InboxRatio
Check your domain

Glossary term

SPF records: syntax, the 10-lookup limit, and quiet failures

What an SPF record is

An SPF record is a DNS TXT record that lists which mail servers are allowed to send email on behalf of your domain. SPF stands for Sender Policy Framework, defined in RFC 7208. When a receiving server gets a message claiming to come from your domain, it looks up your SPF record and checks whether the connecting IP address is on the list.

A real-world record looks like this:

v=spf1 ip4:192.0.2.10 include:_spf.google.com include:sendgrid.net ~all

Translated: mail from the IP 192.0.2.10 is authorized, mail from anything Google Workspace or SendGrid authorize on their side is authorized, and everything else should be treated with suspicion (~all, a softfail).

One clarification that saves confusion later: there is no separate "SPF record type" in modern DNS. An earlier dedicated record type was tried and retired; today an SPF record is always a TXT record on the bare domain (or on a subdomain, if that subdomain sends mail under its own name). A domain gets exactly one.

How an SPF record differs from DKIM

SPF and DKIM are the two authentication mechanisms DMARC builds on, and they verify different things through different means.

SPF is about the path: it validates that the server which physically connected and said MAIL FROM:<you@yourdomain.com> is one your domain authorized. It checks the envelope sender — the bounce address set during the SMTP session — not the From header a recipient sees. Nothing about the message content is examined.

DKIM is about the content: a cryptographic signature over selected headers and the body, verifiable regardless of which server delivered the message.

The practical difference shows up in transit. Forward a message and SPF breaks — the forwarding server is not in the original domain's record — while a DKIM signature usually survives untouched. This is why a mature setup always runs both: SPF fails on forwarding, DKIM fails when content is modified, and DMARC needs only one of them to pass with alignment.

How an SPF record works

Evaluation happens during the SMTP conversation, before the receiving server has even accepted the message body. The receiver takes the envelope sender's domain, fetches its TXT records, finds the one starting v=spf1, and walks it left to right until a mechanism matches the connecting IP.

The mechanisms you will actually see:

  • ip4: / ip6: — a literal address or CIDR range. Cheapest to evaluate; no extra DNS work.
  • include: — evaluate another domain's SPF record as part of yours. This is how every ESP and hosted mail provider gets authorized.
  • a and mx — authorize the IPs behind the domain's A or MX records.
  • all — the catch-all terminator, whose qualifier sets the default verdict: -all (fail — reject unauthorized sources), ~all (softfail — suspicious but not conclusive), ?all (neutral — says nothing), and +all (authorize the entire internet; never publish this).

The verdict — pass, fail, softfail, neutral, or one of two error states — feeds into the receiver's filtering and into DMARC evaluation. For DMARC, a pass counts only if the envelope-sender domain also aligns with the From header domain. This is where many ESP setups silently fall short: the platform passes SPF using its own bounce domain, alignment fails, and your DMARC compliance rests entirely on DKIM.

Two error states matter operationally. Permerror means the record is structurally broken — unparseable, duplicated, or over the lookup limit — and many receivers treat it as harshly as a fail. Temperror means DNS did not answer in time. You can see how your record parses, and what it resolves to mechanism by mechanism, with an SPF checker.

SPF records and your deliverability

A correct SPF record is table stakes. Google Postmaster guidelines and the Yahoo Sender Hub both list SPF (together with DKIM) among the baseline authentication requirements for senders, with DMARC layered on top for bulk volume. Mail without it is not automatically rejected everywhere, but it starts every filtering evaluation with a handicap and cannot contribute to DMARC.

The deliverability failure pattern worth internalizing is the 10-lookup limit. RFC 7208 caps SPF evaluation at ten DNS-querying mechanisms — include, a, mx and friends — counted recursively through every nested include. Providers nest their own includes, so a single include: can cost three or four lookups on its own.

The way it actually breaks: your record has held steady for years at eight lookups. Marketing signs up for a new tool, IT pastes in one more include: per the vendor's setup guide, the count crosses ten, and evaluation now returns permerror — for every message, from every source, including the ones that worked yesterday. Nothing alerts you. Placement erodes across the board, and because the record looks fine at a glance, diagnosis often takes weeks. Count lookups every time the record changes; any competent checker reports the number.

The other quiet degradation is the qualifier. ~all versus -all is a long-running debate, but publishing ?all — or worse, +all because a troubleshooting session once suggested it — tells receivers your record carries no information, and some score that against you.

Limitations and failure modes

Forwarding breaks SPF by design. The forwarder's IP is not in your record. Not fixable from your side; this is why DMARC accepts DKIM as the alternate path and why SPF alone was never enough.

The 10-lookup ceiling. The failure story is told above; what belongs here is mitigation: replace deep includes with ip4: ranges where a provider publishes stable ones, drop mechanisms for services you no longer use, or use SPF flattening — with the caveat that flattened records go stale the moment a provider rotates IPs, so flattening without automated refresh trades one silent failure for another.

Multiple SPF records. Two TXT records both starting v=spf1 is a permerror, full stop. It happens most often when a website migration tool or a second team adds "their" record without checking for an existing one.

The 255-character string limit. A TXT record string tops out at 255 characters; longer records must be split into multiple quoted strings within the single record. Some DNS panels handle this automatically, some corrupt the record instead. Verify after publishing, not just before.

Stale authorizations. The include: for the ESP you left in 2022 still authorizes that platform's shared infrastructure to send as your domain. SPF hygiene is subtractive as much as additive — audit annually and remove what no longer sends.

SPF says nothing about the visible From. A passing SPF check validates the envelope sender only. Anti-spoofing protection for the address recipients actually read requires DMARC alignment on top.

Related terms

DKIM, DMARC, SPF alignment, MX record, hard bounce, sender reputation, suppression list.

Frequently asked questions

How do I check if my domain has an SPF record? Query your domain's TXT records and look for the one beginning v=spf1 — or run the domain through an SPF checker, which also counts DNS lookups and flags syntax errors.

Should I use ~all or -all? -all states your policy without ambiguity and is the right endpoint once you are certain the record covers every legitimate source. ~all is a reasonable stage while you verify. In a DMARC-enforced world the practical difference between them has narrowed, because DMARC's policy — not SPF's qualifier — decides the message's fate.

Can I have two SPF records on one domain? No. Two records starting v=spf1 produce a permanent error and can be treated as a failure. Merge all mechanisms into a single record.

Does SPF cover subdomains? No — each subdomain that sends mail under its own name needs its own record. A missing subdomain record returns "none", not the parent's policy.

Why did SPF break when I added a new email tool? Almost certainly the 10-lookup limit. Each include: costs at least one lookup and often several through nesting. Count them; if you are over ten, every check now returns permerror.

Does passing SPF mean my email reaches the inbox? No. SPF removes one reason to distrust the message. Placement decisions also weigh domain and IP reputation, engagement and content — which is why we measure actual inbox placement rather than authentication status alone.

Before you touch the record next, note your current lookup count — and if you are building one from scratch, the SPF generator produces correct syntax for the common provider combinations.

Sources