Why does Mailchimp DMARC alignment not require adding Mailchimp to SPF?

Mailchimp Marketing email can pass DMARC without adding Mailchimp to the visible From domain's SPF record because DMARC needs one aligned authentication path, not two. Mailchimp's current custom-authentication flow gives the customer a DKIM signing identity aligned with the From domain. That passing, aligned DKIM result is sufficient for DMARC. SPF evaluates the separate SMTP MAIL FROM domain, so changing the visible From domain's SPF record does not automatically change Mailchimp's SPF identity.

Quick takeaways

• DMARC passes when at least one authenticated identifier aligns with the author domain. Aligned DKIM can supply the pass even when SPF is unaligned.
• SPF checks the SMTP MAIL FROM domain, often called the return path or envelope sender. It does not authenticate the visible From header directly.
• Mailchimp's current Marketing domain-authentication instructions use two DKIM CNAME records and a DMARC TXT record. They do not tell customers to add a generic Mailchimp include to the From domain's SPF record.
• A raw spf=pass can still be unaligned and therefore irrelevant to the DMARC pass.
• Mailchimp Marketing and Mailchimp Transactional are related but distinct products. Follow the records and return-path options for the product and account actually sending.
• Do not publish a second SPF record or a second DMARC record. Validate one delivered message and the aggregate DMARC evidence before changing DNS.

DMARC evaluates alignment, not whether both underlying mechanisms align. Open the full-size Mailchimp DMARC alignment map.

The DMARC pass rule uses one aligned identifier

The current DMARC standard is RFC 9989, published in May 2026 to replace RFC 7489. It calls the domain in the visible From header the Author Domain. DMARC validates that domain when a passing DKIM or SPF authenticated identifier aligns with it.

For DKIM, the authenticated identifier is the signing domain in the signature's d= tag. For SPF, DMARC relies on the SMTP MAIL FROM domain, not the visible From address. A message can therefore have these results:

• visible From: newsletter@example.com
• DKIM: pass with d=example.com
• SPF: pass for a Mailchimp-managed return-path domain that does not align with example.com
• DMARC: pass because the aligned DKIM signature is valid

RFC 9989 states that a message can carry multiple DKIM signatures and that any validated DKIM identifier aligned with the Author Domain can produce the DMARC pass. The standard recommends deploying both DKIM and SPF, but the per-message pass condition does not require both to align.

This distinction matters operationally. "Use SPF and DKIM" is a sound resilience goal. "Every service must be placed in the visible From domain's SPF record for DMARC to pass" is not the DMARC algorithm.

SPF authenticates the envelope identity

RFC 7208 defines SPF around SMTP identities. In ordinary mail with a non-empty reverse path, the receiver checks the domain from the MAIL FROM command. That domain is commonly surfaced in the delivered message as the Return-Path.

The visible From header belongs to the message content. SPF does not select that domain just because a person sees it in the mail client. DMARC is the layer that compares the SPF-authenticated MAIL FROM domain with the visible Author Domain.

This is why adding a Mailchimp mechanism to example.com's SPF record can be a no-op for the campaign being diagnosed. If the delivered message uses a Mailchimp-controlled MAIL FROM domain, the receiver queries that domain's SPF record. It does not query example.com for that SPF evaluation.

The change can still consume DNS-lookup budget and make the organization's SPF record harder to manage. If an administrator accidentally publishes a second SPF TXT record instead of editing the existing one, the result can be an SPF permanent error.

Do not authorize services in SPF by brand association. First identify the exact MAIL FROM domain used by that message.

Mailchimp Marketing custom authentication uses DKIM alignment

Mailchimp's current email domain authentication instructions direct Marketing customers to authenticate a verified private domain through an automated Entri flow or a manual flow. The manual flow currently supplies two CNAME records for DKIM and one TXT record for DMARC.

The DKIM CNAME records delegate Mailchimp's selectors under the customer's domain to Mailchimp's key-hosting targets. When Mailchimp applies a valid signature with the authenticated customer domain in d=, that signing domain can align with the visible From domain.

