SPFSender Policy Framework
SPF is a list, published in your DNS, of every server allowed to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from you, it checks the sending server's IP address against that list — pass if it's there, fail if it isn't.
It sounds simple, and the record itself is simple. What isn't simple: every mail tool you use — your email provider, your CRM, your help desk, your marketing platform — needs to be on that list, and each one you add costs part of a strict budget most people don't know exists until it's already broken.
The SPF DNS record
SPF is a single TXT record at the root of your domain (RFC 7208), not a subdomain like DMARC. A typical record looks like v=spf1 include:_spf.google.com include:mail.vendor.com -all. v=spf1 must come first. Each include pulls in another domain's authorized senders. The record ends in an "all" mechanism: -all (hard fail — reject anything not listed), ~all (soft fail — accept but mark), or +all (authorize everyone, effectively disabling SPF — a serious misconfiguration).
The 10-lookup limit — SPF's most common failure
RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS lookups total. Every include, redirect, a, mx, ptr, and exists mechanism counts against that budget — and includes nest: your CRM's include might itself include three more domains you've never heard of. Cross the limit and the entire record returns permerror, which most receivers treat as an outright SPF failure — silently, with no error visible in your inbox, until deliverability quietly drops.
Only one SPF record is allowed
Multiple TXT records starting with v=spf1 on the same domain make SPF evaluation undefined per RFC 7208 — receivers may pick either, or fail closed. If you need to combine sender lists (e.g., after a merger or when a vendor tool auto-adds its own record), they need to be merged into a single record, not left as two.
Flattening: the fix, and its cost
Flattening replaces include: mechanisms with the actual IP ranges they resolve to, cutting a record from ten lookups to one or two. It solves the limit — but a flattened record goes stale the moment a vendor changes their sending IPs, silently breaking authentication for that vendor's mail until someone notices and re-flattens. Flattening is a maintenance commitment, not a one-time fix.
How Trustliant handles this
Trustliant resolves the entire SPF include tree recursively — nested includes and all — with cycle detection, and shows exactly where the ten-lookup budget goes: which vendor include costs what, and which look stale. It flags +all records, duplicate SPF records, and permerror conditions automatically, and presents flattening as a monitored, reversible recommendation with the ongoing maintenance cost stated up front — not a silent record rewrite.
Questions we get about SPF
- Why did my email stop authenticating with no error message?
- The most common cause is crossing the SPF 10-lookup limit — adding one more marketing or sales tool tips the record into permerror, which most receivers treat as a hard SPF failure. Nothing in your inbox tells you this happened; it shows up as declining deliverability instead.
- Do I need SPF if I already have DKIM?
- DMARC passes if either SPF or DKIM aligns, so technically a domain can pass DMARC on DKIM alone. In practice, most mail platforms and receivers still expect a valid SPF record, and some intermediate systems (mailing lists, forwarders) break DKIM signatures but leave SPF-style checks intact, so publishing both is the resilient default.
- What does ~all vs -all actually change?
- Both fail unlisted senders under SPF alone, but -all (hard fail) is unambiguous, while ~all (soft fail) leaves receivers free to accept and merely flag the message. Most DMARC guidance recommends -all once you've confirmed every legitimate sender is listed.