SPF Explained: How Sender Policy Framework Actually Works

If you've ever published an SPF record because some onboarding doc told you to, this post is for you. We'll unpack what SPF actually does, why it exists, and the misconfigurations that quietly hurt your deliverability without anyone telling you.

What problem does SPF solve?

Email's original spec (SMTP, 1982) has no concept of authentication. Any server on the internet can claim to be sending mail from support@yourdomain.com. SPF — published in 2006 — was the first widely-adopted attempt to fix this: a DNS record where the domain owner declares which IPs are allowed to send mail.

The mechanics, in one diagram

1. Your mail server sends a message claiming to be from you@yourdomain.com.
2. The receiver looks up the TXT record at yourdomain.com and finds your SPF.
3. The receiver checks if the sending IP matches any of the SPF mechanisms.
4. Based on the result, the receiver either accepts the mail, marks it as spam, or rejects it.

Anatomy of an SPF record

Here's a typical one:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:sendgrid.net -all

Reading left to right:

• v=spf1 — the version. Always 1.
• ip4:192.0.2.0/24 — these IPs are allowed.
• include:_spf.google.com — defer to Google's SPF record (used when you send via Workspace).
• include:sendgrid.net — defer to SendGrid's record.
• -all — anything not matching the above fails. Strict.

The qualifiers — and which to use

• + (pass) — default when no qualifier is given. The mechanism authorizes the source.
• - (fail) — the mechanism explicitly rejects unmatched mail. Mail can be dropped.
• ~ (soft fail) — "probably not authorized." Mail accepted but flagged.
• ? (neutral) — explicit non-statement. Useless in production.

For new domains, start with ~all while you verify all your senders. Once you're confident, switch to -all for full protection.

5 mistakes that quietly hurt deliverability

1. Having two SPF records

You can only have one SPF record per domain. If you have two — say, one from Google Workspace and one from Mailchimp — receivers see this as a syntax error and treat the whole thing as if you have no SPF at all. Merge them into a single record using multiple include: statements.

2. Hitting the 10 DNS lookup limit

Every include, a, mx, exists, or redirect mechanism counts as a DNS query. The SPF spec caps this at 10 total lookups, including nested includes. Big providers' SPF records can already use 6–7 lookups on their own, so adding three or four ESPs to your SPF will exceed the limit and SPF will return PermError — silently failing.

3. Using +all

+all means "any server on the internet can send mail as me." It's the opposite of what you want. We see it most often in records copied from cargo-cult tutorials. Never use it.

4. Forgetting to include your transactional sender

Your marketing emails go out via Mailchimp. Your bills go out via Stripe. Your password resets go out via Postmark. Each one needs an include: in your SPF — or those messages will fail SPF and likely land in spam.

5. Setting it and forgetting it

SPF reflects your sending infrastructure. When you change providers, you need to update the record — and old providers should be removed. Quarterly SPF audits catch the drift.

SPF alone isn't enough

SPF is necessary but not sufficient. It only validates the envelope from — not the From: header your users see. That's why DMARC and DKIM exist. SPF + DKIM + DMARC together form the modern email auth stack.

Next reads:

• DMARC Policy Guide: None vs Quarantine vs Reject
• Check your SPF record now