People sometimes run into the "too many DNS lookups" error when rolling out SPF (Sender Policy Framework). It doesn't help that there is a lot of bad guidance on the Internet. This article describes how to fix this issue. Read the rest of this entry »
People sometimes write in and ask "what is the impact of a broken SPF record"?
The net effect of a broken SPF record is that receivers can't reliably use SPF to determine the legitimacy of the domain's email. *Some* receivers might ignore the broken parts of an SPF record and keep checking, but out of the box all SPF implementations will barf, and you'll be left with a record that is introducing uncertainty into email performance.
We've discovered an odd story related to SPF deployment. When delivering a lot of email, you need an SPF record just to get to the welcome mat. What happens is that new senders go through their pre-flight check list, start sending with working SPF records, and things operate in a nice steady state for a while.
Over time, the servers that are authorized using SPF earn enough good reputation so that senders get through the front door and into the content-based/user-engagement world. At any time, SPF records may get extended until they break or become inaccurate, but since the original set of authorized servers already has a good enough reputation, the inaccurate/broken SPF records do not cause too much trouble. This is how SPF has traditionally been used prior to DMARC. In this way, SPF might have been a "reputation bootstrapping tool".
Unfortunately, when SPF breaks, the newly authorized servers are left out in the cold. People then hire deliverability experts, build volume ramps, and chase symptoms as most of their email is doing OK. Worse is the resulting notion that email infrastructure is a heavy weight and cannot be replaced or upgraded without serious investment.
DMARC changes the above story in a very significant way. First is visibility — you can actually see what is going on and where SPF isn't performing like it should. Second is that SPF results now matter in terms of email content and identifier alignment. In sum, accurate SPF records are no longer a "reputation bootstrapping tool", but necessary for reliable email delivery.
If you publish an SPF record and use the "a" mechanism, but your domain doesn't actually have a "A" record in place, then you'll see this warning.
Here's a sample SPF record that contains the "a" mechanism (the "a" is in bold):
v=spf1 a include:_spf.google.com ~all
The "A" DNS record is how you use the DNS to associate an IP address with your domain. The "AAAA" DNS record (also called "quad-A") is used to associate an IPv6 address with your domain.
If you don't have an IP address associated with your domain, then you shouldn't use the "a" mechanism in your SPF records. This might be case if you're only using your domain for email.