Skip to main content
How-to DMARC

Authenticate Your Email Service Providers (SendGrid, Mailchimp) for DMARC

Your ESP passes SPF and DKIM, just for its own domain, not the one in your From line. That is unaligned, so DMARC fails even though authentication passed. The durable fix is a DKIM CNAME that lets the ESP sign as your domain.

Watch

Why ESPs like SendGrid and Mailchimp pass auth but fail DMARC (alignment), and the DKIM CNAME fix.

June 11, 2026 · 7 min read

TL;DR

  • 1 ESPs like SendGrid and Mailchimp pass SPF and DKIM for THEIR domain, not the domain in your From line, so they are unaligned and DMARC fails even though auth passed.
  • 2 The durable fix is the CNAME records the ESP gives you so it signs DKIM with YOUR domain (aligned); most ESPs support this.
  • 3 SPF includes help but watch the 10-lookup limit. DKIM alignment is what matters, and it survives forwarding.

What it does

When you start sending through an email service provider (SendGrid, Mailchimp, Mailgun, and the rest), a confusing thing happens: the ESP's mail passes SPF and passes DKIM, and yet your DMARC reports show those exact sends <em>failing</em> DMARC. Nothing is broken in the usual sense. Authentication is succeeding. It is just succeeding for the wrong domain.

The reason is alignment. By default an ESP authenticates with <strong>its own</strong> domain: SPF passes for the ESP's bounce domain, and DKIM is signed with the ESP's signing domain. DMARC does not ask "did SPF or DKIM pass?" It asks "did the domain that passed match the domain in the From line?" Your From says <code>you@yourbrand.com</code> while the ESP authenticated as <code>esp.example</code>, so neither identifier aligns and DMARC fails despite the green checkmarks on SPF and DKIM.

These pass-but-unaligned sources are the single most common surprise on the road to DMARC enforcement, because they look like an attack in the failure totals but are entirely legitimate. The durable fix is to make the ESP authenticate as you: the provider hands you CNAME records that let it sign DKIM with <em>your</em> domain. Once the signing domain aligns with your From, the same send that was failing now passes, and it keeps passing even when the message is forwarded.

How it works

  1. 1

    <strong>Why pass-but-unaligned happens.</strong> SPF authenticates the Return-Path (the ESP's bounce domain), and DKIM authenticates whatever domain is in the signature's <code>d=</code> tag (the ESP's signing domain by default). Both can pass cleanly while neither matches your From domain. PhishFence classifies a source exactly this way: when authentication passed but did not align, it is labeled a fixable, legitimate sender rather than spoofing, distinguishing it from a genuine unrecognized source by the presence of a real <code>spf_pass_unaligned</code> or <code>dkim_pass_unaligned</code> signal from a recognized ESP.

  2. 2

    <strong>The DKIM CNAME fix (this is the one that matters).</strong> Most ESPs let you publish CNAME records that point selector hostnames under your domain at keys the ESP controls. The ESP then signs with a <code>d=</code> of your domain, so DKIM is aligned. This is the durable fix because DKIM alignment <em>survives forwarding</em>: a mailing list or auto-forward breaks SPF at the new hop, but the original DKIM signature travels with the message and still validates and aligns.

  3. 3

    <strong>SPF includes help, but mind the 10-lookup limit.</strong> Adding the ESP's <code>include:</code> to your SPF record can give you aligned SPF, but SPF authenticates the Return-Path, which many ESPs keep on their own bounce domain regardless, so SPF alignment is not always achievable. Worse, every <code>include</code> consumes from the RFC 7208 budget of 10 DNS lookups; cross 10 and the whole record returns PermError and receivers silently reject your authentication. Treat SPF includes as a supplement, not the foundation.

  4. 4

    <strong>DKIM alignment is the foundation.</strong> Because it is achievable on essentially every ESP, does not consume the SPF lookup budget, and survives forwarding, aligned DKIM is what a durable setup is built on. Get the ESP signing as your domain and the pass-but-unaligned failures clear.

  5. 5

    <strong>Verify against your DMARC reports.</strong> After publishing the CNAMEs and letting the ESP confirm them, your DMARC aggregate reports should reclassify that source from failing to passing. The same per-source view that flagged the pass-but-unaligned sender is where you confirm the fix took.

Common pitfalls

  • <strong>Reading "SPF pass, DKIM pass" as "DMARC will pass."</strong> It will not, unless one of those identifiers aligns with your From domain. The pass is necessary but not sufficient; alignment is the missing half.

  • <strong>Trying to fix it with SPF includes alone.</strong> Many ESPs keep the Return-Path on their own bounce domain, so SPF can never align no matter how many includes you add, and each include eats into your 10-lookup budget. DKIM alignment is the path that actually works.

  • <strong>Blowing the SPF 10-lookup limit while adding ESPs.</strong> Each new ESP <code>include</code> adds lookups. Cross 10 and the record PermErrors, taking your authentication down for <em>every</em> sender, not just the one you were adding.

  • <strong>Ramping DMARC to reject before the ESP is aligned.</strong> If your ESP is still sending pass-but-unaligned, moving to <code>p=reject</code> will quarantine or block your own legitimate marketing and transactional mail. Align the ESP first, confirm it in reports, then ramp.