SPF Records Explained: Syntax, Examples and Common Mistakes (2026)

What is an SPF record?

An SPF record is a single line of text published in your domain’s DNS that answers one question: which servers are allowed to send email claiming to be from this domain? Receiving mail servers query it during every inbound SMTP handshake. If the connecting IP appears in the list, the message passes SPF. If it doesn’t, the message is treated according to the policy you chose: silently accepted, marked as suspicious, or rejected outright.

SPF is one of the three pillars of modern email authentication, alongside DKIM and DMARC. Without it, anyone on the internet can forge your domain in the MAIL FROM envelope and send spam, phishing, or malware in your name. With it correctly published, receivers have a cryptographic-grade way to reject impersonation attempts before they ever reach an inbox.

How SPF works, step by step

Every time someone sends mail claiming to be from your domain, this is what happens behind the scenes:

1. The sending server connects to the receiving mail server and issues MAIL FROM: user@yourdomain.com.
2. The receiving server extracts the domain (yourdomain.com) from the envelope sender.
3. The receiving server queries DNS for the TXT record at yourdomain.com, looking for one beginning with v=spf1.
4. The SPF record is evaluated against the connecting IP address. The receiver walks left-to-right through each mechanism (ip4, include, a, mx…) until it finds a match.
5. A result is returned: pass, fail, softfail, neutral, none, permerror, or temperror. The receiver then applies its own policy (and your DMARC policy if one exists) to decide whether to deliver, quarantine, or reject.

The whole check takes milliseconds. But the rules that produce the result are subtle, and that’s where most mistakes hide.

SPF record syntax: anatomy of a TXT record

An SPF record is a single string starting with the version tag v=spf1, followed by mechanisms separated by spaces, ending with an all qualifier. Here is a real-world example for a domain that sends mail through Google Workspace plus Mailgun:

v=spf1 include:_spf.google.com include:mailgun.org -all

Read left to right, this says: “version 1; the IPs that Google publishes for Workspace are authorized; the IPs that Mailgun publishes are authorized; everything else, hard-fail.”

SPF mechanisms

SPF qualifiers

Each mechanism can be prefixed with a qualifier that tells the receiver what to do when the mechanism matches:

Real-world SPF examples by provider

Copy these as starting points. Each is a valid record for a domain sending only through that provider. If you use several, combine them (see “multiple services” below).

Google Workspace

v=spf1 include:_spf.google.com ~all

Microsoft 365 / Outlook for Business

v=spf1 include:spf.protection.outlook.com -all

SendGrid

v=spf1 include:sendgrid.net ~all

Mailchimp / Mandrill

v=spf1 include:servers.mcsv.net -all

Mailgun

v=spf1 include:mailgun.org ~all

Amazon SES

v=spf1 include:amazonses.com ~all

Postmark

v=spf1 a mx include:spf.mtasv.net ~all

Brevo (ex-Sendinblue)

v=spf1 include:spf.brevo.com ~all

Multiple services combined

If you send through Google Workspace for corporate email and SendGrid for transactional and Mailchimp for newsletters:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net -all

Watch the 10-lookup limit (next section), each include counts as one, and providers often nest further includes inside their own records.

The 10-DNS-lookup limit (where most SPF records break)

Probably the single most misunderstood part of SPF. An SPF record is allowed a maximum of 10 DNS lookups during evaluation. Exceed that and the entire record returns permerror, meaning none of your mail authenticates, regardless of which IPs you authorized.

What counts as a lookup:

• Every include: mechanism, and recursively, every include: inside that domain’s own SPF record.
• Every a, mx, exists:, ptr, and redirect= mechanism.
• ip4: and ip6: do NOT count, they don’t require a DNS query.

A record like v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:mailgun.org include:amazonses.com include:_spf.salesforce.com include:spf.protection.outlook.com -all looks reasonable, but Google’s _spf.google.com alone nests several deeper includes, and you can blow past 10 lookups with just 5 visible includes.

Fix: use our free SPF checker to count your actual lookups. If you’re over, you have several options: restructure with subdomains, flatten, or use a managed SPF service (the trade-offs of each are covered in the dedicated guide).

How SPF fits into DMARC

SPF authenticates the envelope sender (the MAIL FROM address used during SMTP negotiation). DMARC requires that the envelope domain and the visible From: header domain match, this is called SPF alignment.

A message can pass SPF (the connecting IP is authorized) but still fail DMARC (the SPF-authenticated domain does not match the From header domain). Forwarders are the classic case: a mailing list relays your message from its own IP, so SPF checks against the list’s domain, not yours, DMARC alignment breaks. That is exactly why ARC (RFC 8617) exists, and why a DMARC policy without DKIM is fragile.

For the full picture, see our Email Delivery Infrastructure guide.

Common SPF mistakes (and how to avoid them)

1. Two SPF records on the same domain. If you add a second TXT starting with v=spf1, the entire SPF lookup returns permerror. Merge into one record.
2. Using +all or no all. +all tells receivers everyone is authorized, equivalent to no SPF at all. Always end with ~all or -all.
3. Exceeding the 10-lookup limit. Discussed above. The most common reason for “SPF stopped working after I added a new ESP.”
4. Forgetting subdomains. marketing.example.com needs its own SPF if you send from it. Otherwise it inherits nothing, and DMARC may fail.
5. Using deprecated ptr. The ptr mechanism is officially deprecated in RFC 7208 because it is slow and unreliable. Don’t use it.
6. SPF string longer than 255 characters. A single DNS string is capped at 255 chars. Longer records must be split into multiple concatenated strings inside one TXT record, most DNS hosts handle this automatically, but a manual edit can break it.
7. Trusting SPF alone. SPF doesn’t authenticate the From header, doesn’t survive forwarding, and doesn’t protect attachments. Pair it with DKIM and DMARC, every time.
8. Not updating after switching ESPs. Cancelled SendGrid but left include:sendgrid.net in your record? You’re now linked to a service you no longer control. Audit twice a year.
9. Hard-failing (-all) before you’re ready. Going straight to -all can block legitimate edge cases (a forgotten internal mailer, a vendor’s notification service). Start with ~all, monitor DMARC reports for 2-4 weeks, then tighten.
10. Treating include as an inheritance. include:other.com only imports SPF rules, not the domain itself. If other.com‘s SPF returns fail, your evaluation continues; an include only stops on match.

How to test your SPF record

Before you publish, and after every change, verify your record:

1. Use the free SMTPedia SPF Checker at smtpedia.com/free-spf-record-checker. It validates syntax, counts your DNS lookups, expands every include, and flags permerror conditions.
2. Send a test email to a personal Gmail or Outlook account. Open the message, view the full headers, and look for an Authentication-Results line containing spf=pass.
3. Query DNS directly with dig or nslookup:

   dig TXT example.com +short

   You should see exactly one string starting with v=spf1.
4. Monitor DMARC aggregate reports once DMARC is in place. They show real-world SPF pass/fail rates by source IP, which catches issues no checker can simulate.

SPF FAQ

Final words

SPF is the simplest piece of email authentication to set up, and one of the most consequential to get wrong. A correct record protects your domain, your recipients, and your reputation. A misconfigured one quietly sends your campaigns to the spam folder while you wonder what changed.

Three habits keep an SPF record healthy: (1) audit it whenever you add or remove a sending service, (2) count your DNS lookups every quarter, (3) read your DMARC reports, they tell you the truth about what’s actually happening in the wild.

Once SPF is solid, move on to DKIM and DMARC. Together, the three close the door on virtually all forms of domain impersonation.