Skip to content
DMARC
← Blog

Postmark: DKIM, custom Return-Path and DMARC alignment

By Thomas · virtual CISO · September 08, 2026

Postmark built its reputation on a precise niche: transactional mail — order confirmations, password resets, application notifications — with a deliverability standard that is its hallmark. That orientation shows in a clean authentication setup, different from the big generalist ESPs: where others stack three or four CNAMEs, Postmark relies on two distinct building blocks, the DKIM key and the custom Return-Path.

By default, a domain added to Postmark sends under the platform's identity: without the DKIM key published and without a custom Return-Path, the signature does not carry the displayed domain and the envelope stays on Postmark's technical domain. From DMARC's point of view, nothing aligns, and a p=reject policy rejects this otherwise legitimate traffic. Both records must therefore be placed before any policy escalation.

This guide covers the DKIM key and its direct alignment, the custom Return-Path that reaches for SPF alignment, the way DMARC validates the whole, the distinction between transactional and broadcast streams — which touches reputation, not authentication — then the common configuration mistakes and the final proof through RUA reports.

DKIM: the key in the domain's name

The first block is the DKIM signature. From the Postmark console, when a domain is declared, the platform generates a key pair and displays a TXT record to publish in the zone, under a selector it provides:

<selector>._domainkey.example.com.  TXT  "k=rsa; p=MIIBIjANBgkq…"

Once the TXT has propagated, verification in the console confirms the key is detected: from there, every outgoing message carries a d=example.com signature — the organisational domain itself. DKIM alignment is therefore secured from the outset, even in strict mode, with no technical subdomain interposed.

Postmark also handles rotation: renewing a key means generating a new pair in the console, publishing the new TXT, then switching once propagation is confirmed. The overlap principle — new selector active before removing the old one — is the same as for any key renewal, step by step: it avoids the window during which messages would leave without a valid signature. The key offered is 2048-bit, a robust length expected by the major providers; 1024, still accepted by older tools, should be avoided for any new configuration.

Sender signature or whole domain

Postmark distinguishes two levels of configuration, and confusing them is a frequent source of error. The sender signature verifies a single address — no-reply@example.com — through a simple confirmation email; it authorises sending from that address but places neither a domain DKIM key nor a Return-Path. The verified domain, by contrast, publishes the DKIM key and the Return-Path in the zone, and then covers every address on the domain with a single set of records.

For DMARC, only domain-level configuration brings alignment at scale: a lone sender signature leaves the rest of the domain's mail without an aligned signature. An account that started with a sender signature — the fastest path to a first test send — must therefore move to the verified domain as soon as several addresses send, or DMARC will fail on everything the isolated signature does not cover. It is a forgotten transition in many setups left at the prototype stage.

The custom Return-Path: aligning SPF

The second block settles SPF. By default, the envelope address — the Return-Path, which is what SPF actually checks — is on Postmark's technical domain (pm.mtasv.net). SPF does authenticate that domain, but it aligns with Postmark, not with example.com: SPF passes without aligning, which does not count for DMARC.

The answer is the custom Return-Path, placed as a CNAME in the domain zone:

pm-bounces.example.com.  CNAME  pm.mtasv.net.

This CNAME moves the envelope to pm-bounces.example.com, a subdomain of the organisational domain. In relaxed mode — DMARC's default — that subdomain aligns with example.com, and SPF aligns in turn. SPF resolution follows the CNAME to Postmark, which publishes the appropriate authorisation there: there is thus no include to add to the domain's root SPF, a point that sets Postmark apart from platforms requiring a change to the main SPF record.

DMARC alignment: the double guarantee

DMARC only validates a message if SPF or DKIM passes and aligns with the From domain. With both blocks in place, Postmark offers the favourable case: DKIM aligns through the d=example.com signature, SPF aligns through the custom Return-Path. Two mechanisms pass aligned.

