Set up DMARC with Postmark

Postmark documents the very point most platforms leave in the shade: its custom Return-Path is not a convenience setting, it is what makes SPF alignment possible.

Two records

(provided selector)._domainkey  TXT    (DKIM public key)
pm-bounces                      CNAME  pm.mtasv.net

The first signs your messages. The second creates the return address on your domain. The pm-bounces prefix can be changed freely: it simply has to be identical in your DNS zone and in the Postmark interface, or verification fails.

What the Return-Path changes

Without it, the envelope address stays Postmark’s: SPF passes and does not align, and DKIM alone gets DMARC through. With it, the return address becomes a subdomain of yours, relaxed alignment ties it to your domain, and SPF and DKIM both align.

That is not pointless redundancy: DKIM survives forwarding, SPF survives content being altered by a relay. Having both is compliance that holds in the edge cases.

DMARC

Publish the monitoring policy on _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:your-address@yourdomain.com

Only tighten once every sender is identified. The progression, step by step.

Common mistakes with Postmark

• Skipping the custom Return-Path. Everything works, until the day a DKIM signature is broken by an intermediary and nothing is left.
• A different prefix in DNS and in the interface. Verification fails without saying why; the two must match exactly.
• Confusing sender signature with domain verification. The first authorises one address, the second the whole domain — and only the second requires DKIM.
• Adding a Postmark include to your root SPF. The custom Return-Path makes that unnecessary.

Once it is in place, Clarsend reads your reports and shows you what passes, what fails, and who is sending without your knowledge.