SPF Record Explained: What It Is and How to Set It Up

Published December 21, 2025 · 10 min read

SPF Record Explained: What It Is and How to Set It Up

I spent way too long debugging email deliverability issues before I really understood SPF. Turns out, half the "why are my emails going to spam" problems come down to this one DNS record being wrong - or missing entirely.

SPF stands for Sender Policy Framework. It's a TXT record in your DNS that basically says "these servers are allowed to send email on behalf of my domain." When Gmail or Outlook receives an email claiming to be from yourdomain.com, they check your SPF record to see if the sending server is on the approved list. If it's not, the email gets flagged or rejected.

Why You Actually Need This

Without SPF, literally anyone can send email that looks like it comes from your domain. I don't mean they can fake the display name - I mean they can make the actual From address show your domain. Phishing emails that look like they're from "support@yourcompany.com" become trivially easy.

But here's what really gets people's attention: Gmail and Yahoo now require SPF for bulk senders. Since February 2024, if you're sending marketing emails or newsletters without proper SPF, you're going to have deliverability problems.

The Syntax (It's Not That Bad)

Every SPF record starts with v=spf1 and ends with something like -all or ~all. In between, you list who's allowed to send.

\\\

\\\

That's a complete, valid SPF record. It says "Google's servers can send mail for me, and reject everything else."

Here's what the pieces mean:

And the ending:

Copy-Paste Examples

\\\

\\\

\\\

\\\

\\\

\\\

\\\

\\\

Mistakes That Will Bite You

This one gets everyone eventually. SPF is limited to 10 DNS lookups total. Every "include:" causes at least one lookup. And here's the annoying part - if your include references another SPF record with includes, those count too.

Google's _spf.google.com alone uses up 4-5 lookups. Add Microsoft and a couple email services, and you're over the limit. Your SPF silently fails and you have no idea why emails are bouncing.

Fix: use IP addresses where you can. Or look into SPF flattening services that expand includes into IP lists.

Each domain can only have one SPF record. If you've got two, behavior is undefined - some receivers take the first, some take the second, some reject both.

I see this happen when someone adds Google Workspace without realizing there's already an SPF record for something else.

Wrong:

\\\

\\\

Right:

\\\

\\\

Sign up for Mailchimp. Connect your domain. Forget to update SPF. Three months later, wonder why campaign open rates tanked.

Every service that sends email on your behalf needs to be in your SPF record. That includes: transactional email (SendGrid, Postmark, SES), marketing (Mailchimp, ConvertKit), CRM tools that send email, helpdesk software, etc.

Soft fail (~all) is for testing. It tells receivers "if SPF fails, it's probably suspicious but don't reject it." That was fine in 2015. In 2025, you want hard fail (-all). Show receivers you mean it.

Actually Setting This Up

DNS changes can take up to 48 hours to propagate everywhere, but usually it's more like 15-30 minutes.

Test It

Use our DNS Health Check to validate your SPF record. It'll catch syntax errors, check if you're over the lookup limit, and tell you if anything looks wrong.

You can also send a test email to a Gmail account, then open the email, click the three dots, and "Show original." Look for "spf=pass". If it says fail or softfail, something's wrong.

SPF Is Just One Piece

SPF, DKIM, and DMARC work together. SPF checks if the server is authorized. DKIM cryptographically signs the email so receivers know it wasn't tampered with. DMARC tells receivers what to do when checks fail.

You really want all three. But SPF is the easiest to set up, so start there.

Frequently Asked Questions

Depends on DNS propagation, but usually within an hour. Give it 24-48 hours before panicking.

No. SPF only works when the receiving server checks it (most major providers do) and when the attacker isn't using your own compromised server. Combined with DKIM and DMARC, it's much more effective.

SPF is necessary but not sufficient. You might be missing DKIM, or your domain is new and has no reputation, or your email content is triggering spam filters. Run a full DNS health check to see what else might be missing.

No. Each subdomain that sends email needs its own SPF record.

If misconfigured, yes. Always test with ~all before switching to -all.