SPF, DKIM and DMARC Explained: Configure and Diagnose Email
Understand SPF, DKIM and DMARC alignment, inspect delivered messages and diagnose authentication failures before strengthening your domain policy.
TL;DR
- SPF checks whether a sending host is authorized for an envelope domain; it does not directly authenticate the visible From address.
- DKIM verifies a domain's signature over selected message content and headers.
- DMARC connects authentication to the visible From domain through alignment and publishes a receiver policy.
- Inventory legitimate senders, inspect real message results and review reports before strengthening a domain policy.
Three checks with different jobs
Email authentication is easier to understand when each mechanism has one job. SPF concerns the sending host and an envelope identity. DKIM concerns a signed message and the domain that signed it. DMARC asks whether a successful authentication result aligns with the domain the reader sees in the From header.
Passing one check does not prove that the message is wanted, harmless or guaranteed to reach the inbox. Authentication helps establish domain responsibility; recipient expectations, content and sending reputation remain separate considerations.
Start by viewing the source of a message delivered to a mailbox you control. Locate its authentication results, visible From address, return-path and DKIM signing domain. Compare the actual identities rather than assuming they all match your website domain.
What SPF checks
SPF, defined in RFC 7208, lets a domain publish rules describing which hosts may send using its envelope identity. A receiver evaluates the sending IP against that policy. For a message with an empty envelope sender, the HELO identity becomes relevant.
This distinction explains a common surprise: a message can pass SPF for a provider-controlled return-path while failing to align that result with your visible From domain. The word pass is meaningful only together with the domain that passed.
Use the exact DNS configuration your provider supplies. Do not create multiple independent SPF policy records at the same domain to add several services. Maintain a single valid policy and account for the lookup constraints. If you are unsure which services still send, complete an inventory before removing entries.
What DKIM adds
DKIM's specification describes a signature that receivers can verify with a public key published under the signing domain. The signature identifies a selector, allowing the receiver to find the correct DNS key.
Your provider may sign using your domain once verification is complete. Check that delivered messages actually carry the expected signing domain, that verification succeeds and that key rotation does not leave stale configuration behind.
DKIM is not message encryption. It does not hide the body from intermediaries. Its purpose is to allow verification of the signed material, subject to the details of the signature and the changes made in transit.
What DMARC connects
DMARC evaluates the visible From domain against successful SPF or DKIM authentication using alignment rules. A message does not need both aligned mechanisms to pass DMARC, although operating both can make your sending setup more robust.
The current core specification is RFC 9989, published in May 2026 and replacing RFC 7489. Older setup guides can therefore contain obsolete details. Policy and reporting should be reviewed against the current standard and the capabilities of the systems processing your mail.
The familiar policy values none, quarantine and reject express different requested handling of failing messages. Receiver behavior and other local policy still matter. A strong domain policy should follow evidence that legitimate senders authenticate and align correctly, rather than being enabled as a cosmetic security badge.
A safe configuration sequence
- List every legitimate sender: product mail, newsletters, support systems, billing tools and any remaining legacy application.
- Identify the visible From domain, envelope domain and DKIM signing domain used by each.
- Add and verify the DNS records supplied for that sender.
- Send controlled test messages and inspect the receiver's authentication results.
- Review aggregate reporting to discover overlooked senders or alignment failures.
- Strengthen policy after correcting legitimate failures and preparing a rollback procedure.
Keep separate notes for the apex domain and any sending subdomains. A record at one name does not prove that every related identity has the intended configuration. When a DNS dashboard automatically appends your domain, avoid entering a duplicated full name.
Diagnose the failed layer
| Symptom | Check first |
|---|---|
| SPF fails | Actual envelope domain, sending IP and published SPF policy |
| DKIM fails | Selector, key record, signature and message modification |
| SPF passes but DMARC fails | Alignment with the visible From domain |
| Verification never completes | Exact record name/value, authoritative DNS and propagation |
| Some services work but others fail | Sender inventory and per-service identity configuration |
Change one layer at a time and retain a before-and-after message sample. If a provider dashboard shows verified but a recipient reports failures, investigate the delivered source. Dashboard verification proves that a configuration check succeeded; it is not a substitute for observing the specific message.
Common questions
Does a DMARC pass guarantee inbox placement?
No. It answers an authentication-alignment question. Use the spam troubleshooting guide when accepted, authenticated mail still lands outside the inbox.
Should I copy a DNS record from a blog?
Use your provider's domain-specific instructions. Example domains, selectors and reporting addresses are explanatory and should not be pasted into production unchanged.
What should I do with reports?
Use them to investigate who is sending with your domain and whether authentication aligns. Keep reporting access restricted because reports can expose operational information about your mail infrastructure.