Email Authentication: SPF, DKIM, and DMARC Explained
A comprehensive guide to SPF, DKIM, and DMARC email authentication records. Learn how each protocol works, how to configure them correctly, and how they protect your domain from email spoofing.
Why Email Authentication Matters
Email impersonation — the practice of sending emails that appear to come from a domain you do not control — has been a major concern for decades. Unauthorized email campaigns and business email compromise fraud routinely impersonate legitimate organizations by forging the "From" address in emails.
Three DNS-based authentication standards were developed to combat this problem: SPF, DKIM, and DMARC. Together, they allow receiving mail servers to verify that emails claiming to come from your domain were actually sent by authorized servers and were not tampered with in transit. Without these records, anyone can send email claiming to be from your domain — a serious security and deliverability risk.
SPF: Sender Policy Framework
What Is SPF?
SPF (Sender Policy Framework) is a DNS record that specifies which mail servers are authorized to send email on behalf of your domain. When a receiving mail server gets an email claiming to be from your domain, it looks up your SPF record and checks whether the sending server's IP address is listed as authorized.
SPF Record Syntax
An SPF record is a TXT record at your domain root. Here is an example:
`v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:spf.protection.outlook.com -all`
Breaking this down:
- v=spf1 — Declares this is an SPF version 1 record
- ip4:203.0.113.0/24 — Authorizes an IPv4 address range
- include:_spf.google.com — Includes Google Workspace's authorized sending IPs
- include:spf.protection.outlook.com — Includes Microsoft 365's authorized IPs
- -all — Hard fail: reject emails from all other sources
SPF Qualifiers
- ~all — Softfail (suspicious but accept; mark as potential spam)
- -all — Fail (reject emails from unauthorized sources; recommended)
- ?all — Neutral (no policy; not recommended)
Common SPF Mistakes
Multiple SPF records: You can only have one SPF record per domain. Two TXT records starting with "v=spf1" causes all SPF checks to fail with a PermError. Combine all mechanisms into a single record.
Too many DNS lookups: SPF has a hard limit of 10 DNS lookups during evaluation. Each "include:", "a:", and "mx:" counts as a lookup. Exceeding 10 causes a PermError. Flatten your SPF record by replacing includes with their actual IP ranges if needed.
Missing sending sources: Many organizations forget to include transactional email services (SendGrid, Mailchimp, Postmark), CRM systems, help desk tools, or other third-party services that send email from their domain.
DKIM: DomainKeys Identified Mail
What Is DKIM?
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing emails. The signature is added to the email header by your mail server and can be verified by receiving servers using a public key published in your DNS. This proves the email genuinely came from your domain's mail server and was not modified in transit.
DKIM DNS Record Format
DKIM records are published at: [selector]._domainkey.[yourdomain.com]
Example: If your selector is "mail", the record would be at mail._domainkey.example.com
The record value looks like:
`v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...`
Where p= contains the base64-encoded public key provided by your email service.
DKIM Selectors
A selector is a label that allows multiple DKIM keys to coexist for the same domain. You might have separate selectors for different email services: "google" for Google Workspace, "sendgrid" for SendGrid, "mailchimp" for marketing emails. Each service provides its own DKIM records with unique selectors.
Key Rotation
DKIM private keys should be rotated periodically (annually is common) to limit exposure if a key is compromised. Selectors make rotation seamless: generate a new key pair, publish the new public key with a new selector, update your mail server, then remove the old selector's DNS record.
DMARC: Domain-based Message Authentication, Reporting and Conformance
What Is DMARC?
DMARC builds on SPF and DKIM by adding alignment requirements and enforcement policies. It allows you to tell receiving servers what to do when an email fails SPF and DKIM checks, and provides reporting so you can monitor authentication results across all emails sent from your domain.
DMARC Record Format
DMARC records are published as TXT records at _dmarc.[yourdomain.com]
Example:
`v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=r; aspf=r`
Tags explained:
- v=DMARC1 — DMARC version declaration
- p= — Policy: none (monitor only), quarantine (send to spam), or reject (block)
- rua= — Aggregate report destination email (receive summary reports)
- pct= — Percentage of emails to apply the policy to (useful for gradual rollout)
- adkim= — DKIM alignment mode: r (relaxed) or s (strict)
- aspf= — SPF alignment mode: r (relaxed) or s (strict)
DMARC Policy Progression
Phase 1 — Monitor (p=none): Start here. Publish a DMARC record with p=none to receive reports without affecting mail flow. Analyze the reports to identify all legitimate sending sources and ensure they pass SPF and DKIM.
Phase 2 — Quarantine (p=quarantine): After validating your legitimate sources, move to p=quarantine. Emails failing DMARC will be delivered to spam/junk folders. Use pct=10 initially to apply the policy to a fraction of emails while you monitor for issues.
Phase 3 — Reject (p=reject): The final goal. Emails failing DMARC are rejected outright. This completely prevents spoofing of your domain in email.
Deploying All Three Together
Recommended deployment order:
- Set up SPF first (easiest, most immediate benefit)
- Configure DKIM for all your mail-sending services
- Verify SPF and DKIM are working (use our TXT Record Lookup to confirm records are published)
- Deploy DMARC at p=none, collect reports for 30–60 days
- Review reports, fix any failing legitimate senders
- Progress to p=quarantine, then p=reject
Verifying Your Email Authentication Records
Use our TXT Record Lookup tool to verify your SPF, DKIM, and DMARC records are correctly published in DNS:
- SPF: Look up TXT records at your domain root (example.com)
- DKIM: Look up TXT records at [selector]._domainkey.example.com
- DMARC: Look up TXT records at _dmarc.example.com
Conclusion
SPF, DKIM, and DMARC are not optional features — they are essential components of responsible domain management. Without them, your domain is vulnerable to spoofing, your emails are more likely to land in spam, and you have no visibility into unauthorized use of your domain in email. Deploy all three in sequence, and use our TXT Record Lookup to verify your records are correctly configured.
