39

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?

RomanSt
  • 1,207
  • 1
  • 15
  • 32
  • 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 '20 at 00: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 '20 at 20:24

6 Answers6

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.

Esa Jokinen
  • 46,944
  • 3
  • 83
  • 129
  • 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](http://web.archive.org/web/20200811191823/https://dmarcly.com/blog/how-to-set-up-spf-and-dkim-for-mailchimp). – RomanSt Dec 10 '20 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 '20 at 01: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 '20 at 01: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](https://blocked.icu/) being a suitable TLD for spammers just because it was so cheap. – Esa Jokinen Dec 12 '20 at 08: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 '20 at 19:57
  • Evidence that sometimes even spammers set up all these measures is not sufficient to disprove that. If it's happening a lot, that suggests that there are a significant number of systems that are defective in the way I describe. – user1521620 Dec 12 '20 at 19:58
  • Consequences and Enforcement. **************** What I realized after years of anti-spam work, years ago, is what I think is the best way to think about spam fighting. Better rules and better ways of enforcing them. I realized that I was able to define all solutions that avoid being whack-a-mole efforts with just two words. Consequences and Enforcement. Let me try to explain and convince you: – user1521620 Dec 12 '20 at 20:16
  • For an effective anti-spam system, all you need is a PRACTICAL system for enforcing meaningful consequences for abuse. Argument: Think in sequence as a spammer, as an ISP, as a source of email. If there is a practical enforcement system that will reliably impose meaningful negative costs on me the more I am a direct or indirect source of abuse, and reliably provide positive incentives the higher the quality of the mail sourced to me, there is an adequate persistent force on me to not be a bad actor. – user1521620 Dec 12 '20 at 20:31
  • In other words, what the world needs is a more purposefully refined version of a crude structure that is built and already operating and having a huge impact. A system of Consequences and Enforcement It is a (very highly, perhaps approaching maximally) automated structure with two key systems that can only work together. One is very carefully designed to perform extremely efficient automated enforcement of measured negative consequences. The other is the set of rules strategically designed to make part one practical. The rules, the consequences. – user1521620 Dec 12 '20 at 20:46
  • For decades it has been a game of whack-a-mole. The reason the amount of spam in inboxes plummeted with the arrival of these technologies is that they each provide a tighter fit between consequences and enforcement. Does my explanation resonate? Convince you? – user1521620 Dec 12 '20 at 20:49
  • Don't know yet. It was a bit strange monologue that seems a little out of context. :) – Esa Jokinen Dec 12 '20 at 20:56
  • Mailchimp does allow the users to add the user's own `header.from`, which will make DMARC alignment checks fail. I'm leaving this as a comment because my memory might be incorrect on the details, but I have seen mail without a DKIM record fail DMARC for alignment and IIRC, this is the reason why. If I have this wrong, please correct me, but at least once I followed this through reading the RFC. – Paul Mar 07 '21 at 15:23
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).

Austin Hemmelgarn
  • 2,295
  • 9
  • 15
  • 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 '20 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](https://tools.ietf.org/html/rfc7208#section-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 '20 at 13:31
  • Indeed. This answer is incorrect, though the history is right. – user1521620 Dec 12 '20 at 01: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 '20 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)

jornane
  • 1,166
  • 1
  • 9
  • 26
  • 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 '20 at 16:59
  • I've enhanced my answer based on this observation and linked to this answer. +1 – Esa Jokinen Dec 11 '20 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.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
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.

JFL
  • 2,018
  • 1
  • 12
  • 17
  • 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 '20 at 01:10
  • Do you have an example of well known services “including millions of ip addresses”? – eckes Dec 12 '20 at 23:31
  • 1
    @eckes According to this post, it is even worse than that: “That means basically you explicitly allow **b**illions of IP addresses to send email on your behalf …” – Brian Drake Dec 13 '20 at 13:49
  • 1
    @eckes if you count ipv6 its easy :) otherwise I suspect the poster is exaggerating – mbrig Jan 20 '21 at 04: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.

jcaron
  • 1,030
  • 7
  • 9