Another day, another ESP telling a client to publish a SPF include for the wrong domain. It shouldn’t annoy me, really. It’s mostly harmless and it’s just an extra DNS look up for most companies. Heck, we followed Mailchimp’s advice and added their include to our bare root domain and it’s not really a huge deal for companies with only a couple SaaS providers. Still, it’s an incorrect recommendation and it does cause problems for some senders who are using multiple SaaS providers and Google.
Both Steve and I have written different posts about SPF over the years. In fact, the Authenticating with SPF: -all or ~all post is the most visited post on the blog. I’ve even written almost this same post, pointing out that a lot of ESPs have bad recommendations for SPF records. Steve’s written about the technical ins and outs of SPF records in DNS and how to stay under the 10 lookup limit. There’s also a time a client made a pretty huge mistake in their SPF record and a spammer took advantage and trashed their reputation.
There are also dozens of other good write-ups and discussions on how SPF works done by other deliverability experts, filtering companies, deliverability monitoring companies and the Open SPF folks themselves. Yet still so many places get it wrong.
One of the errors comes because a lot of folks, even a lot of email experts, don’t always know or remember that there are two separate yet equally important From: addresses in an email. One, called the envelope from or return path is defined by RFC 821 (and its successors 2821 and 5321). It’s used during the SMTP transaction and is where all the bounces go. The second is what most people think of when we talk about a From address. This address is defined by RFC 822 (and its successors 2822 and 5322) and is the what we see when we look at a message displayed in our email client.