Mailchimp SPF record: when do you need one?

What usually causes it?

SPF is being compared with the visible From domain

SPF evaluates the RFC5321.MailFrom identity when it is available. The visible From address is a message-header identity, so it does not become the SPF identity because it is the address recipients see.

If a Mailchimp campaign uses a Mailchimp-managed envelope domain, editing the SPF record at yourdomain.com does not change the SPF evaluation for that envelope domain. The received headers determine whether that is the path in use.

An unaligned SPF pass is being treated as a DMARC failure

An SPF pass can be valid without aligning with the visible From domain. It cannot supply DMARC alignment in that case, but DMARC permits an aligned DKIM pass to satisfy evaluation.

Under relaxed alignment, related domains can align when they share an organizational domain. Under strict alignment, the authenticated domain must exactly match the visible From domain. The active DMARC record determines which alignment mode applies.

Mailchimp domain authentication is incomplete or unverified

Mailchimp's email-domain authentication instructions describe an automated Microsoft Entra ID option and a manual setup path. The manual path provides two DKIM CNAME records and one DMARC TXT record.

Those instructions establish the setup method, but they do not prove the header.d= domain on a specific campaign. Confirm that from a newly delivered message sent through the same Mailchimp route.

A second SPF or DMARC TXT record was added

SPF specifies that multiple SPF records at one domain produce permerror. Adding a second DMARC policy record can also create an invalid or ambiguous setup instead of repairing alignment.

Do not publish a second SPF TXT record or a second DMARC TXT record. Find the existing record first and change it only when the sending path and documented configuration require it.

A valid SPF result is being mistaken for a DMARC pass

A message can show spf=pass and dmarc=fail when the SPF domain does not align and DKIM does not provide an aligned pass. This is a protocol result, not evidence that Mailchimp must always be added to the visible domain's SPF record.

The repair depends on the delivered identities. Treat a conclusion about a different Mailchimp product, account, or sending route as an inference until its message headers confirm it.

When this answer does not apply

This answer does not apply when the delivered message has no aligned DKIM pass and must rely on SPF alignment. If dkim=fail or the passing header.d= domain is unaligned, inspect smtp.mailfrom and the Mailchimp account's current domain-authentication state. If the received headers show that SPF passes for an aligned envelope domain, that SPF result can supply the DMARC pass.

It also does not apply to another sending platform just because that platform uses a provider-owned return path. Each service can choose different DKIM and envelope-domain behavior. Preserve a message from the exact product and account route before changing DNS.

This is also not an inbox-placement repair. A message can pass DMARC through aligned Mailchimp DKIM and still be filtered for reputation, content, complaint, or receiver-policy reasons. In that case, adding Mailchimp to SPF does not address the observed result.

How do I diagnose the failure?

1. Preserve a message from the exact Mailchimp sending path

Send a new test campaign through the same Mailchimp product, authenticated From domain, audience type, and configuration used in production. Open the raw source in the receiving mailbox, then save the complete headers in an access-controlled incident record.

Record the From, Return-Path when present, Authentication-Results, Message-ID, delivery time, and recipient provider. A rendered mailbox view hides the header fields needed to distinguish SPF from DKIM alignment.

2. Identify the aligned passing identifier

Compare the domains in the received message with the visible From domain.

Visible From: newsletter@yourdomain.com
SPF identity: smtp.mailfrom=mailchimp.example
DKIM identity: header.d=yourdomain.com
DMARC result: dmarc=pass header.from=yourdomain.com

This is illustrative only. If header.d=yourdomain.com passes and aligns with the visible From domain, Mailchimp does not need SPF alignment for that message's DMARC pass. RFC 6376 defines how a receiver verifies a DKIM signature using the signing domain and selector.

If DKIM passes but header.d= does not align, inspect the active DMARC record for relaxed or strict alignment before changing anything.

3. Verify Mailchimp's published authentication records

In the Mailchimp account that sent the campaign, open the official email-domain authentication setup and compare its account-generated DNS values with authoritative DNS. Mailchimp's documented manual flow uses DKIM CNAME records and a DMARC TXT record. Copy names and targets only from the account that owns yourdomain.com.

Use the DMARC checker to inspect the published DMARC policy. Use the SPF checker to inspect the public SPF record before adding or removing an authorization.