The DMARC TXT record publishes the domain owner's policy and reporting request. It does not authorize Mailchimp IP addresses. If the domain already has a valid DMARC record, do not publish another one to satisfy a setup screen. A domain must have one coherent policy record at the applicable _dmarc name. Preserve the organization's reporting destinations and rollout plan while incorporating any necessary change.

The Mailchimp SPF and DKIM setup guide covers the current account path and the DNS-provider checks. Use the values shown in the account rather than examples copied from another domain.

Raw authentication passes and DMARC alignment are separate results

A delivered header might say both spf=pass and dkim=pass, yet only DKIM aligns. That is normal for many third-party sending platforms.

Read the full Authentication-Results field and identify:

• the visible From domain
• the SPF-authenticated MAIL FROM domain
• every passing DKIM d= domain
• the receiver's final dmarc=pass or dmarc=fail result
• any explicit alignment annotations the provider includes

For relaxed alignment, the authenticated identifier and Author Domain can align when they share the same organizational domain. For strict alignment, the domain names must be identical. Most domains use the default relaxed mode unless their DMARC policy explicitly sets strict alignment.

Do not compare only strings that happen to appear in the header. A DKIM signature can pass for an unrelated provider domain and still be unaligned. An SPF record can authorize an IP for one MAIL FROM domain without saying anything about the visible From domain.

The useful diagnostic question is: Which passing authenticated identifier authorized this Author Domain? If the answer is a customer-domain DKIM signature, Mailchimp does not need SPF alignment for that message to pass DMARC.

Current receiver requirements still call for SPF and DKIM

Google's current email sender guidelines require SPF or DKIM for all senders to personal Gmail accounts. For senders above Google's bulk threshold, the requirements include SPF, DKIM, DMARC, and alignment of the direct-mail From domain with either SPF or DKIM.

The word "either" in the alignment requirement matters. A Mailchimp campaign can satisfy the DMARC-alignment portion through DKIM while Mailchimp's infrastructure supplies a valid SPF result for its own MAIL FROM domain.

This does not make SPF optional for the organization as a whole. The domain's other senders may rely on SPF alignment, and Mailchimp Transactional can use different return-path capabilities. It also does not mean an aligned DKIM signature guarantees inbox placement. Google evaluates reputation, complaints, sending practices, unsubscribe behavior, and other signals after authentication.

The troubleshooting guide for a Mailchimp message marked delivered but placed in spam separates an authentication result from final folder placement.

Mailchimp Marketing and Transactional need separate inventories

Mailchimp Marketing manages campaigns and audiences. Mailchimp Transactional, historically called Mandrill, handles application-generated messages through an API or SMTP. The products have separate documentation, controls, and traffic patterns.

Mailchimp Transactional's current fundamentals documentation requires a sending domain to be verified and authenticated with DKIM and DMARC before normal sending. Its API also exposes a return_path_domain option for messages. That makes the actual product and account configuration relevant to SPF alignment.

Do not infer a Marketing campaign's DNS needs from an old Mandrill tutorial, or infer a Transactional integration's return path from a Marketing report. Capture a delivered message from the stream being diagnosed and record whether it came from:

• a regular Mailchimp Marketing campaign
• a Marketing automation
• Mailchimp Transactional through SMTP
• Mailchimp Transactional through the API
• another system that only uses a Mailchimp template or integration

The last case is especially easy to mislabel. A CRM can synchronize contacts with Mailchimp while sending through a different provider. DMARC evidence should follow the actual message path, not the application's logo.

Safe DNS changes start with the existing records

Before changing anything, retrieve the current DNS answers from more than one resolver and compare them with the authoritative DNS provider. Save the existing SPF, DKIM, and DMARC records.

For SPF, check that the MAIL FROM domain has exactly one SPF record and that it stays within the protocol's lookup limit. Do not flatten a provider's dynamic IP ranges unless the provider explicitly supports that design and there is an owner for keeping the result current.

