SPF records: what they do, and the ten-lookup limit that breaks them
SPF lets a domain owner publish, in a DNS TXT record, exactly which servers are authorized to send mail as that domain, so receivers can check the HELO or MAIL FROM identity and decide whether to accept, flag, or reject a message. A domain must have only one SPF record, ending in "-all" if senders want unauthorized mail to face real scrutiny, and kept small enough to avoid DNS lookup and size limits (RFC 7208).
What an SPF record actually authorizes
SPF was built to solve a specific problem: any host injecting mail can put any domain name it wants in the SMTP session, and there was no standard way for a domain owner to say "only these servers send mail as me" (RFC 7208). An SPF record publishes that authorization in DNS. Receivers use it to check the "HELO" identity, the "MAIL FROM" identity, or both, and can then make a policy decision — accept, flag, or reject — based on the result (RFC 7208).
The record itself is a single text string published in a DNS TXT record. A domain must not have more than one SPF record that a check could select — publishing two causes ambiguity, not redundancy (RFC 7208). If a TXT record is split into multiple quoted strings, receivers concatenate them without adding spaces before evaluating, which lets you exceed the 255-octet limit on a single string while staying in one record (RFC 7208).
How to write one
A minimal record looks like this:
``` example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" ```
This has a version tag (v=spf1) and three directives: +mx (mail servers listed in the domain's MX records are authorized — the + is implied and usually omitted), a:colo.example.com/28 (a specific network block is authorized), and -all (everything else fails) (RFC 7208).
That trailing all mechanism matters. If you want receivers to be able to make a negative determination — to actually reject or flag mail that isn't from your listed servers — your record has to end in -all, or redirect to a record that does. Without it, there's no definitive statement of who isn't authorized, and mail spoofed from your domain gets no extra scrutiny (RFC 7208).
If a domain never sends mail at all — a parked domain, a subdomain used only for links — you can publish a record that says no host is authorized for that name, which closes off that domain as a spoofing target (RFC 7208).
Keep the record small
SPF records should stay small enough that a DNS query for them fits in 512 octets, to avoid tripping older DNS resolvers into TCP fallback (RFC 7208). RFC 7208 explicitly recommends that domain owners keep the DNS information needed to evaluate a record to a minimum, and points at include mechanisms and chained redirect modifiers as the usual source of bloat (RFC 7208).
The ten-lookup limit
SPF caps the number of DNS lookups a single check can use at 10. Mechanisms like a, mx, include, and exists, and the redirect modifier, each consume part of that budget — and include in particular pulls in another domain's entire SPF record, lookups and all (RFC 7208). Each include: adds its own chain of lookups on top of yours. RFC 7208 warns operators to watch this specifically because "include" chains and nested "redirect" modifiers are the easy way to blow past the limit without noticing (RFC 7208).
The fix is architectural, not clever syntax: audit which third parties actually need to send as your domain, drop the ones that don't, and flatten include chains where you can rather than layering vendor-provided snippets on top of each other.
What a receiver does with the result
A receiver evaluates your record and gets one of several defined outcomes (RFC 7208):
- Pass — the sending host is explicitly authorized.
- Fail — the sending host is explicitly not authorized.
- Softfail — a weaker statement that the host is probably not authorized; the domain hasn't published a hard
-all. - Neutral — the domain owner has explicitly declined to make a determination.
- None — no usable domain could be extracted, or no SPF record exists.
- Temperror — a transient DNS problem; the receiver may retry.
- Permerror — the published record itself can't be correctly interpreted, as defined in RFC 7208.
RFC 7208 sets no single required action for any of these — what a receiver does with a fail or a permerror is a local policy decision (RFC 7208).
SPF alone doesn't protect the address your recipient sees
SPF authenticates the "HELO" or "MAIL FROM" domain — not necessarily the domain in the visible From: header a recipient actually reads. DMARC was built to close that gap: it requires that the domain in the RFC5322.From field align with a domain that SPF or DKIM actually authenticated (RFC 7489).
That alignment can be checked in relaxed or strict mode. In relaxed mode, an SPF pass on bounces.example.com aligns with a From: address at example.com because they share the same Organizational Domain; in strict mode, it does not, because the domains aren't an exact match (RFC 7489). A domain that publishes SPF but no DMARC record has no way to require this check happen at all — an attacker can still spoof the From: address on a message that fails SPF outright, or send through a service that passes SPF under a different domain than the one shown to the recipient.
Frequently asked questions
Do I need SPF if I already have DKIM?
SPF and DKIM authenticate different things — SPF checks the sending server's IP against the HELO/MAIL FROM domain, DKIM checks a cryptographic signature tied to a signing domain. DMARC deliberately uses both because each one reduces the impact of the other's transient errors and configuration gaps (RFC 7489).
What happens if my SPF record has no -all?
Receivers can't make a negative determination about unlisted senders.
Can I have two SPF TXT records on the same domain?
No. A domain must not publish multiple records that could both be selected by a single check — the specification requires exactly one to be selected, and having more than one that qualifies is invalid (RFC 7208).
Why did my SPF check return "permerror" instead of "fail"?
Permerror means the published record itself couldn't be correctly interpreted — often because a lookup chain built from include and redirect mechanisms exceeded the evaluation limits, or the syntax is malformed. It requires the DNS operator to fix the record; a retry won't help, unlike a temperror (RFC 7208).
Does SPF alone stop someone from spoofing my company's name in the From: address?
Not by itself. SPF authenticates the HELO/MAIL FROM domain, which recipients typically never see (RFC 7208).
Where to start
Sources
---
_Researched with AI assistance from a live passive security scan run by NEL (scan eph_msicnkx9_1c25), which was not retained; citing 2 external sources; 29 factual claims were extracted and checked against their sources (29 of 29 verified); each verification step was independently recorded and signed by Vitna, which attests that the check ran and what its verdict was — not that the underlying claim is true (records 2ccbfab4-e789-448b-b500-d21fc8df0b92, cabee853-cb3d-4658-a431-f83f91443797, 677588cc-7489-4a62-a305-edf443271a79, +27 more, verify at https://vitna.costrinity.xyz/api/evidence/verify); reviewed and approved by nelprofs@gmail.com before publishing; published by NEL Professionals with no individual byline._
Get up to 100 scans or unlimited lifetime access starting at $15.
View Plans →Comments (0)
No comments yet. Be the first to comment!