Postmark SPF, DKIM and DMARC: the custom Return-Path matters

Postmark's setup has two parts and most people do only the first. The DKIM record signs your mail with a key under your domain, which is enough for DMARC to pass. The custom Return-Path CNAME moves the envelope sender onto a subdomain of yours, which gives you an aligned SPF pass as well. With both, either mechanism can carry DMARC on its own — that redundancy is the point.

The records

Take the DKIM host and value from Postmark's *Sender Signatures* or *Domains* screen — the selector and key are account-specific and cannot be copied from anywhere else. The Return-Path subdomain name is yours to choose in Postmark's settings; pm-bounces is the conventional one.

Postmark documents include:spf.mtasv.net for senders who want it in their own SPF record, but check what your mail actually does before adding it. With a custom Return-Path configured, SPF is evaluated against the delegated subdomain, so an include at your apex is spending one of your 10 DNS lookups for nothing.

Verify from outside the dashboard

dig +short TXT   <selector>._domainkey.yourdomain.com
dig +short CNAME pm-bounces.yourdomain.com
dig +short TXT   pm-bounces.yourdomain.com
dig +short TXT   _dmarc.yourdomain.com

The CNAME should resolve into mtasv.net, and the TXT query on the same host should return a v=spf1 ... record served behind it. If the DKIM TXT query returns nothing:

• Your DNS panel appended the zone and you now have selector._domainkey.yourdomain.com.yourdomain.com. Enter only the relative host.
• The 2048-bit key exceeded the 255-character limit for a single TXT string. Split it into multiple quoted strings inside one record; the resolver concatenates them. A second record is not the same thing.
• You are reading a cached answer. Add @8.8.8.8.

Keep both records DNS-only. A CNAME proxied through a CDN returns the proxy's address rather than following the delegation.

What the three records do, precisely

SPF authorises servers to use a domain in the SMTP envelope — the MAIL FROM, which arrives as Return-Path. It never looks at the From header your recipient reads. It also breaks on forwarding, permanently, because the forwarding server cannot be in your record.

DKIM signs selected headers and a hash of the body with a private key, and publishes the public half in your DNS at a selector. A valid signature survives forwarding as long as nothing rewrites the message, which makes it the more durable of the two.

DMARC requires that at least one of those passes *in alignment* with the From domain, and tells receivers what to do otherwise. Relaxed alignment (the default) accepts any subdomain of the organisational domain, which is exactly why a custom Return-Path on pm-bounces.yourdomain.com aligns with yourdomain.com.

Confirm with a real message

Return-Path: <bounce@pm-bounces.yourdomain.com>
From: Receipts <receipts@yourdomain.com>
Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=pm-bounces.yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

Two aligned passes. If smtp.mailfrom shows a domain you do not own, the custom Return-Path is not configured and you are relying on DKIM alone — workable, but one broken selector away from dmarc=fail.

DMARC and the policy path

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

A week at p=none, an inventory of every sender from the aggregate reports, fixes so each one signs with an aligned key, then p=quarantine, then p=reject. Set sp= explicitly once you enforce. If rua points at another domain, that domain must publish v=DMARC1 at yourdomain.com._report._dmarc.<their-domain> or compliant receivers discard the reports.

Transactional mail is the easiest category to get to p=reject, because the sender list is short and stable. Do it — receipts and password resets are exactly the mail attackers want to impersonate.

Separating transactional from marketing

If the same domain sends receipts and campaigns, a bad campaign's complaint rate affects the deliverability of password resets. The standard fix is streams on separate subdomains — transactional on one, marketing on another — each with its own DKIM selector and its own reputation. Postmark's message streams separate the sending logic; subdomains separate the reputation. Do both.

The requirements all large receivers now enforce

Google and Yahoo set bulk-sender requirements in February 2024 and Microsoft followed for consumer Outlook addresses in 2025. The shared core: SPF and DKIM published, at least one passing in alignment, a DMARC record of p=none or stricter, one-click unsubscribe on bulk mail, valid forward and reverse DNS on sending hosts, and complaint rates held low — Google publishes 0.3% as the threshold. Transactional senders are not exempt from the authentication parts.

What not to do

• Do not skip the custom Return-Path. It is one CNAME and it buys you a second aligned mechanism.
• Do not publish the DKIM key as two TXT records.
• Do not add an ESP's SPF include without checking the Return-Path first; if the envelope is elsewhere, the include is dead weight against a hard 10-lookup limit.
• Do not send marketing and transactional mail from the same subdomain.
• Do not enforce DMARC before reports confirm every sender is aligned.

MailPilot warms mailboxes over OAuth or SMTP/IMAP — Postmark, SendGrid, Amazon SES, Mailgun and custom SMTP included — checks SPF, DKIM and DMARC on the sending domain, and measures per-provider inbox placement with a seed-inbox network.