Why Mailchimp's SPF Include Is a Spoofing Liability: The ESP Authentication Pattern

In auditing several hundred domains over the past year, we kept finding the same line in root-domain SPF records: include:servers.mcsv.net. Mailchimp's. Sometimes the organization had a Mailchimp account. Often they didn't, or hadn't sent mail through it in years. The include was there because at some point, someone had followed Mailchimp's setup instructions and added it. Nobody had ever removed it.

This wouldn't matter except for one architectural detail: Mailchimp's customers don't send mail from the root domain. They send mail from Mailchimp's own envelope-sender domains. The include:servers.mcsv.net line on a customer's root domain authorizes Mailchimp's IPs to send mail using that customer's domain in the SMTP envelope — for mail streams that Mailchimp itself doesn't generate from the customer's domain. The include adds spoofing surface without contributing to legitimate authentication.

This post is about a class of authentication pattern that several major ESPs follow, the structural risk it creates, and what the right architecture would look like.

The Mechanics

When you include servers.mcsv.net in your domain's SPF record, you are publishing a DNS statement that says: "Mail with my domain in the Return-Path can legitimately come from any IP in Mailchimp's servers.mcsv.net range." Mailchimp's range is large — thousands of IPs across multiple shared infrastructure pools. Any one of those IPs, if compromised, gives an attacker the ability to send SPF-passing mail with your domain in the Return-Path.

If your DMARC alignment is set to aspf=r (relaxed, which is the default), an SPF pass on a related domain is enough for DMARC to pass. The attacker's spoofed mail, sent through a compromised Mailchimp IP with your domain in the Return-Path, will pass SPF, satisfy alignment, and therefore pass DMARC — even if your policy is set to p=reject. The attacker doesn't need to break DKIM. They don't need to compromise anything you control. They just need to be on a Mailchimp IP at the moment they send.

Daniel Maloney explained the practical exploit on our LinkedIn post:

"When one of Mailchimp's servers is compromised, they can send 'authenticated mail' as any of their customers. Additionally, if SMTP relay creds are compromised, a threat actor can use their own mail server as the first MTA spoofing the target org and forging headers, then relay the mail through the Mailchimp SMTP server where it gains authentication headers which trick most receiving mail servers."

The "trick" isn't sophisticated. It's the SPF spec working as designed. If you authorize a wide IP range, every IP in that range gets the authority you granted.

Why Mailchimp's Documentation Recommends the Include

Mailchimp's official position, repeated in their support documentation, is that the include is not required for sending. Mail through Mailchimp authenticates via DKIM regardless of whether the customer adds the SPF include. DMARC alignment via DKIM is sufficient. So why does the documentation continue to recommend the include?

Our hypothesis is operational: it reduces customer support load. If a customer's mail starts failing SPF somewhere — even when DKIM passes and DMARC alignment is satisfied — their first instinct is to email Mailchimp support. Recommending the include preempts the ticket. The cost is borne by customers whose security posture is silently weakened. The savings accrue to the ESP.

Neil Anuskiewicz framed it bluntly in the same thread: "Crazy zombie documentation." The recommendation hasn't been quietly updated because doing so would require Mailchimp to acknowledge the years of customer records that are now spoofing surface — and the work of explaining the cleanup to a customer base that mostly doesn't read DNS records.

Nicola Selenu at Google had the structural read: "This has more to do with the poor practice of providing a generic include with some pretty big ranges in it. Sadly only a few ESPs use a dedicated SPF record for each client, listing only the IPs used by that particular client."

That's the real architectural problem. The SPF include pattern works fine when every IP in the included range only sends mail for one customer. It breaks the moment the included range is shared across all of an ESP's customers — because now any compromised IP can spoof any customer.

MailerLite and the Same Pattern

The pattern isn't limited to Mailchimp. MailerLite's "Authenticated" dashboard status — the indicator that tells a customer their domain is set up correctly — is gated behind a SPF include the customer is asked to add to their root domain. Same architectural problem. MailerLite's customers don't send from root. They send from MailerLite's own envelope-sender infrastructure with proper DKIM signing. The include exists for the same operational reason: it reduces support load and gives the customer a single dashboard indicator that everything is "correct."

