Learn · Email authentication
What is an ESP — and why does it fail DMARC?
An ESP (Email Service Provider) is any platform that sends email on your behalf: Mailchimp for newsletters, SendGrid or Mailgun for transactional mail, HubSpot or Klaviyo for marketing, Zendesk for support replies. Modern companies typically use several — and every one of them is a server that isn't yours, sending mail with your name on it. Getting them authenticated is where most of the real work in a DMARC rollout lives.
How an ESP sends "your" email
When Mailchimp sends your newsletter, the visible From says news@yourbrand.com — but the message leaves Mailchimp's servers, and by default it authenticates as Mailchimp: SPF evaluates a Return-Path on their domain, and the DKIM signature carries their d=. Both checks can genuinely pass — for the wrong domain.
DMARC's alignment rule exists for exactly this case: a pass only counts if the passing domain matches your From domain. Which yields the situation that confuses everyone the first time they see it in their reports:
"SPF: pass, DKIM: pass — DMARC: fail." The checks passed for the ESP's domain, not yours. Nothing is broken at the ESP; the mail just isn't aligned. Every legitimate wave of "unknown" traffic in a new DMARC deployment looks like this.
To see which side of this your domain is on, run it through the DKIM checker: if your ESP’s selectors are published under your domain, DKIM aligns and DMARC passes — custom DKIM is exactly what turns this failure into a pass.
The two settings that fix it
- Custom DKIM signing (the important one). Every serious ESP lets you authenticate your own domain — usually by adding two or three CNAME records they generate. After that, their signatures carry
d=yourbrand.com: DKIM passes aligned, DMARC passes, done. ESPs name this "authenticate your domain", "domain verification", or "custom DKIM". - Custom Return-Path (nice to have). Many ESPs also offer a custom bounce domain — a CNAME like
bounce.yourbrand.compointing at them — which makes SPF align too. With DKIM aligned it's technically redundant (DMARC needs only one), but it's cheap redundancy for the day a signature breaks.
Two rules of thumb while you're in the ESP's settings: send from a subdomain (news.yourbrand.com) rather than your apex when the ESP suggests it — relaxed alignment still passes DMARC and it compartmentalizes reputation; and never solve alignment by pasting an ESP's entire IP range into your apex SPF record — it burns your 10-lookup budget and authorizes far more than you need.
The audit loop
- Inventory. List everything that sends as your domain. You'll miss some — everyone does. The CRM someone trialed, the survey tool, the e-signature service.
- Watch your reports. Publish DMARC at
p=noneand let the aggregate reports complete your inventory: every sending IP shows up, including the forgotten ones. This is where sender identification earns its keep — Canny Pigeons resolves report IPs to named services, so "unknown source, 4,000 msgs" becomes "Klaviyo, not aligned yet". - Align each service. Custom DKIM first, custom Return-Path where offered. One service at a time; each fix shows up in the next day's reports.
- Then enforce. When every legitimate source passes aligned, you're clear to advance your policy toward reject.
One warning
Tightening DMARC before aligning your ESPs is the classic self-inflicted outage: your own newsletter lands in spam at p=quarantine, and at p=reject your invoices stop arriving. The order is always: monitor, align every ESP, then enforce — never the reverse.