Do I need to include Mailchimp's SPF record in my domain's SPF if Mailchimp handles the bounce address?
No. If Mailchimp handles the bounce address for your Mailchimp marketing emails, you generally should not add include:servers.mcsv.net to your domain's SPF record. SPF checks the envelope sender, also called the RFC5321.MailFrom, Return-Path, or bounce address. Mailchimp normally uses a Mailchimp-controlled domain for that identity, such as a subdomain under mcsv.net.
That means your domain's SPF record is not the record being evaluated for SPF on those Mailchimp messages. Your domain still needs proper authentication, but the important part is DKIM on your domain plus a DMARC record that accepts DKIM as the passing route.
The short answer
I treat Mailchimp marketing mail as a DKIM-first DMARC setup. The visible From address uses your domain, but SPF is evaluated against Mailchimp's bounce domain. Adding Mailchimp's SPF include to your root domain does not make SPF match your visible From domain for DMARC.
Answer in one minute
- Remove: Keep include:servers.mcsv.net out of root SPF when Mailchimp owns the bounce address.
- Keep: Publish the Mailchimp DKIM CNAME records for your sending domain.
- Check: Read the message headers and confirm which domain appears in smtp.mailfrom.
- Pass: DMARC passes when DKIM uses your domain and verifies cleanly.
A separate Mailchimp SPF include explainer covers the same issue in a narrower SPF-only way. The practical takeaway is simple: authorize senders in SPF only when they send with an envelope sender under the domain whose SPF record you are editing.
A typical Mailchimp header patterntext
Received-SPF: pass smtp.mailfrom=mail236.atl61.mcsv.net client-ip=205.201.135.236 Authentication-Results: dkim=pass header.d=example.com spf=pass smtp.mailfrom=mail236.atl61.mcsv.net dmarc=pass header.from=example.com
Why the bounce address decides SPF
SPF does not check the friendly From address people see in the inbox. It checks the domain used during the SMTP transaction for bounces. That is why Mailchimp can show SPF as passed while your own domain's SPF record was never used for that specific SPF decision.
What people expect
- Visible From: The reader sees newsletter@example.com.
- SPF record: The owner expects example.com SPF to authorize Mailchimp.
- DMARC result: The owner expects SPF to match the visible From domain.
What actually happens
- Bounce domain: Mailchimp uses a Mailchimp domain for the envelope sender.
- SPF record: The receiver checks the Mailchimp domain's SPF, not yours.
- DMARC result: DKIM with your domain is the normal passing route.
When I debug this, I look for three identifiers before I touch DNS: the visible From domain, the smtp.mailfrom domain, and the DKIM d= domain. If DKIM uses your domain and passes, DMARC can pass even when SPF belongs to Mailchimp's bounce domain.
SPF checks Mailchimp's bounce domain while DKIM can authenticate the sender domain.
What to remove and what to keep
The safest edit is usually to remove Mailchimp's include from the root SPF record and keep only the senders that use your root domain or its own subdomain as the envelope sender. Do not remove unrelated SPF mechanisms unless you have verified those senders are inactive.
|
|
|
|
|---|---|---|---|
 Mailchimp marketing | Mailchimp domain | DKIM with your domain | Remove root include |