This is the broader pattern: ESPs that gate authentication status, support documentation, or onboarding flows behind a root-domain SPF include create persistent spoofing liability for their entire customer base. The ESPs that get this right — and there are some — provide each customer with a dedicated subdomain for sending, configure DKIM on that subdomain, and either skip the SPF include entirely or use SPF macros to scope the authorized IPs per-customer.

The Fix in Two Directions

For domain owners, the immediate fix is to audit your SPF record and remove includes for ESPs you don't currently use. The audit is straightforward:

dig TXT example.com | grep spf

For each include, ask: "Does my domain currently send mail through this platform from the apex, with a Return-Path on the apex domain?" If the answer is no, the include should not be there. If you use the ESP but it sends from a subdomain (which is the case for SendGrid, Amazon SES, and most enterprise infrastructure), the include belongs on the subdomain's SPF record, not the apex.

The secondary check is to look at your DMARC aggregate reports for sources you don't recognize. If your reports show mail from Mailchimp IPs and you haven't sent through Mailchimp in five years, that's a problem — and not because someone is spoofing you yet, but because the surface for spoofing is sitting in your DNS waiting to be used.

For ESPs, the right architecture is the one Nicola Selenu pointed to: dedicated SPF records per customer. The cost is real. As Ivan Maltsev at TinyEmail noted, "Having dedicated SPF for each customer in most cases is too expensive. Imagine you're an ESP and have 1000 customers. To manage SPF for each one of them you need to invest money and development into proper tooling for your Deliverability department. And this investment won't just bring any money back."

That's not a refutation. That's an admission. The reason the industry hasn't moved to per-customer SPF is that the security cost is externalized to customers and the operational cost would be absorbed by ESPs. SPF macros, which let an ESP construct a per-customer SPF dynamically without managing thousands of static records, exist in the spec but are barely adopted because they require engineering investment ESPs haven't been forced to make.

One path forward is regulatory or contractual pressure. Another is the ESP that gets it right capturing market share from those that don't. Until then, the operational answer for customers is to know what's in their SPF and remove what doesn't belong there.

What a Clean ESP Authentication Looks Like

The minimum viable correct configuration for using an ESP without root-domain SPF exposure:

1. The ESP sends from a subdomain you own (e.g., mail.example.com for marketing, notifications.example.com for transactional).
2. DKIM is configured on that subdomain with a 2048-bit key.
3. The subdomain has its own SPF record with include: for the ESP, scoped only to that subdomain.
4. The apex SPF record contains only senders that actually use the apex — typically just your corporate mail platform (Google Workspace or Microsoft 365).
5. DMARC at the apex enforces p=reject with relaxed alignment, so the subdomain mail aligns to the apex via the organizational domain match.
6. The subdomain optionally has its own DMARC record (sp= on the apex covers it, but explicit is better) at p=reject.

In this setup, a compromise of the ESP's IP range cannot spoof your apex, because your apex SPF doesn't authorize the ESP's IPs. The blast radius is contained to the subdomain. The ESP is doing real work — sending DKIM-signed mail under your subdomain — and DMARC validates the signing, not a Boolean trust statement about thousands of IPs.

This is the configuration we deploy on every client engagement where we have the latitude. Some ESPs make it harder than others. The ones that gate dashboard "authenticated" status behind a root SPF include are the worst offenders. The ones that publish per-customer subdomain authentication paths with proper DKIM-first guidance are the ones that have actually thought about this.

The Trust Boundary

The SPF include pattern is a trust statement. Every time you add include:something.example.com to your SPF, you are saying "I trust whoever controls that domain to not allow my domain to be spoofed via their authorized IPs." For a well-architected platform — one that scopes per-customer authorization correctly — that trust is reasonable. For a platform that authorizes all customer mail from a shared IP pool, the trust is delegated to whatever the weakest tenant on that platform looks like.

Knowing what's in your SPF, and what the structural risk of each include is, is the bare minimum of email security hygiene. Most domains we audit have at least one include that no longer has a defensible reason to be there. Removing it takes thirty seconds. Leaving it leaves a path open for someone who notices before you do.

---

Written by the team at SH Consulting. If you want a full SPF audit and an inventory of which of your authorized senders should actually be in your DNS, book a call.