What is SPF? How SPF records work and where they break

SPF, the Sender Policy Framework, is how a domain tells receiving mail servers which machines may send mail in its name. It is one TXT record, defined in RFC 7208, and the idea fits in a sentence. The trouble is in the details: SPF checks an address most people never see, and a record can stop working without anyone editing it.

For how it fits with DKIM and DMARC, see SPF, DKIM and DMARC explained.

What does SPF check?

Before a message arrives, the sending server gives two names: its own, in the HELO or EHLO command, and a return address in MAIL FROM. That address is the envelope sender, also called the Return-Path, where bounces go.

SPF checks those two names and nothing else. A receiver checks the MAIL FROM domain, and RFC 7208 recommends checking HELO as well. On a bounce, where MAIL FROM is empty, it checks the HELO name instead.

The From line people read is not one of them. A message can pass SPF for bounces.example.net while its From line says [email protected]. DMARC closes that gap by counting an SPF pass only when the checked domain aligns with the From domain, which by default means the two share an organisational domain. RFC 9989, the DMARC standard since May 2026, uses only the MAIL FROM result, never HELO. What is DMARC? covers alignment in full.

Receivers usually check before the message itself is transferred. They read the checked domain's record from left to right, and the first mechanism that matches the connecting IP decides the result. If nothing matches, the result is neutral unless a redirect= takes over.

Do subdomains need their own SPF record?

Yes. The lookup is for exactly the name in the return address, so a record on example.com says nothing about mail.example.com. RFC 7208 recommends v=spf1 -all on names that send no mail, and v=spf1 a -all on each mail server's own host name.

What does an SPF record look like?

example.com.  TXT  "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 include:_spf.example.net ~all"

Every record is a TXT record that starts with v=spf1, followed by mechanisms and, conventionally, an all at the end. This one authorises two address ranges and every server the record at _spf.example.net passes, and soft-fails everyone else.

The qualifier sets the result of a match:

Why ptr is discouraged

RFC 7208 marks ptr "do not use", because it is slow and loads the reverse-DNS servers under .arpa. M3AAWG, the industry's anti-abuse working group, advises against a and mx too: use your provider's include, and ip4 and ip6 for your own servers.

include and redirect are not what they sound like

include does not copy the other record into yours. The receiver runs a separate check against the included domain, and the include matches only if that check passes, so a -all inside it never ends your check. The sharp edge: if the included domain has no SPF record, your whole check is a permerror.

redirect= is read only when nothing matched, hands over the whole result, and is ignored if the record has an all anywhere. It lets many domains share one record, and M3AAWG advises leaving it to advanced users.

What do SPF results mean?

SPF never says what to do with a failure. RFC 7208 leaves that to each receiver, and DMARC turns it into an instruction.

The SPF 10-lookup limit

Each include, a, mx, ptr, exists and redirect costs a DNS lookup, and RFC 7208 caps one check at ten, counting the lookups inside every included record. The eleventh is a permerror. M3AAWG warns that one include can cost several, because providers nest records of their own. So a provider adding a lookup to its own record can break yours.

A second limit catches records that point at nothing. A lookup that returns no records, or NXDOMAIN, is a void lookup, and RFC 7208 says receivers should allow only two, so a third is a permerror too. Void lookups come from names that do not exist, such as a retired service's or a mistyped one.

Long records hit one more limit. A TXT string holds 255 characters, so longer records are split into quoted strings that receivers join without spaces. End every string but the last with a space, and keep the whole answer under 512 bytes:

example.com.  TXT  "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 " "ip4:203.0.113.0/24 ~all"

To see where your own record stands, the deliverability checker follows every include and shows how many of the ten lookups you have used.

What is SPF flattening?

Flattening swaps each include for the ip4 and ip6 ranges it resolves to today, so the record costs almost no lookups. RFC 7208 prefers literal addresses where they are stable, but a provider's are not: Google says its outbound mail servers use a large range of addresses that change often. A flattened copy is right on the day you make it, and mail from new addresses fails until someone updates it. Tools that flatten again on a schedule fix that by becoming one more dependency.

