What is SPF, and how does it authorize sending servers?

What an SPF record looks like

SPF is a single TXT record published at the root of the domain. Here is a typical example for a company that sends through Google Workspace, SendGrid, and one in-house server:

example.com.  IN TXT
  "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all"

Piece by piece:

• v=spf1 — the version. Every SPF record starts with this; it's how the receiver recognizes it.
• include:_spf.google.com — delegates to Google: "any server Google declares authorized for that subdomain is authorized for me too."
• include:sendgrid.net — the same for SendGrid, the email service provider.
• ip4:203.0.113.10 — one specific IP, the in-house server, hard-authorized.
• -all — the final qualifier: anything not listed above is strictly rejected.

One record, one line (even if we display it across several for readability). That's already the first trap: only one is allowed — more on that shortly.

The mechanisms, one by one

The inside of an SPF record is a sequence of mechanisms the receiver evaluates left to right until it finds a match:

• include: — delegates authorization to another domain. This is the most common mechanism: the provider (Google, Microsoft 365, SendGrid, Mailchimp…) publishes its SPF, and the record imports it. No need to know its IPs, which change: the provider keeps them current.
• ip4: / ip6: — authorizes one specific IP address or an entire block (e.g. ip4:203.0.113.0/24). Ideal for in-house servers, whose IPs are stable.
• a — authorizes the IPs in the domain's A (or AAAA) records. Handy when the web server also sends mail.
• mx — authorizes the IPs of the inbound mail servers (the MX records). Useful when the same machine both receives and sends.
• the final all qualifier — the safety net that decides the fate of everything else.

Each mechanism can carry a qualifier: + (pass, the default), - (fail), ~ (softfail), ? (neutral). In practice it only ever shows up on all, and the choice there is decisive:

• -all (hard fail) — anything not listed is rejected. This is the right target: a clear, defensible posture.
• ~all (softfail) — "probably not legitimate, but let it through with a mark." Useful during rollout, while the inventory is being finished.
• ?all (neutral) — no opinion. Publishing nothing amounts to the same thing; it protects nobody.
• +all — this one is never published. It authorizes the whole world to send for the domain. It's the equivalent of a wide-open door. Spotted anywhere, it calls for an immediate fix.

For the detail of each qualifier and the edge cases, we wrote a dedicated guide: understanding the SPF all mechanism.

The 10-DNS-lookup trap

Here is the most common mistake, and the most insidious because it is silent. RFC 7208 requires that evaluating an SPF record trigger no more than 10 DNS lookups. Every include:, every a, every mx counts as at least one lookup — and an include can itself contain more, cascading.

The tally adds up fast: Google Workspace consumes several lookups, the marketing provider a few, the billing tool more, customer support more… and the count crosses 10 unnoticed. Beyond that, the receiver returns a permerror (permanent error): SPF fails entirely, as if it didn't exist. Legitimate mail can then be flagged as suspect.

The trap is nasty because the record looks correct and works fine as long as the count stays under the bar — then one day a provider gets added, the limit falls, and everything breaks at once with no visible error. We cover diagnosis and causes in the SPF lookup limit, and for the error message itself, what an SPF permerror is walks through it step by step.

The fix is called flattening: greedy include: mechanisms give way to the corresponding ip4:/ip6: blocks, resolved once and for all. The lookups are saved at the cost of maintenance: when the provider changes its IPs, the record has to be regenerated. It's a trade-off to manage, explained in detail in our guide on flattening an SPF record.

Common traps beyond lookups

Two other mistakes break SPF quietly:

• Two SPF records on the same domain. The RFC is explicit: there must be exactly one TXT record starting with v=spf1. Publishing a second — often by adding a provider without touching the existing one — makes the receiver return a permerror, and both are ignored. The rule: merge everything into a single record. Two extra includes go into the existing line, not into a new one.
• +all by accident. We said it, but it bears repeating: it's the worst possible configuration. A +all (or an unqualified all under some readings) amounts to having no protection at all.

When a domain's state is unknown, guessing is the wrong move: reading a published record takes a few seconds. And for anyone juggling Microsoft 365 and Google Workspace, the special case of running both includes together is covered in SPF for Microsoft 365 and Google Workspace.

A concrete case: Microsoft 365 and Google Workspace

Here is a very common situation. A company migrates from Microsoft 365 to Google Workspace but keeps both live for a while. The record becomes:

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

Each of those two includes triggers several DNS lookups. With two major providers, half the 10-lookup budget is already gone. With billing, marketing email and support on top, the permerror is waiting. This is the textbook scenario where flattening one of the two includes becomes necessary — and where the reason the SPF lookup limit deserves watching before it bites becomes very concrete.

Why SPF alone isn't enough

Back to the distinction from the start: SPF validates the envelope (MAIL FROM / Return-Path), not the visible From:. So an attacker can configure perfect SPF for their own domain, pass the check without a hitch, and display someone else's domain in the From: the correspondent reads. SPF sees none of it: it never looked at that address.

This is a structural limit, not a bug. SPF does exactly what it's designed to do — verify who may send from a given IP for an envelope domain. It says nothing about the consistency between the envelope and the displayed From:. That consistency is called alignment, and it's DMARC that requires it.

The full trio works like this:

1. SPF — authorizes sending IPs (envelope side).
2. DKIM — attaches a cryptographic signature to the message, proving it wasn't altered and that it really comes from a given domain.
3. DMARC — ties SPF and DKIM to the visible From: and enforces alignment, then tells the receiver what to do on failure (none, quarantine, reject).

In other words, SPF is necessary but not sufficient. It's the foundation; DKIM adds the integrity proof; DMARC lays the roof that finally protects the address a human reads. Publishing a good SPF without DMARC is like locking a window while leaving the front door open.

The SPF roadmap

Publishing a clean, durable SPF record follows this order:

1. Inventorying the senders. Everything that sends in the domain's name goes on the list: mail, marketing, billing, support, internal apps. Some always get forgotten — DMARC reports help flush them out.
2. Publishing a single record starting with v=spf1, with one include: per provider and one ip4:/ip6: per in-house server.
3. Counting the lookups. The total stays under 10. Above it, the greediest includes get flattened.
4. Ending with -all as soon as the inventory is certain (~all serves as a cautious waypoint during validation).
5. Never two records, and never +all.
6. Following with DKIM, then DMARC — it's the only path to real protection.

None of this has to be done blind. A free, instant check of a domain's SPF, DKIM, and DMARC posture runs through our free DMARC analyzer: it shows the current SPF, counts the lookups, spots duplicates, and returns a clear grade. And when the moment comes to move from monitoring to real protection, Thomas, the virtual CISO, names every sender, generates the exact DNS to paste, and calls the timing to tighten without breaking a single legitimate email.

Free DMARC analysis of a domain — where the SPF stands, in seconds.