SPF, DKIM, and DMARC Explained: The Complete Email Authentication Guide
SPF, DKIM, and DMARC are the three pillars of email authentication. Without all three, your email can be spoofed, land in spam, or get rejected. Here is how they work and how to set them up.
SPF, DKIM, and DMARC Explained: The Complete Email Authentication Guide
Email was designed without authentication — anyone could claim to be anyone. SPF, DKIM, and DMARC are the three DNS-based standards that fix this. Together they verify that email claiming to be from your domain actually is from your domain.
Why You Need All Three
Each standard plugs a different hole:
- SPF — tells the world which servers are allowed to send email for your domain
- DKIM — cryptographically signs your emails so recipients can verify they were not tampered with
- DMARC — ties SPF and DKIM together, adds a policy, and gives you reports
None of them alone is sufficient.
SPF — Sender Policy Framework
What It Does
SPF lets you publish a list of authorized mail servers as a DNS TXT record at your domain root. When a receiving server gets email claiming to be from [email protected], it checks whether the sending server's IP is in your SPF record.
Example SPF Record
v=spf1 include:_spf.google.com include:sendgrid.net ~all
This says: Google's servers and SendGrid are authorized senders. The ~all means everything else is a soft fail (still delivered but marked suspicious). Use -all for a hard fail (rejected).
SPF Limitations
SPF checks the technical envelope sender, not the From: header visible in email clients. This means SPF alone does not prevent display name spoofing. Also, SPF breaks on email forwarding — when a server forwards your email, the forwarder's IP is not in your SPF record.
The 10 DNS Lookup Limit
SPF is limited to 10 DNS lookups during evaluation. Complex SPF records with many nested includes can exceed this limit and cause failures. Use an SPF flattening service if needed.
DKIM — DomainKeys Identified Mail
What It Does
DKIM adds a cryptographic signature to every outgoing email. The receiving server verifies this signature using a public key published in your DNS. If valid, the email has not been tampered with in transit.
How It Works
- Your mail server signs outgoing emails with a private key.
- The public key is published in DNS as a TXT record.
- Receiving servers verify the signature using your public key.
Example DKIM DNS Record
DKIM records live at a selector subdomain: mail._domainkey.yourdomain.com → TXT → "v=DKIM1; k=rsa; p=MIGfMA0..."
The "mail" part is the selector — you can have multiple DKIM keys with different selectors (useful when multiple services send email for you).
Why DKIM Is More Robust Than SPF
DKIM survives email forwarding because the signature travels with the message content, not the server IP. As long as the message body and headers are not modified, the DKIM signature remains valid.
DMARC — Domain-Based Message Authentication, Reporting and Conformance
What It Does
DMARC ties SPF and DKIM together with a policy. It tells receiving servers what to do when emails fail authentication checks, and it sends you reports about who is sending email on behalf of your domain.
Example DMARC Record
_dmarc.yourdomain.com → TXT → "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"
Policy options:
- p=none — Monitor only, no action. Start here.
- p=quarantine — Failed emails go to spam folder.
- p=reject — Failed emails are rejected outright.
The Alignment Concept
DMARC introduces alignment — the domain in the From: header must match the domain authenticated by SPF or DKIM. This closes the spoofing gap that SPF alone leaves open.
DMARC Reports
DMARC sends you aggregate reports (rua) showing: what servers are sending email claiming to be from your domain, how many messages passed/failed SPF and DKIM, and which IPs are sending on your behalf. These reports are invaluable for identifying unauthorized senders and fixing misconfigurations.
How the Three Work Together
Email arrives → SPF check: Is sending IP authorized? → DKIM check: Is signature valid? → DMARC alignment: Does From: domain match authenticated domain? → DMARC policy: none / quarantine / reject → Report sent to domain owner
All three need to be configured for the chain to be effective.
Practical Setup Guide
Step 1: Add SPF
Find your email provider's SPF include in their documentation. Common examples:
- Google Workspace: v=spf1 include:_spf.google.com ~all
- Microsoft 365: v=spf1 include:spf.protection.outlook.com ~all
- Mailchimp: v=spf1 include:servers.mcsv.net ~all
Step 2: Enable DKIM
DKIM is configured in your email provider's admin console. They generate the key pair and tell you which TXT record to add to your DNS. The record name follows the pattern selector._domainkey.yourdomain.com.
Step 3: Add DMARC (start with p=none)
Add a TXT record at _dmarc.yourdomain.com: v=DMARC1; p=none; rua=mailto:[email protected]
After reviewing reports for 2-4 weeks, move to p=quarantine, then eventually p=reject.
Step 4: Verify
Use ElasticDomain's Email Deliverability Tester (Tools → Email Deliverability) to confirm all three records are present, valid, and correctly configured. The tester returns a score out of 100.
Common Issues
| Issue | Fix |
|---|---|
| SPF not found | Add TXT record at domain root |
| SPF too many lookups | Flatten nested includes |
| DKIM selector not found | Check selector name in your provider |
| DMARC not found | Add TXT record at _dmarc.yourdomain.com |
| DMARC quarantine too aggressive | Start with p=none and review reports first |
Ongoing Monitoring
SPF, DKIM, and DMARC records can be accidentally removed during DNS migrations or registrar transfers. ElasticDomain monitors your DNS and alerts you if any of these records change — before you lose email deliverability.