That redundancy carries concrete value. If a forward changes the sending IP along the way, SPF breaks but DKIM survives; if a gateway rewrites the body and invalidates the signature, SPF holds. Under DMARCbis, the organisational domain that serves as the alignment reference is determined by the DNS tree walk rather than the old Public Suffix List, but the reasoning is unchanged. The annotated examples, tag by tag show how to set the _dmarc instruction once DKIM and Return-Path are in place — first at p=none, then tightening.

A subtle point on alignment modes deserves stating. With this setup, DKIM aligns in both relaxed and strict mode, since the signature carries the domain exactly. SPF, however, aligns only in relaxed mode — the envelope sits on the pm-bounces subdomain, not the bare domain. A DMARC policy that forced aspf=s would therefore drop SPF alignment and lean entirely on DKIM. For almost every domain, the default relaxed mode is the right choice; strict SPF is a deliberate, rarely needed hardening that this arrangement does not call for.

Worth noting: the custom Return-Path is not strictly required for DMARC to pass, since DKIM suffices on its own. But going without it means giving up the redundancy — and the day a signature drops, nothing catches the message. On transactional mail, where each message matters (a confirmation, a reset link), that redundancy is no luxury: the silent loss of such a message often translates into a blocked user, an abandoned cart or a support ticket.

Transactional and broadcast streams

Postmark separates sends into two stream types: transactional and broadcast. This distinction does not touch authentication — DKIM and SPF align the same way in both cases — but reputation. The transactional stream, with high deliverability stakes, is isolated from the broadcast stream, whose profile (volumes, complaint rates) differs; mixing the two would degrade the reputation of critical mail.

For DMARC, the consequence is indirect but useful to know: in aggregate reports, both streams appear under the same Postmark source, aligned identically. An alignment gap between them would signal an incomplete configuration on one — a rare case, but one that reading the reports catches. Stream separation is a matter of deliverability hygiene; authentication is settled once for the domain.

On higher volumes, Postmark offers dedicated IPs, reserved to an account. As everywhere, a fresh dedicated IP is warmed — ramped up in volume over several days — and that warm-up reads in delivery rates, never in alignment, which stays identical whatever the sending IP. Telling a deliverability dip due to a fresh IP from a genuine authentication defect is one of the direct benefits of aggregate reports: the former does not affect the SPF and DKIM columns, the latter does.

Common configuration mistakes

Several traps recur in the body of reports the free DMARC analyzer processes daily.

Omitting the custom Return-Path. DKIM suffices to make DMARC pass, so a missing CNAME goes unnoticed for a long time — until the day a signature drops and SPF, unaligned, catches nothing. Symptom in the reports: DKIM aligned, SPF authenticated but not aligned.

Publishing the DKIM key without verifying it. The TXT is in place, but the console has not confirmed detection: until the domain is marked verified, the signature is not guaranteed.

Reusing a configuration across domains. Each sending domain has its own DKIM key and its own Return-Path; copying one domain's records to another produces signatures that do not align.

Tightening the policy too early. Moving to p=reject before confirming through reports that all legitimate traffic aligns means risking the rejection of one's own transactional messages — precisely those one cannot afford to lose.

The final proof: RUA reports

The only proof that a configuration holds is not the Postmark console, but what recipients report. Once a _dmarc record is published with a rua= address, aggregate reports arrive within a few days and detail, source by source, what aligns and what fails. Reading the daily returns from the mailbox providers confirms that Postmark traffic is properly attributed to the domain: DKIM aligned, and SPF aligned as soon as the custom Return-Path has been placed.

A simple cadence is enough: a first read a few days after publishing the _dmarc record, once several recipients have reported, then a weekly glance while the policy stays at p=none. Postmark traffic is quick to recognise by its stable address ranges; any unaligned source stands out immediately — a forgotten Return-Path, a domain added without its key. Once alignment is confirmed over several days and across every flow, the move to p=reject carries no risk. The online analyzer reconstructs this state from the published records and the reports received, and places the domain on the path that leads to p=reject.

Related guides

About the author

Thomas — Thomas is the virtual CISO of DMARC.com: a copilot specialized in email authentication that walks organizations from p=none to p=reject without breaking their mail. His guides draw on real data from the DMARC Observatory and the RUA reports the platform analyzes.