Back to Tools
Email Authentication — SPF, DKIM & DMARC Checker
Verify SPF, DKIM, and DMARC DNS records for email authentication alignment.
Enter a domain to check SPF, DKIM, and DMARC records
Authentication Results for
Email Authentication Protocol Reference
Three protocols work together to authenticate email: SPF authorizes sending servers, DKIM cryptographically signs messages, and DMARC tells receivers what to do when authentication fails.
| Protocol | DNS Record | What It Does | Critical Limit |
|---|---|---|---|
| SPF | example.com TXT | Lists IP addresses and hostnames authorized to send mail from this domain. Receivers check the envelope MAIL FROM against the SPF record. | 10 DNS lookups max (RFC 7208). Each include:, a:, mx:, ptr: counts as 1 lookup. |
| DKIM | selector._domainkey.example.com TXT | Cryptographic signature in the email header proving the message was not altered in transit and was authorized by the signing domain. | Key length minimum 1024-bit RSA, recommended 2048-bit. The selector name is arbitrary but published as a DNS subdomain. |
| DMARC | _dmarc.example.com TXT | Policy telling receivers how to handle mail that fails SPF and/or DKIM. Also provides aggregate (rua) and forensic (ruf) reporting. | rua/ruf report URIs must use mailto:. Aggregate XML reports can exceed 10MB for high-volume domains. |
| BIMI | default._bimi.example.com TXT | Brand Indicators for Message Identification — displays a verified logo in the recipient's inbox when DMARC passes with p=quarantine or p=reject. | Requires DMARC at enforcement level. Logo must be a verified SVG Tiny PS format. VMC certificate required. |
How the Authentication Chain Works During Delivery
- SPF check (envelope): The receiving mail server looks at the envelope MAIL FROM (Return-Path), queries the domain's SPF record, and checks if the connecting IP is authorized. Result: Pass, Fail, SoftFail, Neutral, None, TempError, or PermError.
- DKIM check (header): The receiver extracts the DKIM-Signature header, queries the
selector._domainkey.example.comDNS record, retrieves the public key, and verifies the cryptographic signature. Thed=tag identifies the signing domain. - DMARC alignment: DMARC requires alignment — either the SPF-authenticated domain OR the DKIM signing domain must match the header From domain. Alignment can be strict (exact match) or relaxed (same organizational domain).
- Policy application: If neither SPF nor DKIM passes with alignment, the DMARC policy (p=none, p=quarantine, p=reject) is applied. p=none only monitors, p=quarantine sends to spam, p=reject blocks delivery entirely.
- Report generation: The receiver generates an aggregate report (XML, sent to rua addresses) and optionally forensic reports (individual failure samples, sent to ruf addresses) daily.
3 Email Authentication Troubleshooting Workflows
SPF PermError — Too Many Lookups
- Examine your SPF record: each include:, a:, mx:, and ptr: counts as one DNS lookup
- Count the total lookups — if you include _spf.google.com (3 lookups) + spf.protection.outlook.com (1 lookup) + other includes, you may exceed 10
- Use the SPF Flattener to resolve all includes into a flat list of IP ranges
- Consider splitting sending domains: transactional@example.com can have a separate SPF from marketing@example.com using subdomain policies
DKIM Fails After Email Forwarding
- Email forwarding modifies the message body (adds forwarding headers, disclaimers), breaking the DKIM body hash
- DKIM signature includes an
l=(body length) tag — signatures can cover only the first N bytes, allowing appended content - ARC (Authenticated Received Chain) seals preserve original authentication results across forwarding hops
- Forwarding with SRS (Sender Rewriting Scheme) changes the envelope sender, affecting SPF but not DKIM
DMARC Aggregate Report Analysis
- DMARC XML reports contain: source IP, SPF result, DKIM result, disposition, message count, and header From domain
- Look for "SPF pass but not aligned" — the envelope domain passes SPF but does not match the header From domain
- Third-party senders (Mailchimp, SendGrid) appear in reports as sending on your behalf; they need their own SPF/DKIM configuration
- Use the Email Header Analyzer to inspect individual message authentication results
5 Email Authentication Gotchas
1. SPF does not inherit to subdomains: An SPF record at example.com does not protect mail.example.com or any other subdomain unless the subdomain has its own SPF record or a wildcard TXT record exists. Each subdomain must explicitly publish its own SPF.
2. DMARC aggregate reports get too large: Gmail and Microsoft reject aggregate XML reports over 10MB. For domains sending millions of emails per day, reports can exceed this limit silently. Consider a dedicated DMARC analysis service or split reporting across multiple rua addresses.
3. DKIM body length limit interaction: The
l= tag limits how much of the body is signed. If set too low (or omitted), appended footers from forwarding or mailing list software break the signature. Some senders deliberately sign only the first 0 bytes to allow mailing list modification.4. ARC for mailing lists: Mailing lists rewrite the envelope sender, add footers, and change subject lines — breaking both SPF and DKIM. ARC preserves a chain of authentication results so the final receiver can trace back to the original sender's authentication status.
5. Hard fail (-all) vs soft fail (~all):
-all tells receivers to reject mail from unauthorized IPs. ~all says "mark as suspicious but deliver." Start with ~all during rollout — switching to -all prematurely can cause legitimate mail rejection if your SPF record is incomplete.CLI Equivalent
# Check SPF record
dig +short example.com TXT | grep 'v=spf1'
# Check DKIM record (default selector)
dig +short default._domainkey.example.com TXT
# Check DMARC record
dig +short _dmarc.example.com TXT
# Verify SPF include count
dig +short example.com TXT | grep -o 'include:' | wc -l
Related Tools
SPF authorizes which IP addresses can send mail from your domain by publishing a list in DNS. DKIM adds a cryptographic signature to each email that verifies the message was not altered. DMARC is a policy layer on top — it tells receivers what to do (none/quarantine/reject) when SPF or DKIM fails, and provides reporting. All three together provide comprehensive email authentication.
~all (soft fail) tells receiving servers to accept the mail but mark it as suspicious. -all (hard fail) tells servers to reject mail from unauthorized servers entirely. Start with ~all while testing your SPF setup, then move to -all once you are confident all your legitimate sending sources are included.
The DKIM selector is in the DKIM-Signature header as s=selector. You can inspect email headers using the Email Header Analyzer tool. Common default selectors are "default", "google", "selector1", or "dkim". If you do not know your selector, check your email provider documentation or look at the headers of a sent email.
RFC 7208 limits SPF to a maximum of 10 DNS lookups during evaluation. Each include:, a:, mx:, ptr:, and exists: mechanism counts as a lookup. If your SPF record exceeds 10 lookups (e.g., via multiple include chains), receivers return a PermError and may reject your mail. Use the SPF Flattener tool to inline all IP ranges and stay under the limit.
Start with p=none (monitoring only, no action) for at least 2-4 weeks. Collect aggregate reports and verify all legitimate senders pass SPF and DKIM. Then move to p=quarantine with pct=10 (apply to 10% of failing mail). Gradually increase the percentage. Finally move to p=reject once you are confident your configuration is complete.