Third-party senders and DMARC
Your own mail server is rarely the problem. The sources that fail DMARC are almost always the third parties sending as your domain: the newsletter platform, the transactional email service behind your app, the CRM, the helpdesk, the billing tool. Each one puts your domain in the From header — and each one, out of the box, authenticates as itself, not as you.
The good news: every reputable email service provider solves this the same way. Learn the pattern once and you can align any of them.
The universal pattern
DMARC needs at least one authentication check to pass aligned — with your domain, not the ESP's. There are exactly two ways an ESP can give you that, one per mechanism (the full logic is in DMARC alignment explained):
- Custom return-path → SPF alignment. By default the ESP uses its own domain in the envelope-from, so its SPF pass belongs to its domain. The fix is a custom return-path: you publish a CNAME on a subdomain of your domain (something like
bounce.example.com) pointing at the ESP, and the ESP starts using that subdomain as the envelope-from. Now SPF passes on a subdomain of yours — aligned under DMARC's default relaxed mode. - Custom DKIM domain → DKIM alignment. By default the ESP signs with its own domain (
d=espmail.com). The fix is publishing the DKIM record the ESP generates for you — usually a CNAME or TXT onsomething._domainkey.example.com— after which it signs withd=example.com. See What is DKIM? for what thatd=means.
DMARC only requires one, but set up both where the ESP offers both: DKIM survives forwarding while SPF doesn't, and redundancy means one misconfiguration doesn't take your mail stream below the line.
Worked example: Postmark
Postmark's flow is representative. When you add your domain, its dashboard hands you two DNS records:
- A DKIM TXT record — a generated selector under
._domainkeyon your domain, with the public key as the value. Copy both name and value exactly from the Postmark dashboard. - A return-path CNAME — by default on the
pm-bouncessubdomain:
pm-bounces.example.com. CNAME pm.mtasv.net
Publish both, let Postmark verify them, and mail sent through Postmark passes DKIM aligned (signed d=example.com) and SPF aligned (envelope-from on pm-bounces.example.com). Note what you did not do: you never touched your own SPF record. The return-path CNAME delegates that subdomain to Postmark, and Postmark manages SPF for it behind the CNAME.
SendGrid, Mailgun, Mailchimp and the rest
Every major ESP has its own name for this — "domain authentication", "sending domains", "domain verification" — but the underlying DNS work is the same pattern: one or more CNAMEs for DKIM, plus a custom return-path where the ESP offers one. Mailchimp, for instance, provides DKIM only, so its campaigns rely on DKIM alignment alone; Mailgun places SPF directly on your sending subdomain with a TXT record rather than a CNAME return-path. The hostnames and targets are generated per account — so don't copy values from a blog post or from this article. Open your ESP's domain-authentication page and publish exactly what it shows you, then use its verify button.
Two caveats worth knowing:
Shared IPs. Most ESP plans send from IP pools shared with other customers. That's fine for DMARC — alignment ties mail to your domain, not your IP — but it means "the IP is authorised" proves little by itself, and your deliverability partly rides on pool hygiene. It's also why you shouldn't add an ESP's include: to your root SPF record when a custom return-path is on offer: it burns DNS lookups and authorises a shared pool for your bare domain without helping alignment at all.
Alignment is per-sender. Aligning Postmark does nothing for Mailchimp. Inventory every service that sends as your domain and work through them one by one.
Watching it happen in DMARCmetric
This is exactly where a monitor earns its keep. DMARCmetric groups your sending sources by ESP — Postmark, Microsoft 365 and friends each appear as one row with a pass/fail verdict, so an unaligned newsletter tool stands out immediately, and you can watch it flip to passing once its DNS records land. You can see the grouped view with realistic data in the live demo, no account needed.
Once every legitimate third party is aligned — and only then — you're clear to move your policy from p=none towards quarantine and reject.