SPF, DKIM & DMARC Record Inspector & Generator
Parse, validate, and build SPF, DMARC, and DKIM DNS TXT records in your browser — with SPF 10-lookup counting and policy auditing.
| Tag / Mechanism | Qualifier / Value | DNS Lookups | Explanation & Security Impact |
|---|---|---|---|
| Paste or build an SPF, DMARC, or DKIM record to inspect its directives. | |||
How to use the SPF, DKIM & DMARC Inspector
- Paste an SPF (v=spf1), DMARC (v=DMARC1), or DKIM (v=DKIM1) TXT record into the inspector box, or load a sample record.
- Review the parsed mechanism/tag table, the SPF DNS-lookup counter (out of the RFC 7208 10-lookup limit), and security audit warnings.
- Switch to the Policy Builder panel to visually compose a new SPF or DMARC record using common email provider presets (Google Workspace, Microsoft 365, Amazon SES, SendGrid, Postmark).
- Copy the validated DNS TXT host name and value to paste directly into Cloudflare, Route 53, or your DNS provider.
How SPF, DKIM, and DMARC protect email deliverability
Modern inbox providers (including Gmail, Microsoft 365, and Yahoo Mail) enforce strict domain authentication before delivering transactional or marketing emails. Three complementary DNS TXT standards work together to verify sender identity and prevent domain spoofing:
- SPF (Sender Policy Framework — RFC 7208): Published at your root domain (or Return-Path subdomain), an SPF record lists every IPv4/IPv6 CIDR block and third-party mail service authorized to send mail on your domain’s behalf.
- DKIM (DomainKeys Identified Mail — RFC 6376): Attaches a cryptographic signature header (
DKIM-Signature) to outbound messages. Receiving mail servers fetch the RSA or Ed25519 public key from<selector>._domainkey.yourdomain.comto verify the email body and headers were not tampered with in transit. - DMARC (Domain-based Message Authentication, Reporting, and Conformance — RFC 7489): Published at
_dmarc.yourdomain.com, DMARC requires identifier alignment between the visibleFrom:header and your SPF/DKIM domain, tells receivers whether tonone(monitor),quarantine(spam), orreject(block) failing messages, and sends XML aggregate telemetry reports to yourrua=address.
Understanding the SPF 10-DNS-lookup limit (PermError)
Under RFC 7208 Section 4.6.4, a receiving mail server may perform at most 10 DNS-querying mechanisms or modifiers while evaluating an SPF policy. The mechanisms that consume a DNS lookup are include, a, mx, ptr, exists, and the redirect= modifier — plus any nested include lookups triggered inside third-party providers. By contrast, explicit ip4: and ip6: CIDR ranges and the terminal all token require 0 DNS lookups.
If your SPF policy exceeds 10 lookups, receivers abort evaluation with an SPF permerror, which causes legitimate emails to fail DMARC alignment and bounce or land in spam.
Best practices for email authentication
- Never publish
+allin SPF: The+allmechanism authorizes every server on the internet to spoof your domain. Always end your SPF policy with~all(SoftFail) during initial rollout or-all(HardFail) once all legitimate senders are cataloged. - Avoid the deprecated
ptrmechanism: Reverse DNS lookups in SPF are slow, unreliable, and explicitly discouraged by RFC 7208. Replace them with explicit IPv4/IPv6 CIDR blocks using our CIDR & Subnet Calculator. - Gradually tighten DMARC enforcement: Start with
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;to audit aggregate reports, move top=quarantine; pct=25;, and finally enforcep=reject; sp=reject;once all legitimate services sign with aligned DKIM and SPF. - Check live DNS & blacklists: After validating your TXT syntax here, inspect your live mail server reputation with our IP & Domain Blacklist Checker and verify recipient addresses with the Email Verification API.
Frequently asked questions
What is the SPF 10-DNS-lookup limit?
include, a, mx, ptr, exists, and redirect). Exceeding 10 lookups causes receiving mail servers to return permerror and reject or spam-folder your emails. Mechanisms like ip4, ip6, and all do not count toward the limit.What is the difference between ~all (SoftFail) and -all (HardFail) in SPF?
~all (SoftFail) instructs receivers to accept mail from unauthorized IPs but mark it as suspicious or evaluate it further with DMARC. -all (HardFail) instructs receivers to reject unauthorized mail outright. Modern DMARC deployments often pair ~all or -all with p=quarantine or p=reject.What do DMARC policies p=none, p=quarantine, and p=reject do?
p=none monitors email authentication without affecting delivery, sending aggregate XML reports to your rua= address. p=quarantine directs failing messages to the recipient’s spam/junk folder. p=reject blocks unauthenticated spoofed emails before delivery.How does the DKIM public key inspector work?
v=DKIM1; k=rsa; p=... TXT record, the tool Base64-decodes the ASN.1 SubjectPublicKeyInfo structure in your browser to verify that the public key is well-formed and estimates its RSA modulus bit length (warning if a weak 512-bit or 1024-bit key is used instead of 2048-bit).Can I check if my sending IP or domain is already on spam blacklists?
Last updated . Launched with SPF/DMARC/DKIM tag breakdown, RFC 7208 lookup counting, RSA key length inspection, and visual DNS TXT policy builder.
Related developer tools
CIDR Subnet Calculator
IPv4 CIDR subnet calculator for network ranges and host counts.
NewHMAC Generator & Verifier
Generate and verify HMAC signatures using Web Crypto in your browser.
NewJWT Decoder
Decode JWT header and claims, check expiry, verify HS256.
NewRegex Tester
Live regex matching, capture groups and replace preview.
Protecting your email sender reputation and deliverability?
Verify recipient email addresses before sending and check whether your sending IP or domain is listed on 15+ real-time DNSBL blacklists.