SPF Fail: too many DNS lookups

I’ve had a couple folks come to me recently for help troubleshooting SPF failures. The error messages said the SPF record was invalid, but by all checks it was valid.
Eventually, we tracked the issue down to how many include files were in the SPF record.
The SPF specification specifically limits the number of lookups that can happen during a SPF check.

SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the “include” mechanism or the “redirect” modifier. If this number is exceeded during a check, a PermError MUST be returned. The “include”, “a”, “mx”, “ptr”, and “exists” mechanisms as well as the “redirect” modifier do count against this limit. The “all”, “ip4”, and “ip6” mechanisms do not require DNS lookups and therefore do not count against this limit. Processing limits

Some senders are using include: records that then have include: records that then have yet other include: records. Looking up all these include records caused the SPF lookup limits to be reached, thus causing the SPF lookups to fail (all the records can’t be pulled). Note, a lot of SPF checks don’t actually comply with the SPF spec in this area. Because of the spotty compliance, some too long SPF records won’t fail everywhere.
How can you fix this?

  • Prune unnecessary :include files from the SPF record.
  • Use different domains for mail from different places so you don’t need one SPF record to rule them all.
  • Don’t publish SPF records, rely on DKIM for authentication. Even Hotmail is checking DKIM these days.

If you need to find out how many lookups your SPF record entails you can use the SPF checker at emailstuff.org. Enter in a domain in the box and hit go. Then click on the “DNS” tab to see the actual DNS lookups that are happening. Each red domain is a separate DNS lookup.

Secureserver.net has a lot of include: files and a lot of lookups. Because this is a checking tool, it doesn’t limit the number of queries (because that wouldn’t be useful). But in places that are implementing the spec correctly, and are refusing mail based on SPF failures, secureserver.net would experience mail failures.

Related Posts

Gmail and the via

I was hoping to have a detailed post up today about the conditions where gmail presents the user with a “via” but time seems to have gotten away from me. But I can give you the conclusions.

Read More

DMARC: Please Be Careful!

(Cross posted from Spam Resource.)
Every couple of days, somebody new pops up on the DMARC-Discuss mailing list to ask some question or share an observation. It’s great to see people interested and joining the conversation. Clearly, DMARC interest and adoption are growing. What’s really frustrating, though, is that for about a quarter of the new subscribers, their first mailing list message goes to the spam folder in my Gmail account. It has become sort of an intelligence test I apply to new subscribers — I’ve stopped digging those messages out of the spam folder. I’m figuring that if they can’t figure out how to implement a DMARC record, or they don’t understand that it’s not really compatible with mailing lists nor is it meant for hobbyist domains, then I think perhaps they’ve got some things they’ve got to figure out before they’re ready to join the discussion.
To that end, let me take a moment to jot down some recommendations for folks who are considering implementing DMARC.

Read More

DMARC: an authentication framework

A new email industry group was announced this morning. DMARC is a group of industry participants, including large senders, large receivers and relevant intermediaries working on a framework to reduce the harm from phishing.
DMARC is working on a standard to allow senders to publish sending policies and receivers to act on those policies. Currently, senders who want receivers to not deliver unauthenticated email have to negotiate private agreements with the ISPs to make that happen. This is a way to expand the existing programs. Without a published standard, the overhead in managing individual agreements would quickly become prohibitive.
It is an anti-phishing technique built on top of current authentication processes. This is the “next step” in the process and one that most people involved in the authentication process were anticipating and planning for. I’m glad to see so many big players participating.
 

Read More