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.
