Are SPF records legacy?

I am responsible for a domain which has an SPF record as recommended by various other services that send mail on this domain's behalf.

When setting up Mailchimp, I was surprised to find no documentation on Mailchimp's recommended SPF setup. When I contacted support I was told that Mailchimp basically considers SPF legacy, hasn't used SPF for 6+ months, and thinks having the record doesn't help or hinder. Even going so far as suggesting that I delete our SPF record altogether.

I don't doubt that Mailchimp knows infinitely more about email deliverability than I do. But I find it surprising that Mailchimp wouldn't publish anything explaining this decision, especially considering that every other provider that sends email on our behalf continues to recommend the use of SPF, including G-Suite.

So what's going on, is SPF useless in 2020, should I worry about not having Mailchimp's servers in our SPF record, and should I consider deleting the SPF record altogether?

Solution 1:

As @jornane points out, Mailchimp uses their own domain as the envelope sender, making the SPF record of the customer's domain irrelevant for their delivery scheme. This makes DKIM signing indispensable for a proper DMARC alignment, as there wouldn't be alignment from the SPF side.

However, saying SPF is legacy is an odd statement considering they do have SPF set up for their own domain mailchimp.com. Despite not documented by themselves, according to DMARCLY's article on How to Set Up SPF and DKIM for Mailchimp (updated 9th Dec 2020) the correct SPF include for Mailchimp would be:

include:servers.mcsv.net

This SPF record is still in place and supposedly has the IP addresses they use:

"v=spf1 ip4:205.201.128.0/20 ip4:198.2.128.0/18 ip4:148.105.8.0/21 ?all"

I think this statement might come from the biased perspective the email delivery industry has about SPF, DKIM and DMARC. In their rhetorics those technologies are all about better reputation or optimized delivery. They only see them as tools for getting the message to the inbox, but not the other side of the coin that prevents others from spoofing mail from your domain. That's almost always the case when such a company tries to explain the benefits of those technologies. But those are not the real benefits nor the reason why they have been invented in the first place!

Mailchimp might just have taken this thinking further: "if SPF doesn't help us deliver our mail, it must be useless". In my opinion they are clueless if they really made such a statement. This kind of mindset is harmful, as it might even prevent their customers from moving towards a more strict DMARC policy. This was better explained by the observation that Mailchimp is using their own domain as the envelope sender.

Solution 2:

It’s a bit complicated due to the history of SPF, but:

• MailChimp is technically correct about the SPF record itself (as opposed to providing a TXT record with an SPF policy).
• They are almost certainly not suggesting that you stop using SPF altogether.

The original implementations of SPF looked for DNS TXT records on the domain itself fitting a specific format (starting with v=spf1 and containing the rest of a valid SPF policy). In 2005, IANA assigned resource record type 99 for a specific SPF record to theoretically replace this for providing an SPF policy (with the theoretical advantage that you can query for an SPF record specifically instead of having to query for all TXT records and then parse through all of them to see if there is a valid policy).

However, for compatibility reasons, actual usage of the dedicated SPF record type was never very high. Network operators had to still define a TXT record with the SPF policy so that legacy implementations of SPF would still work, and implementers had to support looking for the SPF policy in a TXT record to retain compatibility with existing networks, so neither side had any real incentive to switch exclusively to using the dedicated SPF record type, especially because most domains do not have large volumes of TXT records and therefore parsing a policy out of those is generally pretty quick.

As a result of that poor uptake, the SPF working group decided in 2014 to officially drop support for the dedicated SPF record type because it was not really contributing anything, wasn’t really used, and was in some cases causing confusion (such as the confusion here).

Thus, the SPF record is indeed deprecated, but providing an SPF policy in a TXT record is still highly recommended, even if your domain doesn’t actually handle email (in which case you should define a policy of v=spf1 -ALL).