Part of the
DNS & Authentication category
Browse every SPF / DKIM / DMARC, PTR, MX, and bulk-sender guide in one hub — including the step-by-step setup paths and manual DNS inspection guides.
See the DNS & Authentication category →What SPF, DKIM, and DMARC Are
Email was designed in the 1970s with no concept of sender verification — anyone could open an SMTP connection to a remote server and claim any envelope From: address. SPF, DKIM, and DMARC close that gap by giving domain owners a way to cryptographically and policy-wise declare: these are the only servers that can send email for my domain, and here is what to do when something does not match. Each protocol answers a different question, and together they form the authentication floor every modern mailbox provider expects.
SPF (Sender Policy Framework) is a DNS TXT record published at the apex of your domain that lists every IP address and mail server authorised to send email on your behalf. A receiving mail server accepts a message claiming to come from your domain, does a DNS lookup against your SPF record, and checks whether the sending IP is on the approved list. SPF is the first arm of authentication and an entry ticket the Gmail + Yahoo bulk-sender bar requires.
Example SPF record:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:192.0.2.1 -allThis says: mail for this domain may come from Google Workspace servers, SendGrid, or IP 192.0.2.1. Everything else hard-fails (-all).
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message. Your mail server signs the message with a private key; the matching public key is published as a DNS TXT record at a selector subdomain (selector._domainkey.yourdomain.com). Receiving mail servers use the public key to verify the signature — a passing DKIM check means the content has not been altered in transit and the message genuinely came from a sender that holds your private key. Unlike SPF, DKIM survives forwarding because the signature travels with the headers.
Example DKIM record:
google._domainkey.yourdomain.com TXT
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together. It requires that the domain authenticated by SPF (the envelope MAIL FROM domain) or the domain authenticated by DKIM (the d= domain) aligns with the visible From: domain, and it tells receiving servers what to do when both checks fail — none (monitor), quarantine (spam folder), or reject (block at SMTP). DMARC also lets you receive aggregate RUA reports daily from the major providers.
Example DMARC record:
_dmarc.yourdomain.com TXT
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100The optional rua=mailto:… address tells providers where to send the daily aggregate reports — without it you are flying blind on what is sending on your behalf and what is failing.
How DMARC Alignment Works
SPF and DKIM on their own only verify the envelope sender and the message integrity. They do not tie either result back to the visible From: domain the user sees in their inbox. DMARC alignment is the bridge: for DMARC to pass, the domain authenticated by SPF or DKIM must match — or be a parent of — the domain in the visible From: header.
SPF alignment. SPF checks the envelope sender (the MAIL FROM address used during the SMTP handshake). For DMARC alignment to hold, the SPF domain (the domain in the MAIL FROM envelope) must match the visible From: domain exactly, or be a parent of it. Subdomains accepted on both sides — MAIL FROM: bounces.mail.yourdomain.com aligning with From: alerts@mail.yourdomain.com is fine — but mail.yourdomain.com and mail.notyourdomain.com do not align.
DKIM alignment. DKIM signs the message with a d= domain (the domain in the DKIM-Signature header). For alignment to hold, that d= domain must match the visible From: domain exactly or be a parent of it. DKIM alignment is more resilient than SPF alignment in production because the d= domain does not change between intermediaries — it stays attached to the message when it is forwarded, scanned, or routed through a list.
The dual-pass requirement. DMARC passes when EITHER SPF alignment passes OR DKIM alignment passes. The receiving server does not require both — but you want both to pass for the resilience: SPF can break on forwarding, and DKIM signatures occasionally fail on intermediate rewrites. Configure both against your brand domain and either-arm failure does not break your DMARC posture.
When both arms fail, the DMARC policy in p= takes over: none = take no action (monitor only), quarantine = send to spam, reject = block at SMTP. And the pct=100 flag applies the policy to 100% of failing mail.
How to Verify Each Record
Use public DNS queries to see what is published. For a message-level SPF check, identify the receiver’s smtp.mailfromdomain in Authentication-Results, then follow the manual instructions in the SPF record check guide.
SPF TXT: Query the exact SPF identity domain; the root-domain example below will not cover a separate return-path subdomain.
dig +short TXT yourdomain.comLook for one policy beginning with v=spf1. The DNS response shows publication, not whether a particular message passed or aligned. For symptom-led diagnosis, use the SPF troubleshooting guide.
DKIM selector TXT:
dig +short TXT selector._domainkey.yourdomain.comThe selector comes from the message’s DKIM-Signatures= tag.
DMARC TXT:
dig +short TXT _dmarc.yourdomain.comRead the received message’s SPF, DKIM, and DMARC results together. DMARC passes when at least one authenticated SPF or DKIM identifier aligns with the visible From domain.
Troubleshooting Each Protocol
For detailed SPF diagnosis, use the dedicated SPF troubleshooting guide. It maps duplicate policies, missing or incorrect mechanisms, lookup-limit results, and alignment symptoms to sender-run checks.
For DKIM, compare the receiver’s signature result with the selector and signing domain in the message headers. For DMARC, inspect the SPF and DKIM results alongside the visible From domain and the policy published at _dmarc. A failure in one protocol does not by itself explain the outcome of the others.
Aggregate DMARC reports help identify recurring sources over a reporting period. Compare unfamiliar IPs and domains with the systems authorized to send for you before making DNS changes.
How Authentication Relates to Reputation and Blocklists
SPF, DKIM, and DMARC provide authentication evidence to receiving systems, while inbox placement and blocklist decisions use other signals too. An SPF PermError, an alignment failure, and a blocklist listing are different outcomes; confirm each from its own message headers, reports, or list operator before deciding what to change.
For background on sender reputation, read the Sender Reputation Guide. For list-specific status, use the blocklist checker and the operator’s current guidance.
Authentication Triage Checklist
Start with the result added by the receiving mailbox, then compare its identity and policy fields with the message and the DNS records you control.
- SPF returns an error or does not align. Note the
smtp.mailfromdomain, SPF result, and visible From domain. Follow the SPF troubleshooting guide for the matching symptom and next check. - DKIM fails. Read the
DKIM-Signatureselector and signing domain in the message, then compare them with your provider’s published selector record. - DMARC fails while an authentication arm passes. Check whether the passing SPF or DKIM domain aligns with the visible From domain, then review your DMARC policy and aggregate reports.
- A DNS change is not visible yet. Query the public record again after the DNS provider’s TTL window and send a fresh message before drawing a conclusion from old headers.