SPF, DKIM, and DMARC Explained (Like You're Not an Engineer)
SPF, DKIM, and DMARC Explained — What They Actually Do and Why You Need All Three
Your emails are landing in spam. Someone told you to "set up SPF, DKIM, and DMARC." You Googled each one. Got overwhelmed by technical jargon. Gave up.
Here's the plain-English explanation of what each does and why all three matter for email deliverability.
The Real-World Analogy That Makes This Simple
Think of email authentication like getting into an exclusive club.
SPF is the guest list. The bouncer checks if you're on the list of people authorized to enter. If your name isn't on the list, you're not getting in.
DKIM is the signature on your ID. It proves your ID hasn't been forged or tampered with. The bouncer checks the signature matches what they have on file.
DMARC is the club's policy. It tells the bouncer what to do when someone fails the previous checks — kick them out, let them wait in a separate line, or just make a note of it.
Email authentication works the same way. SPF checks if you're authorized. DKIM proves your message wasn't tampered with. DMARC tells receiving servers what to do when authentication fails.
What SPF Does: The Authorization List
SPF (Sender Policy Framework) is a DNS record that lists which mail servers are authorized to send email on behalf of your domain.
When Gmail receives an email claiming to be from you@yourdomain.com, it checks your SPF record. If the email came from a server listed in your SPF record, it passes. If not, it fails.
Without SPF:
- Anyone can send emails claiming to be from your domain
- ISPs can't verify legitimate senders
- Your emails get flagged as suspicious
- Spammers impersonate your domain easily
With SPF:
- You explicitly authorize sending servers
- ISPs can verify emails actually came from you
- Spoofing your domain becomes much harder
- Your legitimate emails are trusted more
Test your SPF setup → checkyouremail.online (free, no signup)
How to Set Up SPF: The Actual DNS Record
SPF is a TXT record added to your domain's DNS.
Basic SPF record structure:
v=spf1 [mechanisms] [qualifier]
Real example for Google Workspace:
v=spf1 include:_spf.google.com -all
Breaking it down:
v=spf1- SPF version (always this)include:_spf.google.com- Authorize Google's mail servers-all- Fail any server not listed (strict)
If you send from multiple services:
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net -all
This authorizes Google Workspace, SendGrid, and Mailchimp.
Common SPF mechanisms:
ip4:203.0.113.10- Authorize specific IPv4 addressip6:2001:db8::1- Authorize specific IPv6 addressa- Authorize the A record of your domainmx- Authorize your domain's MX recordsinclude:domain.com- Include another domain's SPF record
Qualifier meanings:
-all- Hard fail (reject unauthorized servers) — recommended~all- Soft fail (accept but mark as suspicious) — common but weaker?all- Neutral (don't care) — pointless+all- Pass everything (never use this)
How to add the SPF record:
1. Log into your DNS provider (GoDaddy, Namecheap, Cloudflare, etc.)
2. Add a TXT record
3. Host/Name: @ or leave blank (represents your root domain)
4. Value: Your SPF record
5. TTL: 3600 (1 hour)
6. Save
Wait 10-30 minutes for DNS propagation. Test at checkyouremail.online.
What DKIM Does: The Tamper-Proof Signature
DKIM (DomainKeys Identified Mail) adds a digital signature to every email you send. This signature proves two things:
1. The email actually came from your domain 2. The email wasn't modified during transit
Think of it like a wax seal on a letter. If the seal is broken, you know someone tampered with it.
How DKIM works technically:
1. Your mail server generates a public/private key pair 2. You publish the public key in your DNS 3. Your server signs every outgoing email with the private key 4. Receiving servers use your public key to verify the signature 5. If the signature matches, the email is authenticated
Without DKIM:
- No proof your emails are legitimate
- Emails can be modified in transit without detection
- ISPs treat your mail with suspicion
- Lower deliverability rates
With DKIM:
- Cryptographic proof of authenticity
- Tampering detection
- Higher trust from ISPs
- Better inbox placement
How to Set Up DKIM: The DNS Record
DKIM setup is more complex than SPF because it involves cryptographic keys. Your email service provider typically generates the keys for you.
For Google Workspace:
1. Go to Admin Console → Apps → Google Workspace → Gmail
2. Click "Authenticate email"
3. Click "Generate new record"
4. Copy the TXT record values
5. Add to your DNS:
- Name: google._domainkey.yourdomain.com
- Type: TXT
- Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC... (long string)
6. Save and wait for propagation
7. Click "Start authentication" in Google Admin
For SendGrid:
1. Go to Settings → Sender Authentication
2. Click "Authenticate Your Domain"
3. Follow the wizard
4. Add three CNAME records they provide:
- s1._domainkey.yourdomain.com → s1.domainkey.u1234.wl.sendgrid.net
- s2._domainkey.yourdomain.com → s2.domainkey.u1234.wl.sendgrid.net
- em1234.yourdomain.com → u1234.wl.sendgrid.net
5. Verify setup in SendGrid dashboard
For your own mail server (advanced):
Generate DKIM keys
opendkim-genkey -t -s mail -d yourdomain.comThis creates two files:
mail.private (keep this secret on your server)
mail.txt (publish this in DNS)
Add the public key from mail.txt to DNS:
mail._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
Test DKIM configuration → checkyouremail.online
What DMARC Does: The Policy Enforcer
DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails.
Without DMARC:
- You have SPF and DKIM but no policy
- ISPs don't know your intentions
- Failed authentication emails might still deliver
- You get no visibility into authentication failures
With DMARC:
- You specify exactly what to do with failing emails
- You receive reports about authentication attempts
- ISPs respect your policy
- You gain visibility into email spoofing attempts
DMARC policies:
p=none- Monitor only, don't reject anything (start here)p=quarantine- Send failing emails to spam folderp=reject- Reject failing emails entirely (maximum protection)
How to Set Up DMARC: The DNS Record
DMARC is the easiest record to add. It's a single TXT record at _dmarc.yourdomain.com.
Start with monitoring mode:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
Add this as a TXT record:
- Host/Name:
_dmarc - Value: The record above
- TTL: 3600
Breaking it down:
v=DMARC1- Version (always this)p=none- Policy (none/quarantine/reject)rua=mailto:email@domain.com- Where to send aggregate reports
After 1-2 weeks of monitoring, upgrade:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100
Eventually move to strict enforcement:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100
Additional DMARC tags:
ruf=mailto:forensic@domain.com- Forensic (detailed) failure reportspct=50- Apply policy to only 50% of emails (useful for gradual rollout)adkim=s- Strict DKIM alignment (default is relaxed)aspf=s- Strict SPF alignment (default is relaxed)
Test your complete authentication → checkyouremail.online
How the Three Work Together
Here's what happens when someone sends an email claiming to be from your domain:
Step 1: SPF Check
- Receiving server checks if the sending IP is in your SPF record
- Result: Pass or Fail
Step 2: DKIM Check
- Receiving server retrieves your public key from DNS
- Verifies the email signature using that key
- Result: Pass or Fail
Step 3: DMARC Evaluation
- Checks if SPF and/or DKIM passed
- Checks alignment (does the "From" domain match?)
- Applies your DMARC policy based on results
- Sends you a report
Possible outcomes:
| SPF | DKIM | DMARC Result | Action with p=reject | |-----|------|--------------|---------------------| | Pass | Pass | Pass | Deliver to inbox | | Pass | Fail | Pass (SPF aligned) | Deliver to inbox | | Fail | Pass | Pass (DKIM aligned) | Deliver to inbox | | Fail | Fail | Fail | Reject email |
You only need ONE of SPF or DKIM to pass for DMARC to pass (in relaxed alignment mode). But you should have both configured.
Common Mistakes and How to Fix Them
Mistake 1: Multiple SPF Records
Problem: You have two or three SPF TXT records
DNS allows multiple TXT records, but SPF requires exactly one. Having multiples breaks SPF entirely.
Fix: Combine them into a single record:
Wrong:
v=spf1 include:_spf.google.com -all
v=spf1 include:sendgrid.net -all
Right:
v=spf1 include:_spf.google.com include:sendgrid.net -all
Mistake 2: SPF Too Many DNS Lookups
Problem: SPF has a 10 DNS lookup limit. Each include: counts as a lookup. Exceeding this breaks SPF.
Example that breaks:
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:spf.protection.outlook.com include:_spf.salesforce.com include:amazonses.com -all
This might exceed 10 lookups because some includes chain to other includes.
Fix: Use IP addresses instead of includes where possible:
v=spf1 include:_spf.google.com ip4:168.245.240.0/20 ip4:198.2.128.0/18 -all
Or use a subdomain for different sending types.
Mistake 3: DKIM Selector Not Found
Problem: DKIM check fails because the selector doesn't exist in DNS
When your server signs an email, it uses a selector like mail._domainkey.yourdomain.com. If that record doesn't exist, DKIM fails.
Fix: Verify your DKIM DNS record exists:
nslookup -type=TXT mail._domainkey.yourdomain.com
If it returns nothing, add the record your email service provided.
Mistake 4: DMARC on Wrong Subdomain
Problem: You added DMARC at dmarc.yourdomain.com instead of _dmarc.yourdomain.com
The underscore prefix is mandatory. Without it, the record won't be found.
Fix: Delete the wrong record. Add it with the underscore: _dmarc
Mistake 5: Starting with p=reject
Problem: You immediately set DMARC policy to reject. Legitimate emails start getting blocked.
Fix: Always start with p=none for 1-2 weeks. Review reports. Fix any issues. Then upgrade to quarantine, then eventually reject.
Check for these mistakes → checkyouremail.online
Testing All Three Together
After setting up SPF, DKIM, and DMARC, test that everything works.
Method 1: Send yourself a test email
Send an email from your domain to your Gmail account. View the full headers (three dots → Show original).
Look for:
spf=pass
dkim=pass
dmarc=pass
All three should say "pass."
Method 2: Use authentication checkers
Tools like checkyouremail.online test all three at once and show exactly what's misconfigured.
Method 3: Check DMARC reports
Wait 24-48 hours after setup. Check the email address you specified in the rua tag. You should receive XML reports showing authentication results.
Why All Three Are Required Now
Gmail and Yahoo announced in 2024 that SPF, DKIM, and DMARC are required for bulk senders (5,000+ emails/day).
But even if you're not a bulk sender, these three are effectively mandatory:
- Without SPF: Emails from your domain fail basic authentication
- Without DKIM: No cryptographic proof of authenticity
- Without DMARC: No policy for authentication failures, no visibility into spoofing
ISPs don't explicitly block you for missing authentication (usually). But their algorithms heavily penalize missing SPF/DKIM/DMARC. Your emails land in spam instead of inbox.
Modern email deliverability requires all three. Not optional. Required.
The Progressive Implementation Plan
Week 1: SPF 1. Identify all servers that send email on your behalf 2. Create SPF record including all of them 3. Add to DNS 4. Test thoroughly 5. Monitor for issues
Week 2: DKIM 1. Generate DKIM keys (or have your ESP do it) 2. Add public key to DNS 3. Configure your mail server to sign with private key 4. Test that signatures appear and validate 5. Monitor for failures
Week 3-4: DMARC Monitoring
1. Add DMARC record with p=none
2. Collect reports for 1-2 weeks
3. Identify any authentication failures
4. Fix issues before enforcement
Week 5: DMARC Quarantine
1. Upgrade to p=quarantine
2. Monitor impact on delivery
3. Check for false positives
4. Adjust if needed
Week 6+: DMARC Reject
1. Upgrade to p=reject
2. Maximum protection achieved
3. Continue monitoring reports
4. Maintain records as you add/remove services
Test at each stage → checkyouremail.online
What Happens to Emails That Fail Authentication
With no SPF/DKIM/DMARC:
- Emails might still deliver (depends on ISP)
- Treated with suspicion
- More likely to land in spam
- Easier for spammers to impersonate you
With SPF/DKIM but no DMARC:
- Better than nothing
- ISPs make their own decisions on failures
- You get no visibility into issues
- No consistent policy enforcement
With all three (p=none):
- Monitoring mode
- Authentication checked but not enforced
- You receive reports
- ISPs still make their own decisions
With all three (p=quarantine):
- Failed authentication → spam folder
- Passed authentication → inbox (if content is good)
- Consistent enforcement
- Better protection
With all three (p=reject):
- Failed authentication → rejected entirely
- Maximum protection against spoofing
- Requires confident authentication setup
- Industry best practice
SPF, DKIM, DMARC Checklist
- [ ] Identified all servers authorized to send from your domain
- [ ] Created SPF record including all authorized servers
- [ ] Kept SPF under 10 DNS lookups
- [ ] Added SPF TXT record to DNS
- [ ] Verified SPF with
nslookupand email test - [ ] Generated DKIM key pair (or obtained from ESP)
- [ ] Added DKIM public key to DNS
- [ ] Configured mail server to sign with DKIM private key
- [ ] Verified DKIM signature appears and validates
- [ ] Added DMARC record with
p=none - [ ] Specified valid email address for reports in
ruatag - [ ] Waited 1-2 weeks and reviewed DMARC reports
- [ ] Fixed any authentication issues found
- [ ] Upgraded DMARC to
p=quarantine - [ ] Monitored for false positives
- [ ] Upgraded DMARC to
p=reject - [ ] Set up ongoing monitoring
SPF, DKIM, and DMARC aren't optional anymore. They're the minimum requirement for legitimate email delivery. Set them up correctly once, and your deliverability improves permanently.
Run a free deliverability check right now at checkyouremail.online — no signup, results in 30 seconds.