For DKIM, confirm that each Mailchimp selector resolves to the target shown in the account. A DNS host can append the zone name automatically, so entering a full host name in the wrong field can repeat the zone after the selector and create a doubled DNS name.

For DMARC, confirm that one valid policy record exists at the applicable _dmarc name. Preserve rua destinations, alignment modes, subdomain policy, and the organization's enforcement plan. Do not replace a monitored enforcement record with a generic p=none example just because a vendor setup page displays it.

Make the smallest change supported by the evidence. If aligned DKIM already passes for Mailchimp Marketing, adding Mailchimp to the From domain's SPF record is not the repair.

Validation should prove the exact identity path

After Mailchimp reports the domain as authenticated and DNS has become visible, send a small labeled campaign to test accounts at more than one provider. Use the same From domain and Mailchimp product as the production traffic.

Save the original messages and verify:

• the intended Mailchimp DKIM selector signed the message
• the DKIM signature validates
• the DKIM d= domain aligns with the visible From domain
• the receiver reports dmarc=pass
• the SPF result names the MAIL FROM domain actually used
• no unrelated sender's authentication was mistaken for Mailchimp's result

Then review aggregate DMARC reports over a representative interval. Group records by source, header-from domain, envelope-from domain, DKIM domain, selector, and result. A single successful seed proves the configured route works; aggregate data shows whether production consistently uses it.

If DKIM sometimes disappears or fails, investigate template or route differences, account configuration, intermediary modification, and selector DNS. Do not hide an intermittent DKIM problem by broadly authorizing more infrastructure in SPF.

Palisade shows which mechanism is carrying DMARC

Palisade does not log into Mailchimp, publish Mailchimp DNS records, change an external SPF or DMARC policy, control Mailchimp's return path, or guarantee message placement.

Palisade can analyze DMARC aggregate reports for domains you control. It can help an IT team or MSP identify Mailchimp traffic, compare the reported SPF and DKIM identities with the visible From domain, and see whether DKIM or SPF is carrying the DMARC pass across receivers and time.

Use the free Email Security Score to inspect the public SPF and DMARC configuration. If the broader need is tracking Mailchimp and other authorized senders across several domains or clients, start a Palisade account after validating one real message.

Frequently asked questions

Can Mailchimp pass DMARC when SPF is unaligned?

Yes. A valid Mailchimp DKIM signature can align with the visible From domain and produce a DMARC pass. SPF may pass for a separate Mailchimp-managed MAIL FROM domain without aligning. The receiver needs at least one passing, aligned authenticated identifier.

Does SPF check the address recipients see in From?

No. SPF normally checks the domain in the SMTP MAIL FROM command, which appears as the return path in a delivered message. DMARC compares that SPF-authenticated domain with the visible From domain to determine alignment.

Should I add an SPF include that I found in an old Mailchimp guide?

Not without checking the current product instructions and a delivered message. Mailchimp Marketing's current custom-authentication flow uses DKIM CNAME records and DMARC. Mailchimp Transactional has separate documentation and return-path behavior. Copying an old include can add cost or create an SPF error without changing the evaluated identity.

Do SPF and DKIM both have to pass for Gmail bulk-sender compliance?

Google requires bulk senders to use SPF, DKIM, and DMARC. For direct-mail alignment, the visible From domain must align with either SPF or DKIM. A Mailchimp campaign can therefore use aligned DKIM for DMARC while still producing SPF for its own MAIL FROM identity.

Can I publish two SPF records, one for Mailchimp and one for Microsoft 365?

No. A domain must not publish multiple competing SPF records. If the domain's actual MAIL FROM traffic requires several authorized sources, combine the supported mechanisms in one record and stay within SPF's DNS-lookup limit. Do not add Mailchimp when the message never uses that domain for MAIL FROM.

How can I tell whether DKIM or SPF made DMARC pass?

Inspect the original message's Authentication-Results, visible From domain, DKIM d= domains, and return path. Then compare the same identities in DMARC aggregate reports. A passing aligned DKIM result can carry DMARC even when the SPF-authenticated domain is unaligned.