Try two cheaper fixes first. Remove includes for services you no longer use: M3AAWG suggests an audit at least once a year. And check which domain each service puts in MAIL FROM, because an include on example.com only helps mail whose return address is on example.com. A service sending from news.example.com is checked against that name's record, which has ten lookups of its own.

Can a domain have two SPF records?

No. A name may have only one TXT record starting with v=spf1, and a receiver that finds two returns permerror, so neither counts. It happens when a new service's TXT record goes in beside the old one instead of into it.

Merge them into one record with every mechanism from both, one v=spf1 at the front and one all at the end, since anything after the first all is ignored. Other TXT records at the same name, such as verification tokens, do no harm.

Should SPF end in ~all or -all?

-all says unlisted servers are not authorised, and ~all says they probably are not. RFC 7208 lets receivers reject on fail but not on softfail alone, and M3AAWG notes that most receivers treat the two much the same, though some reject more readily under -all.

DMARC changed the calculation. RFC 9989 warns that a receiver running SPF first can reject a -all failure before it reads the From line. That loses mail DMARC would have passed on an aligned DKIM signature, forwarded mail included, and those rejections never reach your DMARC reports.

So on a domain that sends mail, pair ~all with DMARC at quarantine or reject, and keep -all for names that never send. Never use +all, which authorises the whole internet. And if you must include a platform shared with other senders, RFC 9989 suggests putting ? in front of it, so the platform's mail gets neutral and cannot pass DMARC as you through SPF.

Why forwarding breaks SPF

A forwarder sends the message on from its own IP address, often with the original MAIL FROM intact, so the final receiver finds the forwarder missing from the sender's record and gets fail or softfail. Three things help:

• SRS, the Sender Rewriting Scheme. The forwarder rewrites MAIL FROM to an address on its own domain that encodes the original, so SPF is checked against the forwarder and bounces find their way back. Microsoft 365 does this: a message from [email protected] that Alice forwards from [email protected] leaves as [email protected]. The From line is untouched, so the new pass does not align for DMARC.
• DKIM. The signature travels inside the message and survives as long as the signed parts are not changed. RFC 9989 requires it of every domain at p=reject. What is DKIM? explains how signing works.
• ARC. Each forwarder seals the authentication results it saw, as RFC 8617 defines, so the last receiver can see that SPF passed at the first hop and decide whether to trust it. Yahoo asks forwarders to implement it.

Is SPF required? What Gmail, Yahoo and Outlook.com ask for

The standard leaves SPF optional. The largest mailbox providers do not:

Gmail began ramping up enforcement in November 2025, with temporary and permanent rejections, and it counts volume by primary domain: cross 5,000 once and you are a bulk sender for good. Outlook.com rejects failing mail from those domains with 550 5.7.515. Even below the thresholds, Gmail may file unauthenticated mail as spam or reject it.

How to check your SPF record

Look the record up from a terminal:

dig +short TXT example.com

Then send yourself a message and find its Authentication-Results header:

Authentication-Results: mx.example.org; spf=pass smtp.mailfrom=bounce.example.com

smtp.mailfrom is the domain SPF checked. If it is not yours or a subdomain of yours, the pass belongs to someone else, and DMARC cannot count it for you. The deliverability checker does the lookup for you, counting through every include, and checks DKIM, DMARC, BIMI and MX in the same pass.

Where Nextmail fits

When you add a domain to Nextmail, the domain page lists every record to publish, with SPF in two places: on the domain itself, and on its return-path host, bounce. under your domain, which gets an MX record too. With the return-path records published, the envelope sender of your mail is on your own domain, so SPF can pass for a name that aligns with your From line.

The page checks each record against public DNS, shows what it found, and names the usual cause when SPF does not match, such as two v=spf1 records at one name. Connect a domain has the steps and a table of fixes, and Multiple domains covers how they are checked.

Incoming forwards are covered too: a message forwarded through Gmail, Microsoft 365, Fastmail or Zoho with an intact ARC chain, whose first hop saw it pass DMARC, is treated as passing DMARC even though SPF broke. The deliverability check also runs over the API, for checking domains from your own code.