Skip to content
  1. Home
  2. Developer Tools
  3. SPF, DKIM & DMARC Inspector

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.

Runs 100% in your browser Free, no sign-up Updated

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

  1. Paste an SPF (v=spf1), DMARC (v=DMARC1), or DKIM (v=DKIM1) TXT record into the inspector box, or load a sample record.
  2. Review the parsed mechanism/tag table, the SPF DNS-lookup counter (out of the RFC 7208 10-lookup limit), and security audit warnings.
  3. 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).
  4. 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.com to 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 visible From: header and your SPF/DKIM domain, tells receivers whether to none (monitor), quarantine (spam), or reject (block) failing messages, and sends XML aggregate telemetry reports to your rua= 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

  1. Never publish +all in SPF: The +all mechanism 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.
  2. Avoid the deprecated ptr mechanism: 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.
  3. Gradually tighten DMARC enforcement: Start with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; to audit aggregate reports, move to p=quarantine; pct=25;, and finally enforce p=reject; sp=reject; once all legitimate services sign with aligned DKIM and SPF.
  4. 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?
Under RFC 7208 Section 4.6.4, an SPF evaluation must not perform more than 10 DNS-querying mechanisms or modifiers (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?
When you paste a 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?
Yes. After verifying your SPF and DMARC syntax here, use the ProWebLook IP & Domain Blacklist Checker to query 15+ live DNSBL/RBL reputation feeds in one request.

Last updated . Launched with SPF/DMARC/DKIM tag breakdown, RFC 7208 lookup counting, RSA key length inspection, and visual DNS TXT policy builder.

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.

Check IP & Domain Blacklists