Why does my email fail DMARC through Mailchimp, SendGrid, or Klaviyo?

Your campaign sent fine. The ESP dashboard shows green checks next to SPF and DKIM. Then a DMARC aggregate report lands and tells you the same mail failed. Both things are true at once, and the gap between them is why people ask “why does my email fail DMARC” when they send through a marketing platform.

The cause is identical across platforms, but the fix is not, so the answer has to be provider-specific. We will not re-explain alignment from the ground up. If you want the full mechanics, read how SPF, DKIM, and DMARC alignment actually work and the companion post on why DMARC fails in general first. Here is the one-paragraph recap, then what Mailchimp, SendGrid, and Klaviyo do by default and the exact feature that fixes each one.

Last updated: May 29, 2026.

Why your email fails DMARC: alignment, not authentication

DMARC does not care whether SPF or DKIM passes on its own. It cares whether a passing mechanism is aligned with the domain in your visible From: header. DMARCbis states the rule plainly: “If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.” (Source: RFC 9989 §5.3.5.) Identifier alignment itself is defined in RFC 9989 §3.2.10, with relaxed and strict modes; adkim and aspf still default to relaxed. (RFC 9989 obsoletes RFC 7489, which stated the same rule historically in its §4.2.)

SPF authenticates the envelope sender (the Return-Path), and DKIM authenticates the d= domain in its signature. Neither of those is your From: header by default. When you send through an ESP, the platform signs DKIM with its own domain and bounces through its own Return-Path. SPF and DKIM both pass, but they pass for the ESP’s domain, not yours, so neither aligns with your From: and DMARC returns fail. The ESP reports success because, from its point of view, the mail authenticated correctly. The mechanism passes while the result fails to align, and that gap is the problem. See why ESPs and subdomains break DKIM alignment for the deeper version.

Here is what that looks like inside an aggregate report. Note how the raw auth_results show pass, while the alignment-evaluated policy_evaluated shows fail:

<record>
  <row>
    <source_ip>203.0.113.25</source_ip>
    <count>14</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>            <!-- alignment-evaluated -->
      <spf>fail</spf>             <!-- alignment-evaluated -->
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>bounce.mailer-esp.com</domain>
      <result>pass</result>       <!-- SPF passed, but for the ESP's domain -->
    </spf>
    <dkim>
      <domain>mailer-esp.com</domain>
      <selector>s1</selector>
      <result>pass</result>       <!-- DKIM passed, but d= is the ESP's domain -->
    </dkim>
  </auth_results>
</record>

The auth_results block is the mechanism layer (the aggregate report XML schema is defined in RFC 9990 Appendix A). The policy_evaluated block is the alignment verdict. When header_from is your domain and the SPF/DKIM domains are the ESP’s, that is the signature of an alignment failure. The fix is always the same in shape: move the DKIM d= and the Return-Path under your own domain. Each provider has its own feature name and record set for doing that.

Mailchimp DMARC: the “via mcsv.net” problem

What the default state looks like. Send a campaign from [email protected] without authenticating, and Mailchimp signs and bounces through its own shared infrastructure. Mailchimp states the sender address “is based on our sending servers and usually contains mcsv.net, mcdlv.net, mailchimpapp.net, or rsgsv.net.” (Source: Mailchimp: My Campaign’s From Name Shows mcsv.net.) That is why Gmail and Apple Mail show the “via mcsv.net” label next to your name. The DKIM d= is on a Mailchimp domain and the Return-Path is a Mailchimp bounce subdomain, so neither aligns with yourdomain.com and DMARC fails.

The fix: Email Domain Authentication. Mailchimp’s current feature is called Email Domain Authentication, available as a manual DNS entry or an automated flow through Entri. (Source: Mailchimp: Set Up Email Domain Authentication.) The setup adds two CNAME records for DKIM and one TXT record for DMARC, three records total. The two DKIM CNAMEs are selector records under your domain (the _domainkey host names) that delegate to Mailchimp’s key hosts, so the public key resolves under yourdomain.com and the signature can carry d=yourdomain.com. Mailchimp presents the exact Name/Value pairs in your account dashboard rather than printing literal targets in the help article, so copy them from there. (If you want the step-by-step with the records explained, see our Mailchimp DKIM setup guide.)

One correction worth stating, because stale third-party guides get it wrong: DMARC is a TXT record, not a CNAME. Only the two DKIM records are CNAMEs.

How to confirm. After authentication, Mailchimp signs DKIM with d=yourdomain.com and the “via mcsv.net” label disappears. Mailchimp describes authenticating as the step that makes emails “appear as if they originated from your servers.” (Source: Mailchimp: My Campaign’s From Name Shows mcsv.net.) A delivered message should then show dkim=pass header.d=yourdomain.com and dmarc=pass.

SendGrid DMARC: SPF and DKIM pass for sendgrid.net

What the default state looks like. SendGrid is explicit about this. “If no valid authenticated domains can be found, the sending domain defaults to sendgrid.net.” An unauthenticated message shows SPF pass for sendgrid.net and DKIM pass with header.d=sendgrid.net, while the From: header is your domain. (Source: SendGrid: Troubleshooting DMARC Failures due to SPF or DKIM Alignment Issues.) Both mechanisms pass, both authenticate sendgrid.net, neither aligns with your From: domain, so DMARC fails. This is the “SPF passed but DMARC still failed” case covered in SPF failure troubleshooting.

