Why you shouldn't add MailChimp to your SPF record
Michael Ko
Co-founder & CEO, Suped
Published 11 Jul 2025
Updated 11 Jul 2025
7 min read
When setting up a new email sending service, one of the first steps is usually to update your domain's DNS records. For years, the conventional wisdom has been to add every service you use to your Sender Policy Framework (SPF) record. It seems logical; you're authorizing this service to send on your behalf, so you should list it. However, when it comes to MailChimp, this common practice is not only unnecessary but can be actively harmful to your email deliverability.
This might sound counterintuitive, especially since many guides online still recommend it. The reason you shouldn't add MailChimp to your SPF record lies in the technical details of how email authentication works, specifically the difference between the 'From' address your recipients see and the hidden 'envelope' address used by mail servers. Understanding this distinction is key to a clean, effective, and future-proof email authentication setup.
SPF and the two 'from' addresses
A Sender Policy Framework (SPF) record is a list of IP addresses and servers authorized to send email on behalf of your domain. When an email is received, the recipient's mail server checks the SPF record of the sending domain to verify the sender's authenticity. It's a fundamental part of preventing email spoofing and protecting your domain's reputation. The goal is to tell the world, "These are the only servers I trust to send my mail."
Here's where it gets a little technical, but it's the most important concept to grasp. Every email has two 'From' addresses:
The first is the one you see in your inbox, often called the 'header From' or RFC5322.From. This is your branding, like newsletter@yourbrand.com.
The second is a hidden address called the 'envelope sender', 'return-path', or RFC5321.MailFrom. This address is used by mail servers for the actual transport of the email and, crucially, for handling bounces.
The critical point is that SPF validation is performed on the domain found in the hidden RFC5321.MailFrom address, not the visible header From address. This is a common point of confusion that leads to misconfigured records. A receiving server looks at the envelope, not the letterhead, to decide which domain's SPF policy to check. So if a brand's domain isn't used in the MailFrom, adding it to your SPF policy is pointless.
MailChimp, by design, uses its own domain in the RFC5321.MailFrom address, typically something like mcsv.net. This allows them to process bounces and unsubscribes on their own servers efficiently. Since the SPF check looks at the mcsv.net domain, the receiving server will fetch and evaluate MailChimp's SPF policy, not the SPF policy on your domain. Your record is never even consulted for the SPF check.
How MailChimp actually handles authentication
If SPF isn't being checked against your domain, how does MailChimp prove an email is legitimately from you? The answer is DKIM (DomainKeys Identified Mail). DKIM works by adding a unique digital signature to the email's headers. This signature is created using a private key that only MailChimp has for your account, and it can be verified by anyone using a public key that you publish in your DNS.
When you authenticate your domain in MailChimp, you are given a DKIM record to add to your DNS. This record links your sending domain to the email, even though the MailFrom address belongs to MailChimp. For DMARC, a security policy that uses SPF and DKIM, this DKIM signature is sufficient for the email to 'align' with your domain and pass authentication. This is why you should always authenticate your domain with DKIM and SPF records.
So, while the SPF check will technically fail to align with your From domain, the DKIM check will pass and align perfectly. Because DMARC only requires one of these methods to pass and align, your email is considered authentic, and your deliverability is protected. This is the modern, standard way for email service providers to handle authentication.
SPF alignment
This will fail. The RFC5321.MailFrom uses a MailChimp domain (mcsv.net), while the RFC5322.From uses your domain. Because the domains don't match, SPF alignment fails for DMARC, even if MailChimp's own SPF record is valid.
DKIM alignment
This will pass. MailChimp signs the email using a DKIM key associated with your domain (d=yourbrand.com). This signature aligns with the RFC5322.From address domain, so the DMARC check passes. This is the intended authentication method.
The hidden costs of adding MailChimp to SPF
At this point, you might think, "Okay, it's not needed, but what's the harm in adding it anyway?" The harm comes from a critical limitation in the SPF specification: the 10 DNS lookup limit. To prevent denial-of-service attacks, a receiving mail server is only allowed to make a maximum of 10 DNS lookups when evaluating an SPF record. This includes any lookups from include mechanisms.
Every time you add an include:thirdparty.com to your SPF record, you are using up one of these 10 precious lookups. When you add MailChimp's include, include:servers.mcsv.net, you are consuming a lookup for absolutely no benefit, as your record isn't being checked for MailChimp sends in the first place.
As your organization grows, you will inevitably add more services that genuinely require an SPF entry, such as Google Workspace, Microsoft 365, or your CRM. Wasting a lookup on MailChimp brings you one step closer to exceeding the limit. If you go over 10 lookups, your SPF record will fail validation with what's called a 'PermError'. This is worse than having no SPF record at all, as it can cause all your legitimate emails from every service to fail authentication.
Danger of exceeding the SPF lookup limit
Exceeding the 10 DNS lookup limit will cause your entire SPF record to return a PermError. This invalidates your SPF for all sending services, not just the last one, and can cause legitimate mail to be marked as spam or rejected. Always keep your lookup count as low as possible.
By keeping your SPF record clean and only including services that need to be there, you maintain its integrity and avoid future deliverability problems. The correct approach is to focus your efforts on setting up DKIM for services like MailChimp and reserving your valuable SPF include slots for services that use your domain in the MailFrom path.
In conclusion, the advice to add MailChimp to your SPF record is outdated and based on a misunderstanding of how SPF works. MailChimp relies on DKIM for domain alignment, making the SPF entry for them redundant. Including it does nothing to help your deliverability, wastes a valuable DNS lookup, and brings you closer to the hard limit that can break your email authentication entirely.
Your time is better spent ensuring you have correctly set up the DKIM records provided by MailChimp and monitoring your DMARC reports to ensure everything is working as intended.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
