Learn · Email authentication

What is SPF?

SPF (Sender Policy Framework) is a DNS record that lists the servers allowed to send email on your domain's behalf. Receivers check the connecting server against that list. It's the oldest of the three email authentication standards — simple to publish, easy to get subtly wrong.

How it works

When a mail server connects to deliver a message, the receiver sees two things: the connecting server's IP address, and the envelope sender — the address in the SMTP MAIL FROM command (also called the Return-Path, where bounces go). SPF (RFC 7208) has the receiver look up a TXT record on the envelope sender's domain and check whether the connecting IP is on the list.

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

This record says: Google Workspace's servers and the IP 203.0.113.7 may send for example.com; everything else should fail.

Syntax: mechanisms and qualifiers

Element	Meaning
`ip4:` / `ip6:`	Authorize an IP address or CIDR range directly. The cheapest mechanism — no extra DNS lookup.
`include:`	Pull in another domain's SPF record — how you authorize Google, Microsoft 365, or an ESP. Costs a DNS lookup.
`a` / `mx`	Authorize the domain's A or MX hosts. Each costs a lookup and is rarely what you actually mean.
`all`	Matches everything; always last. The qualifier in front of it sets your default verdict.
`-all`	Hard fail: unauthorized mail should be rejected by SPF-only filters.
`~all`	Soft fail: treat with suspicion. With DMARC in place, `~all` vs `-all` matters much less — DMARC's own policy takes over the "what to do" decision.
`+all`	Authorizes the entire internet to send as you. Never publish this.

The 10-lookup limit

Evaluating an SPF record may cost at most 10 DNS lookups — every include:, a, mx, and redirect= counts, including the ones nested inside each include. Go over and receivers return permerror, which DMARC treats as a failure. This bites real companies constantly: sign up for a handful of SaaS tools, add an include for each, and one day mail starts soft-failing for no visible reason. Count your lookups (flattening rarely-changed includes into IPs is the usual fix), and remember a domain must have exactly one SPF record — two records is also a permerror.

Where SPF falls short

Forwarding breaks it. When mail is forwarded, the new server delivers it from an IP that isn't in your record, so SPF fails on perfectly legitimate mail. This is the problem DKIM (and for intermediaries, ARC) exists to solve.
It checks the wrong From. SPF validates the envelope sender — which recipients never see. A phisher can pass SPF with their own domain in the envelope while displaying yourbank.com in the visible From header. Only DMARC's alignment requirement — the SPF-passing domain must match the visible From domain — closes that hole.
Hard to diagnose. A source failing both SPF and DKIM is not automatically an attack — forwarding, an unaligned vendor and real spoofing all look alike in a report until you separate them. Telling the three apart is most of the work of reading DMARC data.
No reporting. SPF alone gives you zero feedback. You find misconfigurations when customers stop receiving your invoices. DMARC's aggregate reports show you every SPF result for mail claiming your name.

Rule of thumb: SPF answers "which servers may send for this domain?" It cannot answer "is the From address the user sees genuine?" — that's DMARC's job, using SPF as one of its two inputs.

Checklist

One SPF record per domain, starting v=spf1, ending ~all or -all.
Include every legitimate sender: your mail platform, marketing tools, billing, support desk. Your DMARC reports will reveal the ones you forgot.
Stay under 10 lookups.
For ESP mail, set up the custom Return-Path (bounce) domain they offer — without it, their mail can pass SPF yet still fail DMARC alignment.