You added the DNS records. You triple-checked the values. The registrar dashboard shows everything's there. But every checker tool keeps saying "SPF record not found". Sound familiar?
Last Tuesday, a friend pinged me at 11 PM. He'd been trying to set up email authentication for his new SaaS for three hours. DNS records were in place. Screenshots to prove it. But mail-tester kept giving him a 4/10.
"Bro, I'm going insane. I literally copied everything from Google's documentation."
Turns out it was one of those problems that looks complicated but has a stupidly simple cause. Let me walk you through what we found — and the 5 things you should check before you lose your mind.
Before we dive in
Run a quick check on your domain. Sometimes the problem is obvious and you don't need to read this whole thing.
Check my SPF record →1DNS Propagation (The Boring But Common One)
Yeah, I know. Everyone says "wait for DNS propagation" and you're thinking "I've waited an hour, that should be enough."
Here's the thing — it depends on your DNS provider. Some are fast (Cloudflare, usually under 5 minutes). Some are... not (looking at you, certain budget registrars).
What actually happened to my friend:
He was using GoDaddy's DNS. The dashboard showed the record, but when we ran dig, nothing. We waited another 30 minutes — still nothing. Switched his nameservers to Cloudflare, and boom, records showed up in under 2 minutes.
How to actually check propagation:
Don't trust your registrar's dashboard. Use these instead:
# Check SPF from command line
dig TXT yourdomain.com +short# Or check from multiple locations
nslookup -type=TXT yourdomain.com 8.8.8.8If you see your record when querying Google's DNS (8.8.8.8) but not others, it's still propagating. Give it another hour or two.
2Wrong Record Type (This One Got Me)
SPF records go in a TXT record, not an SPF record.
"Wait, there's an SPF record type?" Yeah, there was. It's been deprecated since 2014. But some older DNS interfaces still show it as an option, and if you pick that instead of TXT... nothing works.
Wrong
Type: SPF
Value: v=spf1 include:...
Correct
Type: TXT
Value: v=spf1 include:...
Same goes for DKIM — it's also a TXT record, just with a specific name format (like selector._domainkey.yourdomain.com).
3The Subdomain Trap
This is sneaky. You set up SPF for yourdomain.com, but your emails are actually sent from mail.yourdomain.comor notifications.yourdomain.com.
Key insight: SPF is checked against the domain in the Return-Path header, not the From header. These are often different, especially if you're using a third-party email service.
Check your email headers. Look for the Return-Path line. That's the domain that needs the SPF record.
For DKIM, check the d= value in the signature. If it says d=mail.yourdomain.com, your DKIM record needs to be atselector._domainkey.mail.yourdomain.com, not the root domain.
4Quoting and Formatting Issues
Some registrar interfaces are... special. They auto-add quotes around your TXT value. Or they don't, when they should. Or they add escape characters that break everything.
Things that have broken my records before:
- Extra quotes:
"\"v=spf1..."\" - Smart quotes (copy-pasted from a Word doc)
- Invisible characters (especially if copied from a PDF)
- Trailing spaces
Pro tip:
Type it out manually instead of copy-pasting. Seriously. Or paste into a plain text editor first, then copy from there.
5DKIM Selector Mismatch
DKIM records have a "selector" — it's the first part of the record name. If your email service uses selector1 but you set up the record for google... it won't match.
Common selectors by provider:
| Provider | Typical Selector | Record Name |
|---|---|---|
| Google Workspace | google._domainkey | |
| Microsoft 365 | selector1, selector2 | selector1._domainkey |
| SendGrid | s1, s2 | s1._domainkey |
| Mailchimp | k1 | k1._domainkey |
Check your email headers for the s= value in the DKIM signature. That tells you exactly which selector is being used.
🔧 Quick Debug Checklist
Run through these before you pull your hair out:
Still Stuck?
If you've gone through all of this and it's still not working, there might be something specific to your setup. The most helpful thing you can do is grab the raw email headers from a test message and look at what's actually happening.
My friend's issue? Turned out to be a combination of #1 and #3 — slow propagation at GoDaddy plus he was checking the wrong domain. Classic combo.
We fixed it in about 10 minutes once we knew what to look for. Hopefully this saves you the 2 hours of frustration we went through.
Need a second opinion?
Run your domain through our checker. It'll tell you exactly what's configured (or not) and where the problem might be.