SPF is the oldest and simplest of the three email-authentication records, but its quirks trip up a lot of people — especially the silent 10-lookup limit. This guide explains what every part of an SPF record means, shows real examples, and covers the mistakes that quietly break it.

What an SPF record is

SPF (Sender Policy Framework) is a single DNS TXT record, published at your domain's root, that lists which servers are allowed to send email using your domain. When a receiving server gets a message claiming to be from you, it looks up your SPF record and checks whether the connecting server is on the list. A real example for a domain using Google Workspace:

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

Reading the syntax

An SPF record is a version tag, followed by one or more mechanisms (each optionally carrying a qualifier), evaluated left to right.

The version tag

v=spf1 always comes first and identifies the record as SPF. A domain must have exactly one SPF record — publishing two breaks SPF entirely.

Mechanisms

  • include: — authorise another domain's SPF, used to add a provider, e.g. include:_spf.google.com or include:sendgrid.net.
  • a — authorise the IPs in the domain's A/AAAA record.
  • mx — authorise the servers listed in the domain's MX records.
  • ip4: / ip6: — authorise a specific IP or range, e.g. ip4:203.0.113.10.
  • all — matches everything; always comes last and sets the default for anything not matched above.

Qualifiers (the prefix on all)

The character before a mechanism sets what happens on a match. On the final all it sets your default policy:

  • -all (fail) — anything not listed should be rejected. The strict, recommended setting once you're confident your record is complete.
  • ~all (softfail) — anything not listed is suspicious but accepted, usually marked. A safe starting point.
  • ?all (neutral) — no opinion. Offers almost no protection.
  • +all — authorise everyone. Never use this; it lets anyone send as you.

Putting it together: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all means "Google, SendGrid, and that one IP may send as me; treat everything else as softfail."

The 10-lookup limit — the most common silent failure

SPF allows a maximum of 10 DNS lookups while evaluating your record. Mechanisms like include, a, and mx each cost a lookup — and an include can trigger more lookups inside the included record. Exceed 10 and SPF returns a permerror, which most receivers treat as a failure. Your SPF effectively stops working, often with no obvious symptom.

It's surprisingly easy to hit: a handful of marketing tools, a CRM, and a help desk can blow past 10 between them. ip4: and ip6: mechanisms are free of lookups, so "flattening" — replacing includes with their resolved IPs — is one fix, at the cost of having to maintain those IPs by hand.

SPF and forwarding

SPF has a built-in weakness: when a message is forwarded, the forwarding server becomes the new sender, and your SPF no longer matches its IP — so SPF fails. This is by design and is exactly why DKIM and DMARC exist. DKIM survives forwarding because the signature travels with the message, which is why you should never rely on SPF alone.

Common SPF mistakes

  • Two SPF records. Only one v=spf1 TXT record is allowed. Merge them into one.
  • Forgetting a sending service. Every tool that sends "as you" needs to be in SPF, or its mail softfails/fails.
  • Using +all or leaving off all. Either way you've authorised the world.
  • Exceeding 10 lookups. Audit and trim regularly.
  • Treating SPF as enough. It isn't — pair it with DKIM and DMARC.

Check and build your SPF record

The SPF checker parses your record, counts your DNS lookups, flags syntax problems, and helps you build a correct one for your providers. For the bigger picture, see SPF, DKIM & DMARC explained and DKIM explained.