Mailchimp and DMARC: reaching full alignment

k1._domainkey.example.com.  CNAME  dkim.mcsv.net.
k2._domainkey.example.com.  CNAME  dkim2.mcsv.net.
k3._domainkey.example.com.  CNAME  dkim3.mcsv.net.

Why SPF alignment will never come — and why that is fine

The reflex that often follows the CNAME setup is to "complete" the job with SPF, adding the platform's include to the domain's record. That reflex rests on a confusion. SPF is evaluated against the envelope domain (the Return-Path), not against the domain displayed in the From. And at Mailchimp, the envelope stays on the platform's servers: that is how error returns — invalid addresses, full mailboxes — flow back into its list-management systems. No option exists to substitute a custom envelope domain there.

The consequence: SPF will always pass for the platform's domain and never align with the From. Adding the include to the domain's SPF changes nothing — it merely burns one of the ten allowed DNS lookups on a mechanism that will not take part in the verdict. The platform itself stopped recommending that addition long ago.

And it is fine, because DMARC does not require both mechanisms: one aligned result is enough to produce a pass. The aligned DKIM obtained through the CNAMEs covers the entire need. It even carries a robustness bonus: a DKIM signature travels with the message and survives most automatic forwarding, whereas SPF breaks as soon as an intermediary re-sends. For a marketing flow, whose recipients forward liberally, DKIM alignment is the right horse to back.

What RUA reports show, before and after

Aggregate reports tell this story with precision. Before authentication, every row attributed to the platform's IP addresses shows the same characteristic signature:

<record>
  <row>
    <source_ip>205.201.131.xx</source_ip>
    <policy_evaluated><dkim>fail</dkim><spf>fail</spf></policy_evaluated>
  </row>
  <auth_results>
    <dkim><domain>mcsv.net</domain><result>pass</result></dkim>
    <spf><domain>mail01.rsgsv.net</domain><result>pass</result></spf>
  </auth_results>
</record>

The nuance sits in the contrast: in auth_results, everything passes; in policy_evaluated, everything fails. That is the typical fingerprint of an alignment problem, not an authentication problem — the most useful diagnosis an RUA report can deliver.

Once the CNAMEs are in place, the same address range flips: dkim=pass with example.com as the signing domain, policy_evaluated green, and SPF still unaligned — with no consequence whatsoever. Observing that flip across a full campaign cycle is the proof that authorizes hardening the policy. The reports still have to be collected, though: a record along the lines of v=DMARC1; p=none; rua=mailto:reports@example.com is the entry point, and the annotated DMARC record examples provide templates ready to adapt to the domain's maturity.

The same reading grid applies to the other platforms in the fleet: the logic is close for SPF and DKIM at Brevo, and the SendGrid case illustrates a cursor set differently between customizable envelope and delegated DKIM. Each platform makes its own choices; the question to ask stays the same: who signs, and for which domain?

The dedicated subdomain: isolating reputation

Rather than carrying campaigns on the root domain, many organizations entrust them to a dedicated subdomain: news.example.com, info.example.com. The authentication CNAMEs then go on that subdomain, and the campaigns' From displays it. The benefits are concrete. The marketing flow's sending reputation builds separately: a campaign incident — a complaint spike, a poorly cleaned list — does not erode the root domain's reputation, on which transactional email and individual correspondence depend. The source inventory also gains readability: in the reports, everything coming from the subdomain belongs to a single flow, which simplifies attribution.

On the DMARC side, relaxed alignment — the default — accepts a From at news.example.com aligning with a d=news.example.com signature as well as with one from the organizational domain. DMARCbis, the current revision of the standard, determines that organizational domain through the DNS Tree Walk, climbing the DNS tree, no longer through the Public Suffix List. The revision also brings the np tag, which settles the fate of non-existent subdomains: enough to lock down payroll.example.com or any other ghost subdomain while news.example.com rolls out its legitimate campaigns. A dedicated subdomain can finally carry a policy of its own, published at _dmarc.news.example.com, and harden at its own pace.

p=reject without authentication: the double penalty

There remains the worst-case scenario: a domain moving to p=reject without having authenticated its routing platform. Two mechanics combine. For flows where the From keeps the domain, unaligned campaigns are flatly rejected by receivers honoring the policy — entire sends evaporated, often discovered weeks later while investigating why "the newsletter stopped going out". And for flows caught by the From rewriting, the penalty is more insidious: messages leave and land, but under send.mailchimpapp.com — the brand has disappeared from the sender field, recognition drops, and the filters learn a domain that does not belong to the organization.

A strict policy remains the right target; the order of operations is what is non-negotiable: authenticate first, observe alignment in the reports next, harden last. DMARCbis even provides a clean trial tool, the t=y tag, which signals to receivers that a policy is in test mode — the acknowledged successor of the old pct, gone from the current revision.

In summary

By default, Mailchimp authenticates its own domains, not the brand's: SPF and DKIM pass, nothing aligns, DMARC fails — and since the major providers' requirements, the From gets rewritten to a platform domain whenever authentication is missing. The fix comes down to a few CNAMEs under _domainkey, which make campaigns sign in the domain's name: DKIM aligns, and that is enough, because SPF alignment is structurally out of reach with this provider — the envelope stays on its servers. RUA reports supply the proof of the flip, the dedicated subdomain isolates marketing reputation, and the move toward p=reject comes after the proof, never before.

To situate the starting point, running the domain through a free DMARC analysis shows within seconds whether campaigns already sign in the domain's name or still in the platform's. From there, creating an account makes it possible to follow the flip in the reports, campaign after campaign, all the way to a strict policy that protects the brand without losing a single newsletter.