SPF record explained: how mail servers prove they're allowed to send

What SPF is, in one sentence

SPF — Sender Policy Framework — is a DNS TXT record on your domain that lists the IPs and hosts allowed to send mail “from” your domain. When a receiving mail server gets a message claiming to be from [email protected], it looks up example.com’s SPF record and checks whether the connecting IP is on the list.

If it is, SPF passes. If it isn’t, SPF fails, and the receiver leans toward spam — or, with a strict DMARC policy in place, rejects outright.

Why SPF still matters in 2026

Gmail, Yahoo, and Microsoft now require working SPF (or DKIM) on every commercial sender hitting them. For bulk senders — anyone sending 5,000 or more messages a day to a single provider — failing SPF means the message gets filtered hard. Mail-tester and other deliverability scorers all run SPF as the first check, and a missing or broken SPF record is the single most common deliverability problem we see.

SPF on its own isn’t enough — it doesn’t survive forwarding, and it doesn’t sign the message body — but without it, DMARC can’t reach the “pass” state on its own. SPF is the foundation.

Anatomy of an SPF record

An SPF record is a single TXT record on your apex domain that starts with v=spf1. Here’s a real-world example:

example.com.  IN  TXT  "v=spf1 ip4:198.51.100.10 ip4:198.51.100.11 include:_spf.google.com include:sendgrid.net ~all"

Reading it left to right:

• v=spf1 — version tag, always present.
• ip4:198.51.100.10 — allow this specific IPv4 address. Use ip6: for IPv6.
• include:_spf.google.com — also allow whatever Google’s SPF record allows (delegated includes).
• include:sendgrid.net — and whatever SendGrid allows.
• ~all — the qualifier on the catch-all. ~all means “soft-fail anything not above”; -all means “hard fail anything not above.”

Use -all when you’re confident your record is complete. Use ~all while you’re still discovering forgotten senders. Never end with +all — that says “anyone can send for me.”

Common SPF setups

Your own mail server only:

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.5 -all"

Google Workspace:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com -all"

Google Workspace + Mailchimp + a transactional service:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net include:_spf.mtasv.net -all"

How to verify your SPF record is working

1. Look it up directly:

   dig +short TXT example.com | grep spf1

2. Send a test message and inspect the headers in the inbox. Look for Authentication-Results: and confirm spf=pass.

3. Send a test message to Email Health Pro and read the grade — we’ll show the SPF result and explain anything we couldn’t verify.

The five most common SPF mistakes

1. More than 10 DNS lookups. SPF resolves include:, redirect=, a, mx, ptr, and exists against DNS, and the spec limits the total to 10. Past 10, receivers return permerror and your SPF effectively fails. Stacking many include: entries from third-party providers is the usual cause. Tools like Email Health Pro count your lookups and warn before you hit the limit.
2. Two SPF records on the same domain. SPF requires exactly one v=spf1 record. Two of them produces permerror — receivers treat it the same as no SPF. Merge them into one.
3. Forgetting a sender. Marketing platforms, transactional senders, support ticket systems, and bookkeeping tools all send from your domain. If any one of them isn’t in your SPF record, its messages fail SPF.
4. Wrong domain. SPF is evaluated against the MAIL FROM (a.k.a. envelope-from, a.k.a. Return-Path) domain, not the visible From: header. If your ESP uses its own bounce domain, that’s the one that needs SPF — not yours.
5. +all or ?all. +all allows the entire internet to send as you. ?all (“neutral”) gives receivers no signal at all. Always use -all (hard fail) once you’re confident, or ~all (soft fail) during rollout.

SPF, DKIM, and DMARC together

SPF alone is fragile: it breaks the moment a message is forwarded, because the forwarder rewrites the envelope. That’s why modern deliverability relies on three records working together:

• SPF says “this IP is allowed to send for me.”
• DKIM signs the message itself with a key, surviving forwarding.
• DMARC ties both to the visible From: header and tells receivers what to do on failure.

Once your SPF record is in good shape, the next step is DKIM. After that, DMARC brings them together into a policy.

Quick checklist

• One v=spf1 record on your apex domain.
• Every legitimate sender (mail servers, ESPs, transactional services) is in the record.
• Fewer than 10 DNS lookups.
• Ends with -all (preferred) or ~all.
• Verified via dig and via a test message to Email Health Pro.