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?
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:This SPF record is still in place and supposedly has the IP addresses they use:
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.It’s a bit complicated due to the history of SPF, but:
SPFrecord itself (as opposed to providing aTXTrecord with an SPF policy).The original implementations of SPF looked for DNS
TXTrecords on the domain itself fitting a specific format (starting withv=spf1and containing the rest of a valid SPF policy). In 2005, IANA assigned resource record type 99 for a specificSPFrecord to theoretically replace this for providing an SPF policy (with the theoretical advantage that you can query for anSPFrecord specifically instead of having to query for allTXTrecords and then parse through all of them to see if there is a valid policy).However, for compatibility reasons, actual usage of the dedicated
SPFrecord type was never very high. Network operators had to still define aTXTrecord with the SPF policy so that legacy implementations of SPF would still work, and implementers had to support looking for the SPF policy in aTXTrecord to retain compatibility with existing networks, so neither side had any real incentive to switch exclusively to using the dedicatedSPFrecord type, especially because most domains do not have large volumes ofTXTrecords 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
SPFrecord 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
SPFrecord is indeed deprecated, but providing an SPF policy in aTXTrecord is still highly recommended, even if your domain doesn’t actually handle email (in which case you should define a policy ofv=spf1 -ALL).The way MailChimp sends out mailings is not compatible with SPF, so it makes sense for them to deprecate it, in the context of them sending on your behalf the way they do.
MailChimp wants to handle bounces for you, which requires them to set the Envelope From address to their own domain, which means that SPF should be checked against their domain, not yours. Thus it makes no sense for them to ask you to allow them in your SPF policy. This is also why some clients show “via mailchimp” in the From field.
SPF is not deprecated, but it is not suitable for mailing lists and similar cases. DKIM works on the From header and is cryptographically signed by the sender, so it is more resistant to forwarders and is easier to delegate to third parties. It makes more sense for MailChimp to focus on that.
For your own outgoing mail servers, you should maintain SPF, DKIM and DMARC (the third you get essentially for free by doing the first two right)
This is just one vendor's opinion.
Yes, they have specific expertise in email deliverability, but so do many other vendors who continue to recommend the use of SPF records.
Having a properly constructed SPF record isn't going to have a negative impact on your email deliverability. Including Mailchimp in your SPF record isn't going have a negative impact on your email deliverability... so if it were me, I'd continue to maintain a properly constructed SPF record.
In addition to the (mostly correct) other answers, there's another point to consider regarding SPF.
When you use external services to send email on your behalf, or have your email setup in a cloud service, and you have SPF in place, you need to include those services SPF records in your own.
Most of those services now use big cloud providers, and thus their own SPF record include really huge blocks of IP - basically all of those giant providers IP spaces.
That means basically you explicitly allow billions of IP addresses to send email on your behalf, and spammers do use those IP addresses (either sending email from compromised VMs in the cloud, hacking into M365 email accounts, or spawning temporary VMs in those services).
So you end up explicitly allowing spammers to send email in your name!
Due to this SPF alone is worse than no SPF.
It is now necessary to use DKIM and DMARC to counter this phenomena.
As explained by jormane, when sending via Mailchimp, the SPF record for your domain does not need to include their servers, given the way they do it.
However, for other e-mail, there are indeed lots of mail servers out there that actually check SPF records when they receive mail. Policies vary, but you can expect that:
If you don't have an SPF record at all, then some servers will give a bad score to your e-mail by default. They may have heuristics which negate this effect if the address of the server matches one of the MX records or something similar, but you may have e-mail being silently pushed to the junk mailbox of many recipients.
If you have an SPF record which does not include the sending server, then there are many servers which will either outright reject the e-mail or give it a bad score.
Both of these are definitely still true today, and I'm pretty sure they still apply to some very large e-mail providers.
So not having an SPF record, or worse still, having one not including the relevant servers will most definitely have a detrimental effect on your deliverability. This may be slowly going away to favour DKIM or to pay attention to what the DMARC record says, but at this time it's definitely not a good idea to not have correct SPF records if you want your e-mails to have a chance of reaching their destination.