SPF: ten DNS lookups, not eleven

by Francis Rozange | Sep 8, 2026 | Email Marketing

Abstract 3D render: a chain of ten glowing glass links, the eleventh bursting into particles

Your SPF record fits on one line. It declares who is allowed to send mail in your name, and it looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com ~all

Four providers, four includes, one perfectly readable line. And there is a good chance that record is invalid.

Ten, not eleven

The SPF standard, RFC 7208 published in April 2014, devotes its section 4.6.4 to DNS query limits. The text is not a recommendation:

“SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return ‘permerror’.”

Ten terms in total. The count covers the include, a, mx, ptr, exists mechanisms and the redirect modifier.

The count is recursive. An include pointing at a provider does not cost one query: it costs one query plus every query inside that provider’s own record. A serious mail host consumes three or four on its own.

Four providers are therefore often enough to exceed ten. That is why Microsoft takes the trouble to restate this limit in its requirements for volume senders: it is the most widespread failure in the trade.

A sub-limit slips past even more often: evaluating the mx mechanism must not trigger more than ten additional A or AAAA queries, under the same penalty.

Permerror is not a warning

The word sounds like a logging detail. It denotes an outright authentication failure.

An SPF in permerror does not pass. It therefore does not align in the DMARC sense. If your DKIM signature does not save the situation, your message fails DMARC, and the policy you published yourself is applied against you.

The trap is in when the failure appears. You changed nothing: your provider added an include to its own record, on a Tuesday, without telling you, because it opened a data centre. Your SPF line is identical to yesterday’s, and it became invalid overnight.

The mechanism the standard warns against in its own heading

Section 5.5 of RFC 7208 is literally titled: “ptr” (do not use).

The text matches: “This mechanism SHOULD NOT be published.” That is not an absolute ban, it is a formal discouragement, motivated by the mechanism’s slowness, its unreliability and the undue load it places on the servers of the .arpa zone.

A ptr in an SPF record is therefore an age marker: it signals a configuration written before 2014 and never reread since. It also consumes one of your ten queries.

The DNS record type that no longer exists

During its experimental phase, SPF had its own DNS record type, type 99. RFC 7208 ended that dual publication, in section 3.1:

“SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) only.”

The working group found that significant migration to the dedicated type was unlikely, and dropped support for it. If your zone still contains an SPF-type record, it has served no purpose for twelve years, and it can sustain the illusion of a redundancy that does not exist.

Flattening, and what it costs

Faced with the ten-query limit, one practice has spread: replacing include statements with the IP addresses they resolve to, resolved once and for all. The record then costs no recursive queries at all.

The technique works, and it moves the risk rather than removing it.

You take on the job of tracking your providers’ IP addresses. The day one of them adds a range, your messages sent from that range fail SPF, with nothing to warn you. You have traded a loud, immediate failure for a silent, delayed one.

That choice is defensible on one condition: that resynchronisation is automated and monitored. Flattening by hand, once, in 2023, is the worst of the options.

The structural fix lies elsewhere, and it is less technical: reduce the number of tools sending mail in your name. Every marketing team that signs up for a new tool consumes part of a budget of ten, and nobody in the company keeps that count.

What to do tomorrow morning

Count your queries, resolving each include recursively, not by counting the lines in your record. The result almost always surprises.

Then look for the word ptr and for the a mechanism used out of habit: those are two often useless queries, easy to give back.

Finally, list the legitimate senders on your domain. Not the theoretical list: the one that appears in your DMARC aggregate reports. There is almost always a forgotten tool, signed up for by a department that has since changed managers, occupying a slot in a budget of ten.

Sources

LaFactory works email on the evidence: headers, DNS records, rejection logs. No open rate promises, ever. Get in touch for a deliverability audit.