SPF
sender policy framework / SPF record / too many DNS lookups / permerror
SPF is a DNS record listing which servers may send mail using your domain in the envelope sender. The specification caps it at ten DNS-querying terms, and receivers must return permerror if that is exceeded, which means the check fails. It does not check the From address a recipient sees.
The specification is precise about what is being authorized, and the precision matters. An SPF record declares which hosts are, and are not, authorized to use a domain name for the HELO and MAIL FROM identities. Microsoft spells out what MAIL FROM means in practice: the sender address used during the SMTP transmission, also called the 5321.MailFrom address, the P1 sender, or the envelope sender.
That is not the From address your recipient reads. SPF is checking the address the mail servers exchanged, which a person never sees. This is why SPF alone does not stop somebody putting your company in the visible From line, and why an alignment layer exists on top of it.
Now the part that breaks working setups. Some terms in an SPF record cause DNS queries: include, a, mx, ptr, exists, and the redirect modifier. The specification says implementations MUST limit the total to ten during evaluation, to avoid unreasonable load on the DNS, and that if the limit is exceeded the implementation MUST return permerror. The terms that do not query DNS, all, ip4 and ip6, are not subject to the limit.
Permerror is not a warning. The specification defines it as meaning the domain's published records could not be correctly interpreted, an error condition that definitely requires DNS operator intervention. Your SPF is not partially working at that point. It is not working.
In practice
The limit is crossed by doing something completely ordinary. Microsoft points out that nested include statements add lookups beyond the direct ones: an include pointing at a record that itself contains three more includes adds four lookups in total, not one. Every marketing tool, help desk, invoicing system and newsletter platform you authorize adds at least one. The fifth tool is often the one that tips a record over, and nothing in your inbox announces it.
Not the same as
- DKIM
- That signs the message itself. SPF authorizes sending servers, and the two check different things.
- The From address
- SPF covers the envelope sender. The name your customer sees is checked by a different layer.
Why it matters to you
SPF gets configured once, usually during a migration, and then nobody looks at it again while the business keeps adding tools. The failure mode is quiet, arrives months after the change that caused it, and looks like a general deliverability problem rather than a record with eleven lookups in it. It is also cheap to check and cheap to fix, which is an unusual combination.
What to ask or check
- 01How many DNS-querying terms does our SPF record evaluate to, counting nested includes?
- 02Does our record return permerror today, and who would notice if it did?
- 03Which tools are authorized in it, and are any of them no longer in use?
What people get wrong
That SPF protects the sender name people see. It authorizes servers for the envelope sender exchanged between mail systems, which no recipient ever reads.
Red flags
- An SPF record nobody has counted the lookups in since the last tool was added.
- Deliverability work proposed without anyone checking whether the record returns permerror.
- Authorized senders in the record that the business stopped using years ago.
Who owns it
Whoever controls DNS. The people who add new sending tools are usually not those people, which is exactly how the limit gets crossed unnoticed.
Where you will see it
As a TXT record starting v=spf1 on your domain, and in the authentication results header of any message you receive.