[Top] [All Lists]

Re: [ietf-smtp] SPF DNS query limits

2016-05-23 11:46:06

On May 23, 2016, at 7:52 AM, Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk> 

In RFC 7208 section 4.6.4 we're told that the SPF implementation should limit 
the number of include, a, mx, ptr and exists to 10, and if that limit is 
exceeded then we MUST return a 'permerror' result.

1) is this limit of 10 for the whole evaluation process, or does it restart 
for each 'include'/'redirect'? I've presumed it's for the whole process 
otherwise the total number of DNS queries is effectively unlimited if you 
have many nested includes, and the purpose of that section seems to be to 
limit them.

It's for the whole process, excluding A queries triggered by mx: entries, IIRC. 
(Pretty much, read the RFC if you want the gory details

2) Is this limit generally being stuck to by SPF evaluation functions?

It's hard to say overall, as SPF is almost never used on it's own to make 
delivery decisions. suggests that it's not 
something that's causing spectacularly bad delivery problems or ebay would have 
fixed it.

It's exacerbated by many DNS records being less than half full - either because 
people (or "wizards") generating them don't know that you can have more than 
250 characters in a record, or because they're using DNS management web 
interfaces that don't allow them to do so. That leads to more include records 
needed and so more queries. Running some commonly used included records through 
the (fairly crude) minimizer at 
suggests it's bloating by a factor of about two, on average.

And that's not the only common SPF mistake made that bloats records.

The reason I ask is that our SPF implementation is regularly hitting this 
limit (eg one or two per minute on a low volume server).

For instance, we got a spam message claiming to come from (chosen 
at random from our incoming messages). That results in:

- - contains "a mx ptr" - so that's 4 
- - contains "" - so that's 
- - contains "" - so that's 7
- - contains "" - 
that's 8
- - contains "a:..." - that's 9
- - contains "" 
- that's 10
- - contains "" 
- that's 11

(there are more includes after that, but our evaluator has given up by now. 
In fact, the source IP address was not listed on any of the SPF records, so 
would have resulted in a FAIL if it had got that far).

The SPF spec says immediate FAIL with too many DNS queries, regardless of 
whether you found a match. I appreciate the intent, but given the number of 
includes that are required if you're outsourcing multiple services (and need 
the return path to point back at you) the limit of ten queries is a bit of a 

Given SPF only affects the return path, it's not actually required to include 
an outsourced providers SPF includes if the bounces go back to them (which they 
usually do). At least until you get into wanting custom return paths because 
you want DMARC-esque alignment, so as to get the delivery benefits of that...

ietf-smtp mailing list