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

When a mail server receives an email that claims to come from your domain, it asks a very simple question: is the IP sending me this message allowed to send for that domain? Without an answer, anyone can pretend to be you. SPF — Sender Policy Framework, defined by RFC 7208 — is the first building block that provides one. You publish, in your DNS, the list of servers authorized to send on your behalf, and the receiver checks it. This guide explains what SPF is, what the record looks like, what the mechanisms mean, the infamous 10-lookup trap, and why SPF on its own does not protect what your recipient actually sees.

The problem SPF solves

Originally, the email protocol verifies nothing. Any server, anywhere on the Internet, can open a connection and declare "I'm carrying mail on behalf of your-domain.com." Nothing stops it, and nothing warns the recipient. That missing check is what made spam and spoofing trivial for years.

SPF closes part of that gap with a very simple idea: you alone control your DNS, so you alone can officially publish the list of your sending servers there. The receiver reads that list and checks whether the IP in front of it is on it. If it is, SPF passes; if not, SPF fails and the message becomes suspect.

What SPF really is — and what it actually checks

One detail is crucial and almost always misunderstood: SPF does not check the From: address your user reads in their mail client. It checks the message envelope — technically the MAIL FROM of the SMTP session, also called the Return-Path. That's the address bounces return to, and it is often different from the visible From:.

Concretely: an email can display From: accounting@your-company.com while carrying an envelope MAIL FROM: bounce@some-other-domain.com. SPF then validates some-other-domain.com, not your-company.com. That is exactly the gap an attacker exploits, and it's why SPF alone is never enough — more on that below. Keep this distinction in mind from now on: envelope ≠ visible From:. It explains half of all confusion about email authentication.

What an SPF record looks like

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

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

Let's break it down:

• 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, your email service provider.
• ip4:203.0.113.10 — one specific IP, your 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: you may only have one — 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: your provider (Google, Microsoft 365, SendGrid, Mailchimp…) publishes its SPF, and you import it. You don't have 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 your own servers, whose IPs are stable.
• a — authorizes the IPs in the domain's A (or AAAA) records. Handy if your web server also sends mail.
• mx — authorizes the IPs of your 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 you only ever see it 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 you finish inventorying everything.
• ?all (neutral) — no opinion. You might as well publish nothing; it protects nobody.
• +all — NEVER publish this. It authorizes the whole world to send for your domain. It's the equivalent of a wide-open door. If you spot it anywhere, fix it immediately.

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.

Add it up: Google Workspace consumes several lookups, your marketing provider a few, your billing tool more, your customer support more… and you cross 10 without noticing. Beyond that, the receiver returns a permerror (permanent error): SPF fails entirely, as if it didn't exist. Your legitimate mail can then be flagged as suspect.

The trap is nasty because the record looks correct and works fine as long as you stay under the bar — then one day you add one more provider, cross the limit, and everything breaks at once with no visible error. We cover diagnosis and causes in SPF: too many DNS lookups, and if you want to understand the error message itself, what an SPF permerror is walks you through it step by step.

The fix is called flattening: you replace greedy include: mechanisms with the corresponding ip4:/ip6: blocks, resolved once and for all. You save lookups at the cost of maintenance: if the provider changes its IPs, you have to regenerate. 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. If you publish a second — often by adding a provider without touching the existing one — the receiver returns 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.

If you don't know what state your domain is in, don't guess: check your SPF record in a few seconds. And if you're 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

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

your-domain.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, you're already halfway through the 10-lookup budget. Add billing, marketing email, and support, and the permerror is waiting for you. This is the textbook scenario where flattening one of the two includes becomes necessary — and where you understand, very concretely, why the SPF lookup limit deserves watching before it bites.

Why SPF alone isn't enough

Come 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 your domain in the From: your 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.

Your SPF roadmap

To publish a clean, durable SPF record, work in this order:

1. Inventory your senders. List everything that sends in your name: mail, marketing, billing, support, internal apps. You always forget some — DMARC reports help flush them out.
2. Publish a single record starting with v=spf1, with one include: per provider and one ip4:/ip6: per in-house server.
3. Count your lookups. Stay under 10. If you go over, flatten the greediest includes.
4. End with -all as soon as you're sure of your inventory (go through ~all while you validate if you prefer caution).
5. Never publish two records or +all.
6. Follow with DKIM, then DMARC — it's the only path to real protection.

You don't have to do all this blind. Run a free, instant check of your domain's SPF, DKIM, and DMARC posture with our free DMARC analyzer: it shows your current SPF, counts your lookups, spots duplicates, and gives you a clear grade. And when you're ready to move from monitoring to real protection, Thomas, your virtual CISO, names every sender, generates the exact DNS to paste, and tells you when to tighten without breaking a single legitimate email.

Analyze your domain for free → and see where your SPF stands in seconds.