SPF Record: What It Publishes, and the Limit That Silently Breaks It

An SPF record is a DNS TXT record published at a domain, listing the servers that are permitted to send mail using that domain in the SMTP envelope. A receiving server reads the record, compares it against the address the mail actually connected from, and records a pass or a fail. SPF stands for Sender Policy Framework, and RFC 7208 states the arrangement in one line: "Compliant ADMDs publish Sender Policy Framework (SPF) records in the DNS specifying which hosts are permitted to use their names".

That is the whole definition, and the word carrying the most weight in it is envelope. SPF authenticates the return path the servers negotiate, not the From address the recipient reads, and almost every surprising SPF result traces back to that gap.

What is actually in the record

The record is a single line of text at the root of the domain, made of mechanisms and modifiers evaluated left to right until one matches.

ip4: and ip6: name addresses or ranges directly. include: hands the question to another domain's record, which is how a vendor gives you permission to send as you without either side sharing infrastructure. a and mx resolve the domain's own address and mail exchanger records. all at the end states what to do with everything that did not match, and its prefix is the part that matters: -all fails, ~all soft-fails, ?all is neutral.

An SPF include authorises a third-party sender by pointing at that sender's own record, and the receiver evaluates that record separately and uses only its verdict, so your own record gains no entries from it and an include whose target has no record of its own returns a permanent error for the whole thing.

A working record for a domain that sends through one platform is short, often a version tag, one include, and a closing all. Records get long because organisations accumulate senders, and the length is where the trouble starts.

1. Step 1Read the envelope

   The receiver takes the domain from the SMTP MAIL FROM command, which is the return path rather than the visible sender.

2. Step 2Fetch the record

   It queries the TXT record published at that domain and reads the mechanisms in order.

3. Step 3Compare the connecting IP

   Each mechanism is tested against the address the mail arrived from, and the first match decides the result.

4. Step 4Hand the result to DMARC

   A pass counts for the visible sender only if the envelope domain aligns with the From domain.

Why it matters: the limit nobody edits their way into

SPF has a hard ceiling that has nothing to do with the length of your record in characters. It counts DNS lookups performed while the record is evaluated, including every lookup inside every record yours points at, and RFC 7208 sets that ceiling in one sentence: "SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS." Exceed it and evaluation returns a permanent error rather than a verdict about your mail.

Two properties make this the most common structural failure in outbound authentication.

Includes are recursive, so the visible count understates the real one. An include: costs one lookup, and then the record it points at is evaluated against the same budget of ten. A vendor whose own record contains four includes costs you five rather than one, which is how a record with three visible entries sits at eleven.

Your budget is spent by other people. Vendors edit their SPF records without telling their customers, and the change lands on your domain as soon as caches expire. A record that evaluated cleanly in one quarter can fail in the next with nobody on your side having touched it.

There is a second, much tighter allowance underneath the headline one. The same specification holds what it calls void lookups, meaning queries that come back with nothing, to two. A retired vendor whose hostname no longer resolves spends one of those two, silently, and nothing in a DNS panel indicates it.

The cost of a permanent error is larger than losing SPF. DMARC passes when either SPF or DKIM passes and aligns, and that redundancy is the safety net. A record in permanent error removes half of it, so the entire result then rests on one DKIM signature, one selector and one key. When that signature breaks during a rotation or a platform change, there is nothing left to catch it.

Spends a lookupCounted toward the ten

• include
• a
• mx
• ptr
• exists
• the redirect modifier

Costs nothingUse as many as you need

• all
• ip4
• ip6
• the exp modifier

Separate ceilingsEasy to miss entirely

• Void lookups, which the specification holds to two
• A permanent error, which is scored as a failure rather than as a configuration fault
• Nothing in a DNS interface warns you about either

Where the textbook definition misleads

The received summary is that SPF stops people spoofing your domain. Four things narrow that considerably.

It never sees the address the reader sees. SPF authenticates the envelope, so a message can pass SPF outright on a domain the recipient has never heard of while displaying any From address the sender chose. The thing that ties a pass to the visible sender is DMARC alignment, and without it a pass protects nobody.

Forwarding breaks it, and forwarding is ordinary. A message redirected by a mailing list or a personal forwarding rule arrives from a server that is not in your record, so SPF fails on mail that is entirely legitimate. A steady trickle of such failures in your reports is normal rather than an attack, and it is the main reason DKIM is the more durable half of authentication on a portfolio of domains.