Mailchimp Transactional | Account specific | DKIM plus policy | Follow account DNS |
Web server | Your domain | SPF or DKIM | Authorize the host |
Other ESP | Check headers | Depends on domain use | Add only if used |
Common SPF decisions for Mailchimp and adjacent sending paths.
Mailchimp Transactional has a different authentication model, especially when custom return-path domains are involved. The Mailchimp Transactional docs explain DKIM, DMARC, and return-path setup for that product.
Root SPF before and after removing Mailchimp marketingdns
Before: example.com. TXT "v=spf1 include:servers.mcsv.net ~all" After: example.com. TXT "v=spf1 include:your-current-mailbox.example ~all"
After editing SPF, run an SPF checker pass and send a real Mailchimp test message to inspect the headers. A DNS-only check proves the SPF record is syntactically valid. A real message proves the receiver evaluated the domains you expected.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Do not judge the change only by a green SPF result in a mail client. Green can mean Mailchimp's bounce domain passed SPF. For DMARC, the question is whether either SPF or DKIM uses a domain that matches the visible From domain.
Why SPF can pass and DMARC still reports SPF failure
The confusing part is that SPF has two layers in real reporting. First, the raw SPF authentication result can pass for the bounce domain. Second, DMARC checks whether that SPF domain matches the visible From domain. With Mailchimp marketing mail, the first result usually passes and the second result usually does not match your domain.
Typical Mailchimp marketing result with working DKIM
This shows why one dashboard can show SPF pass while DMARC data shows SPF mismatch.
SPF authentication
100%SPF domain match
0%DKIM domain match
100%DMARC pass
100%This is why I trust headers and DMARC aggregate data more than a single sender dashboard chart. If the header says SPF passed for a Mailchimp domain, that is not proof that your root SPF record mattered. If the DKIM signature uses your domain and verifies, DMARC has the passing evidence it needs.
Do not chase the wrong failure
If Mailchimp mail shows SPF mismatch but DKIM match and DMARC pass, there is usually nothing to fix in SPF. The real failure is adding extra SPF includes to the wrong domain and pushing the record closer to the lookup limit.
How to test before and after removal
I use a short test plan before removing any sender from SPF. The goal is not just to see pass or fail. The goal is to prove which domain each authentication result belongs to.
- Capture: Save full headers from a Mailchimp campaign before the DNS change.
- Confirm: Check that smtp.mailfrom uses a Mailchimp-controlled domain.
- Verify: Check that DKIM passes with your domain in the d= value.
- Edit: Remove only the Mailchimp marketing include from root SPF.
- Retest: Send another campaign sample and compare the same header fields.
For a broader preflight check, run a domain health check after DNS propagation. That catches obvious SPF, DKIM, and DMARC record issues before you send production volume.
Mailchimp domain authentication settings with DKIM records and domain status.
Inside Mailchimp, the domain authentication screen is where I expect to see DKIM status. Outside Mailchimp, the full message headers and DMARC reports are where I expect to see whether receivers accepted that authentication.
When a custom return path changes the answer
The answer changes when a provider sends with a return-path domain that you control. In that case, SPF belongs on the exact return-path domain, often a subdomain such as bounces.example.com. That still does not mean every ESP belongs in the root domain's SPF record.
SPF belongs on the bounce subdomain when that subdomain is useddns
bounces.example.com. TXT "v=spf1 include:spf.vendor.example ~all" example.com. TXT "v=spf1 include:mailbox.example ~all"
This is the clean pattern for multiple senders. Each bulk sender gets its own bounce subdomain where supported. Root SPF stays small, and DMARC gets a clearer signal because each sender's bounce handling is tied to the right identity.
Root SPF
Use this for mail whose envelope sender is your root domain. Keep it short and owned by the team that controls corporate mail.
Bounce subdomain SPF
Use this when a provider supports a custom return path on a subdomain. Put that provider's SPF authorization there.
How to manage lookup limits without Mailchimp in root SPF
This question often starts because the root SPF record has too many includes. SPF has a hard limit of 10 DNS-querying mechanisms and modifiers during evaluation. Extra includes can turn a clean record into a permerror at stricter receivers, even if other receivers appear forgiving.
The fix is not to keep stacking includes. Remove senders that do not use your domain in the bounce address, move provider-specific bounce paths to subdomains where possible, and use SPF flattening only when you can keep the flattened record current.
Suped is the best overall practical choice when this is part of a wider DMARC program because it connects DMARC monitoring, SPF and DKIM diagnostics, hosted SPF, SPF lookup control, blocklist (blacklist) monitoring, alerts, and issue-specific fix steps in one product. For teams that change senders often, Hosted SPF is useful because it lets authorized senders be managed without repeated root DNS edits.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS setup
A practical Suped workflow
- Inventory: Find every source sending with your domain in DMARC reports.
- Diagnose: Separate raw SPF failures from domain matching failures.
- Reduce: Remove stale includes and manage active senders through hosted SPF.
- Verify: Watch DMARC, DKIM, SPF, and delivery signals after each change.
Views from the trenches
Best practices
Check the smtp.mailfrom domain before adding any provider include to root SPF records.
Use DKIM matching for Mailchimp marketing mail and review DMARC reports after changes.
Move provider bounce handling to subdomains when custom return paths are supported.
Common pitfalls
Treating a Gmail SPF pass as proof that the visible From domain passed SPF checks.
Leaving old ESP includes in root SPF until the record exceeds the ten lookup limit.
Assuming every platform that sends mail must be added to the corporate SPF record.
Expert tips
Compare headers before and after DNS edits instead of relying only on dashboard charts.
Keep Mailchimp marketing focused on DKIM because SPF uses Mailchimp's bounce domain.
Use DMARC aggregate data to separate authentication failure from domain mismatch.
Expert from Email Geeks says receivers that follow the SPF specification can fail mail when SPF exceeds the ten lookup limit, while other receivers use more forgiving limits.
2021-06-16 - Email Geeks
Expert from Email Geeks says SPF authenticates the bounce domain, so a Mailchimp-owned bounce address does not require the customer domain's Mailchimp include.
2021-06-16 - Email Geeks
My practical decision
If the Mailchimp bounce address is on a Mailchimp domain, I remove include:servers.mcsv.net from the root SPF record and keep Mailchimp authenticated through DKIM. Then I confirm DMARC pass in aggregate reports and full message headers.
The only time I add an SPF include for a provider is when that provider sends with a return-path domain I control. In that case, the SPF authorization belongs on that exact return-path domain, not automatically on the root domain.