The fix: Domain Authentication. SendGrid’s feature is Domain Authentication (formerly “domain whitelabel”). (Source: SendGrid: How to Set Up Domain Authentication.) With Automated Security enabled, it provisions three CNAME records:

Record	Points to	Purpose
em####.yourdomain.com	u#######.wl###.sendgrid.net	Link branding and the Return-Path subdomain
s1._domainkey.yourdomain.com	s1.domainkey.u#######.wl###.sendgrid.net	DKIM selector 1
s2._domainkey.yourdomain.com	s2.domainkey.u#######.wl###.sendgrid.net	DKIM selector 2

Two selectors exist so SendGrid can rotate DKIM keys without an outage. (Source: SendGrid: Automated Security Domain Authentication.) The detail people miss: once Domain Authentication is in place, the em#### record already puts your Return-Path under yourdomain.com, so SPF aligns at the organizational-domain level even with the random em#### label. You do not need anything extra for alignment to work. See our walkthroughs for SendGrid SPF setup and SendGrid DKIM setup.

Where Custom Return Path comes in. SendGrid’s Custom Return Path is an advanced setting that lets you replace the em#### label with a subdomain you choose, so the Return-Path subdomain matches the subdomain in your From: address. (Source: SendGrid: How to Use Custom Return Path.) It is about branding and exact-subdomain matching, not about achieving organizational-level alignment, which Domain Authentication already gives you. If you are deciding which subdomain to use, the Return-Path and DMARC explainer covers the tradeoffs.

How to confirm. A correctly authenticated message shows dkim=pass header.d=yourdomain.com (via the s1/s2 selectors) and a Return-Path under em####.yourdomain.com (or your custom subdomain). Both are organizationally aligned with your From:, so DMARC passes.

Klaviyo DMARC: always misaligned on the shared domain

What the default state looks like. On Klaviyo’s shared sending domain, mail is automatically authenticated for SPF and DKIM, but Klaviyo is blunt about the consequence: “When sending on a shared sending domain, emails will always have a misalignment between your from-address (e.g., [email protected]) and the actual sending domain,” giving the example ksdn.klaviyomail.com. (Source: Klaviyo: Understanding DMARC and Klaviyo.) The Return-Path is also under klaviyomail.com, which is why clients show “via klaviyomail.com.” (Source: Klaviyo: How to Set Up a Branded Sending Domain.) SPF and DKIM pass for klaviyomail.com, neither aligns to yourbrand.com, DMARC fails.

The fix: branded sending domain. Klaviyo’s feature is the branded sending domain (also called a dedicated sending domain). It offers two routing modes, plus one TXT record for domain-ownership verification:

Routing mode	Records	Targets
Dynamic (Klaviyo-recommended)	4 NS records + 1 TXT	ns1.klaviyo.com through ns4.klaviyo.com
Static	3 CNAME records + 1 TXT	sending subdomain to 1.klaviyodns.com, DKIM km1/km2.domainkey.1.klaviyodns.com

(Source: Klaviyo: How to Set Up a Branded Sending Domain.) Note the CNAME targets are under klaviyodns.com, not klaviyomail.com. By delegating the subdomain, Klaviyo manages the DKIM and bounce records under your own subdomain. Klaviyo also auto-adds a DMARC TXT record with v=DMARC1; p=none;.

How to confirm. Klaviyo states that with a branded sending domain “the from-address domain aligns with the sending domain. As a result, DMARC checks will pass,” and the “via klaviyomail.com” label disappears. (Source: Klaviyo: Understanding DMARC and Klaviyo.) A delivered message should show DKIM d= on your subdomain and a Return-Path under your branded subdomain.

How to verify the fix for any provider

The mechanism layer and the alignment layer are different, so read both. In a delivered message’s full headers, the Authentication-Results line tells you the verdict:

Authentication-Results: mx.google.com;
       spf=pass [email protected];
       dkim=pass header.d=yourdomain.com header.s=s1;
       dmarc=pass header.from=yourdomain.com

Two things prove alignment succeeded:

• DKIM header.d= is your organizational domain (or a subdomain of it), not the ESP’s.
• Return-Path / SPF smtp.mailfrom is under your organizational domain, not the ESP’s bounce domain.

If either is true, you have one aligned passing mechanism, which is all DMARC requires. The quick visual proxy in Gmail and Apple Mail is the **“via " label disappearing**; that label generally appears when the sending domain does not match your `From:` domain, so its disappearance is a sign that alignment was achieved. Confirm with the header checks above before relying on it. For a definitive answer rather than a proxy, read your next aggregate report and look for `spf=pass` or `dkim=pass` inside the `policy_evaluated` block, which is the aligned result, not the raw mechanism result. The [DMARC troubleshooting hub](/blog/dmarc-troubleshooting-guides) collects the rest of these checks.

A note on setup guides: we have step-by-step walkthroughs for Mailchimp DKIM, SendGrid SPF, and SendGrid DKIM. We do not have a dedicated Klaviyo guide yet, so for Klaviyo follow the vendor article linked above and verify the result with the header checks here.

Confirming the fix without waiting a day

Diagnosing this per ESP usually means one of two slow paths: wait roughly a day for aggregate reports to arrive, or hand-read raw headers from a test send. Inbox Inspector shortens that loop. You drop a unique seed address into each ESP’s test or seed list, send a real campaign, and DMARCTrust receives it as a real mail server, then shows the SPF, DKIM, DMARC, alignment, and final disposition verdict for that exact message, with the ESP auto-detected. You confirm alignment in minutes instead of waiting for the next reporting cycle.