DMARCmetric

Third-party senders and DMARC

Updated 2026-07-08 · Setup Guides

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):

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:

  1. A DKIM TXT record — a generated selector under ._domainkey on your domain, with the public key as the value. Copy both name and value exactly from the Postmark dashboard.
  2. A return-path CNAME — by default on the pm-bounces subdomain:
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.

Still stuck?

We answer every message — usually within one business day.

Email [email protected]