Public DNS checks show what resolvers can retrieve. They do not prove that Mailchimp signed a particular campaign, used a particular envelope domain, or that a receiver will make the same decision for future mail.

4. Take the safe branch for the observed evidence

If the domain is unverified or unauthenticated in Mailchimp, complete Mailchimp's documented domain-authentication setup and wait for the vendor's status to confirm it. Then send a fresh test through the same path. Do not copy DKIM values from another Mailchimp account or domain.

If DKIM does not align, compare header.d= with the visible From domain and the applicable DMARC alignment mode. Repair the domain-authentication configuration that Mailchimp generated for the actual From domain. Do not change p= to hide the result. A DMARC policy change affects requested enforcement, not the message's DKIM alignment.

If DMARC fails while SPF is valid, determine whether smtp.mailfrom aligns with the visible From domain. If it does not, valid SPF alone cannot supply DMARC alignment. Check whether a DKIM signature passes and aligns, then correct the verified authentication path rather than forcing an unrelated SPF include into the visible domain's record.

5. Check SPF only when the actual sending path needs it

Do not add a hosted SPF mechanism for Mailchimp merely because a campaign needs DMARC alignment. Add or change SPF only when the actual envelope-domain setup and Mailchimp documentation require it.

If the SPF record has an actual DNS-lookup-limit condition, investigate that condition separately. RFC 7208 limits SPF evaluation to ten DNS-querying terms. A lookup-limit repair does not establish Mailchimp DKIM alignment and should not be treated as one.

For a comparison of a provider path that does not supply SPF alignment by default, see why Brevo does not provide SPF alignment by default.

How do I fix it?

Complete Mailchimp authentication for the actual From domain

When the Mailchimp domain-authentication status is incomplete, use the records generated in that Mailchimp account for the private domain used in the campaign. Publish the provided DKIM CNAME records exactly, then confirm the vendor's current status.

Do not replace an existing DMARC policy with a Mailchimp example value without reviewing the current policy and its reporting addresses. A DMARC record controls requested receiver handling and reporting.

This repair changes DNS authentication configuration. It does not guarantee that every future message will authenticate or that a recipient will place mail in the inbox.

Correct the DKIM alignment path

When the receiver's headers show a passing but unaligned header.d=, make the Mailchimp authenticated sending domain match the intended visible From domain according to the applicable alignment mode. Validate with a new message, not only a green vendor status.

Do not relax strict alignment as a first response. That changes the DMARC policy's alignment requirement. It does not correct an unverified or incorrect Mailchimp domain-authentication setup.

Remove duplicate records, not needed authorizations

When the public DNS evidence shows duplicate SPF or DMARC TXT records at the same owner name, consolidate records only after identifying their owners and sending systems. Preserve any authorization used by another approved sender.

This repair changes published DNS. Retest every known sender that depends on the changed record.

How do I validate the repair?

Send a fresh Mailchimp campaign through the same authenticated From domain and product route. Confirm the following four layers:

• DNS: Check the authoritative DNS response and at least one public resolver for the Mailchimp-generated DKIM records and the single intended DMARC record.
• Vendor: Confirm Mailchimp's domain-authentication status for the exact sending domain.
• Message: Inspect the receiver-added Authentication-Results field. Confirm dkim=pass, record header.d=, and confirm that it aligns with header.from=.
• DMARC: Confirm the delivered message reports dmarc=pass, then review DMARC aggregate reports after data accumulates to see whether the same source continues to authenticate as expected.

Check the DMARC record behind the Mailchimp result

After comparing the delivered headers, inspect the published DMARC policy for the visible From domain. This confirms the alignment mode and policy currently visible in DNS before you change Mailchimp authentication or SPF.

Check the DMARC record

A public DMARC record check cannot inspect a Mailchimp campaign's envelope domain, prove which DKIM signature reached a recipient, monitor the sending path, or explain a recipient's private placement decision.

If Mailchimp is one of several sending sources for the domain, Palisade's agent investigates sources observed in aggregate DMARC reports, drafts fixes, and proposes each policy step. You approve before anything ships. When you approve a DNS change, Smart DNS Deployment writes the record into your own zone at your own provider.

Start with Palisade

Palisade does not ship a DMARC policy change without approval, repair every sender, or prove that a future Mailchimp campaign will authenticate or reach the inbox.

For broader DMARC policy and alignment context, visit the DMARC learning hub.