The closing mechanism is a policy choice most people never make. A hard fail with -all tells receivers to treat unlisted senders as unauthorised; a soft fail with ~all tells them to accept the mail and mark it. Providers weigh the two differently and neither is automatically right, but leaving the neutral ?all in place is a decision to publish a record that asserts nothing.

A pass is not a reputation. SPF tells a receiver which domain to hold responsible. It has no opinion about whether that domain is worth trusting, so an authenticated message from a domain with no history is authenticated and unknown at the same time, which is exactly the position a new sending domain starts from.

How it is used in outbound

For a programme sending from many domains, SPF stops being a setup task and becomes a property of the inventory. Every sending domain needs its own record, written for that domain rather than copied from the company's primary one, and the copy is the specific mistake worth naming. A primary domain's record carries years of accumulated vendors, none of which send from a new sending domain, and every one of them still counts against the ten. Twenty sending domains inherit one bloated record, and nobody audits twenty DNS records.

Google's sender guidelines put SPF at the entry bar rather than at the advantage: the requirement for every sender to Gmail accounts is stated as "Set up SPF or DKIM email authentication for your sending domains", with both plus DMARC required above the bulk threshold. Meeting it makes you eligible to be judged on reputation. It buys nothing else.

The practical work is verification rather than configuration. A sending platform showing a green tick is reporting on its own settings, not on what a receiver can resolve, and the two differ more often than anyone expects. Resolve every sending domain's record from outside your own network, expand every include by hand at least once so you know which vendor owns most of your budget, and treat eight terms as the working ceiling rather than ten, so that somebody else's routine expansion does not push you over.

Three fixes exist and they are worth trying in order. Remove what does not send, which on a purpose-built sending domain usually takes an inherited record from eleven entries down to two. Flatten an include into the address ranges it currently expands to, accepting that you have frozen a snapshot of somebody else's infrastructure and owe it a scheduled re-check. Or split senders across subdomains, since the budget applies per record evaluated. The mechanics of each are in the SPF records for cold email guide, and the full three-record setup is in SPF, DKIM and DMARC for cold email.

An SPF audit for one sending domain

• ✓Yes: Every include belongs to a service that genuinely sends using this domain
• ✓Yes: Includes for retired tools have been deleted
• ✓Yes: No mechanism points at a hostname that fails to resolve
• ✓Yes: The fully expanded term count sits at eight or below
• ✓Yes: The envelope domain aligns with the From domain, so a pass counts for DMARC
• ✕No: The record was pasted over from the primary company domain
• ~Depends: A flattened record has a named owner and a scheduled re-check

The failure this catches is quiet by construction. A record over the limit looks entirely ordinary in a text editor, produces no error anybody sees, and shows up in reporting as an SPF failure beside a DKIM pass, which is the same signature ordinary forwarding produces. That is why it gets waved through as forwarding noise for months. Reading the aggregate reports is what separates the two, and why DMARC fails covers the causes worth ruling out first. Where the diagnosis has to start from the outside, reading MXToolbox like a deliverability engineer covers the lookups that answer it.

Related terms

SPF is one of three records that make up email authentication, alongside DKIM, which signs the message rather than naming the path, and DMARC, which ties either result back to the visible sender. The identity SPF actually authenticates is the envelope sender, and the object the record belongs to is the sending domain. Return path is the same address under the name most platforms use for it.

The short version

An SPF record is a published list of who may send for a domain, evaluated against the envelope rather than against the address the reader sees. It is cheap to publish once and expensive to keep correct across an inventory that keeps changing, because the ten-lookup ceiling is spent partly by vendors you do not control and a breach produces a permanent error rather than a warning. Write a record per sending domain rather than copying one, expand it by hand, keep it at eight, and verify it at the published DNS rather than in the tool that claimed to write it.

RevenueFlow runs cold email and LinkedIn outreach for B2B teams on sending infrastructure we authenticate and monitor ourselves, one message per campaign. If you would rather that layer were somebody else's job, see how the campaigns work.

Verified as of mid-2026 against RFC 7208 and Google's sender guidelines. Verify current requirements with the source before making DNS changes.