40

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?

Improve this question
2
  • 10
    If they don't have an SPF record then you need to use a completely separate domain (or a subdomain of your existing domain name) with their service, or forgo SPF entirely. That's still a strange statement and it definitely makes me not trust their service.
    – Michael Hampton
    Dec 10, 2020 at 0:02
  • 2
    I've personally notice it trending downwards in importance relative to the other protection features, and I can image a near future where it's no longer relevant, but I wouldn't remove it just yet.
    – Joel Coel
    Dec 10, 2020 at 20:24

6 Answers 6

Reset to default
44

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.

Improve this answer
12
  • 2
    Interesting points, thanks. Btw that article has a screenshot described as "A modal that contains both SPF and DKIM settings" but the actual dialog shows two DKIM entries instead. The publish date is pretty dodgy... it was definitely live as early as 8th August.
    – RomanSt
    Dec 10, 2020 at 16:44
  • 1
    You hit all the important points. In addition, it's worth mentioning that mailchimp, and everyone in their line of business (sending email while maximizing deliverability) has a fundamental conflict of interest with respect to these technologies.
    – user1521620
    Dec 12, 2020 at 1:21
  • IOW No, they're not legacy. Don't take advice from a fox about how to guard a henhouse. By and large, these technologies were developed and championed by email recipients and entities providing services to them.
    – user1521620
    Dec 12, 2020 at 1:23
  • @MatthewElvey: It's not that straightforward, as SPF, DKIM and DMARC aren't against mass mailing nor even for fighting spam per se, but merely for anti-spoofing. Even spammers can buy their own domains and set up all these measures –and they do! For example, I recently noticed .icu being a suitable TLD for spammers just because it was so cheap.
    – Esa Jokinen
    Dec 12, 2020 at 8:51
  • The conflict of interest is fundamental. They're not merely for anti-spoofing. Why is that myopic? What's valuable is what happens once good actors have good reputations that spoofers can't spoof. What they do is make it more feasible to enforce negative consequences on bad actors by making good reputations more valuable and harder to steal. If an anti-spam system doesn't use these technologies to dynamically assign and act on the (relatively) unspoofable mail stream reputations they enable, it's defective.
    – user1521620
    Dec 12, 2020 at 19:57
22

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).

Improve this answer
4
  • 2
    I used imprecise terminology, unfortunately. The person I was corresponding with referred to it as "SPF txt record" and "SPF txt legacy value" so I'm pretty sure they meant the TXT record at all times, and not the now-retired dedicated SPF record type.
    – RomanSt
    Dec 11, 2020 at 11:08
  • 2
    Your history lesson is correct. However, there's no such problem with terminology: SPF records are officially called SPF records despite they are stored as TXT records. The RFC 7208, 3 defines SPF records this way: "The SPF record is expressed as a single string of text found in the RDATA of a single DNS TXT resource record; multiple SPF records are not permitted for the same owner name."
    – Esa Jokinen
    Dec 11, 2020 at 13:31
  • Indeed. This answer is incorrect, though the history is right.
    – user1521620
    Dec 12, 2020 at 1:02
  • Correct terminology or not, but this provides correct information answering the title question from a certain perspective and might be useful for readers.
    – Džuris
    Dec 12, 2020 at 12:29
11

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)

Improve this answer
2
  • 1
    This is an excellent observation! If they only were able to communicate this correctly... SPF is still useful and in use, but with Mailchimp sending "on behalf" DKIM becomes mandatory for a proper DMARC alignment.
    – Esa Jokinen
    Dec 11, 2020 at 16:59
  • I've enhanced my answer based on this observation and linked to this answer. +1
    – Esa Jokinen
    Dec 11, 2020 at 17:20
10

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.

Improve this answer
1
  • 10
    They only have expertise in email deliverability, but not in email security and anti-spoofing.
    – Esa Jokinen
    Dec 10, 2020 at 4:27
2

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.

Improve this answer
4
  • Nah. Like a gun, SFP is a tool. Don't walk around with one aimed at your foot (in other words don't serve a very badly written SPF record.) If you do, don't be surprised if you hurt yourself.
    – user1521620
    Dec 12, 2020 at 1:10
  • Do you have an example of well known services “including millions of ip addresses”?
    – eckes
    Dec 12, 2020 at 23:31
  • 1
    @eckes According to this post, it is even worse than that: “That means basically you explicitly allow billions of IP addresses to send email on your behalf …”
    – Brian Drake
    Dec 13, 2020 at 13:49
  • 1
    @eckes if you count ipv6 its easy :) otherwise I suspect the poster is exaggerating
    – mbrig
    Jan 20, 2021 at 4:40
2

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .