1 May 2026 · 13 min read
Postmark is a transactional email service, so almost everything it sends is something a recipient is waiting for: a password reset, a receipt, a shipping update, a one-time code. That makes deliverability unusually high stakes. A marketing blast that lands in spam is annoying; a password reset that lands in spam is a support ticket and a lost customer. Getting SPF, DKIM and DMARC right for Postmark is therefore not a nice-to-have, it is part of the product working.
This guide is specific to Postmark. It covers the exact DNS records Postmark asks you to publish, why the custom Return-Path matters more here than with most providers, how alignment actually works for Postmark mail, and how to move your domain to p=reject without breaking the very emails your users depend on. If you also send through Google Workspace, Microsoft 365 or another platform, you will need to combine what is below with those sources, and that combination is exactly where most enforcement projects go wrong.
How Postmark fits into SPF, DKIM and DMARC
When Postmark sends on your behalf, three separate identities are in play, and DMARC only cares about two of them.
- The From address your recipient sees, for example
receipts@yourbrand.com. This is the address that must align. - The Return-Path (also called the envelope sender, MAIL FROM or bounce address), which SPF actually authenticates. By default Postmark uses its own domain here, which is why a custom Return-Path matters.
- The DKIM signing domain (the
d=value in the signature), which DKIM authenticates.
DMARC passes when at least one of SPF or DKIM both passes its own check and is aligned with the From domain. Alignment means the authenticated domain matches the From domain (the organisational domain by default, an exact match under strict alignment). With Postmark, DKIM is the alignment you can rely on for forwarded mail, and SPF alignment depends entirely on whether you configure a custom Return-Path. Both are worth doing.
If you want to see what your domain currently publishes before you change anything, run it through the DMARC checker and the SPF checker. That gives you a baseline so you can prove the change worked rather than hoping it did.
SPF for Postmark
The Postmark SPF include
Postmark sends through the host spf.mtasv.net. To authorise it in SPF, that include goes into the single SPF TXT record on your sending domain (or, with a custom Return-Path, on the Return-Path subdomain, more on that below).
A domain that sends only through Postmark would publish:
v=spf1 include:spf.mtasv.net ~allIf you also send through Google Workspace and, say, Mailchimp, you combine them into one record. You must not publish two separate v=spf1 records: receivers treat that as a permanent error and SPF fails outright.
v=spf1 include:_spf.google.com include:spf.mtasv.net include:servers.mcsv.net ~allNote the mechanism order does not matter for the result, but the lookup count does. SPF allows a maximum of 10 DNS lookups across the whole record, including everything pulled in by nested includes. include:spf.mtasv.net is economical (Postmark keeps its include flat), but stacking several providers can quietly push you over 10, at which point SPF returns permerror and effectively fails. The SPF checker counts your lookups for you; if you are close to the limit, look at the SPF record flattening approach rather than just adding more includes.
~all versus -all
Use ~all (softfail) while you are still discovering every legitimate sender. Once DMARC reporting confirms that every source of your mail is accounted for, you can tighten to -all (hardfail). With a correct DMARC policy at enforcement, the practical security difference between ~all and -all is small, because DMARC is the control that actually rejects spoofed mail. Do not rush to -all before you are certain your inventory is complete.
Why SPF alone is fragile for transactional mail
By default, Postmark sets the Return-Path to its own domain (something under pm.mtasv.net). SPF then authenticates Postmark's domain, not yours. SPF passes, but it is not aligned with your From domain, so it does nothing for DMARC. This is the single most common reason a Postmark setup shows "SPF: pass" in the headers yet still fails DMARC on the SPF side. The fix is a custom Return-Path, covered after DKIM.
DKIM for Postmark
DKIM is the load-bearing mechanism for Postmark, because a DKIM signature survives forwarding and mailing lists, where SPF usually breaks. Postmark signs every message, and once you enable DKIM with your own domain, the signature carries d=yourbrand.com, which gives you aligned DKIM and therefore a reliable DMARC pass.
Enabling and publishing DKIM
In the Postmark dashboard, under Sender Signatures or Domains, add your sending domain and request DKIM. Postmark generates the DKIM keys and shows you the DNS records to publish. Modern Postmark setups use CNAME records that point at Postmark-hosted keys, which means Postmark can rotate keys for you without you touching DNS again.
A current Postmark DKIM record looks like a CNAME on a selector hostname under your domain, pointing into dkim.mtasv.net:
Type: CNAME
Host: 20240101234500pm._domainkey.yourbrand.com
Value: 20240101234500pm.dkim.mtasv.netThe selector (the long timestamped label ending in pm) is generated per domain, so copy the exact host and value Postmark shows you rather than the example above. Some older Postmark accounts were given a single static selector pm._domainkey as a TXT record containing the public key directly:
Host: pm._domainkey.yourbrand.com
Type: TXT
Value: k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...If you are on the TXT style, the value is a fixed public key and you own rotation; the CNAME style is preferable because Postmark handles rotation. Either way, the principle is the same: the selector lives at selector._domainkey.yourbrand.com, and the signature on outgoing mail references that selector with d=yourbrand.com.
After publishing, confirm Postmark marks the domain as verified, then independently verify the published record with the DKIM checker. Enter your domain and the Postmark selector. If Postmark says "pending" for longer than your DNS TTL, the usual culprits are a trailing dot or your provider auto-appending the domain so you end up with pm._domainkey.yourbrand.com.yourbrand.com. Check the fully qualified name carefully.
Why DKIM alignment is the goal
A signature where d= is pm-bounces.mtasv.net or any Postmark-owned domain passes DKIM but is not aligned to your From domain, so it earns you nothing under DMARC. The whole point of enabling DKIM with your own domain in Postmark is to make d=yourbrand.com. When you read a message's headers, you are looking for DKIM-Signature: ... d=yourbrand.com;. That, plus a From of @yourbrand.com, is aligned DKIM and a durable DMARC pass.
The custom Return-Path: the step most Postmark setups skip
This is the part that separates a setup that merely "works" from one that passes DMARC on both mechanisms and survives edge cases.
By default Postmark's Return-Path is on its own domain, so SPF authenticates Postmark and never aligns with you. A custom Return-Path moves the envelope sender onto a subdomain of your own domain, which makes SPF align too.
In Postmark, set the custom Return-Path (often labelled "Custom Return-Path" or "Custom bounce domain") for the domain. Postmark gives you a subdomain, commonly pm-bounces, to publish as a CNAME:
Type: CNAME
Host: pm-bounces.yourbrand.com
Value: pm.mtasv.netOnce that resolves and Postmark verifies it, the Return-Path on your mail becomes something like something@pm-bounces.yourbrand.com. Now SPF is evaluated against pm-bounces.yourbrand.com, which is a subdomain of your organisational domain, so under relaxed alignment (the DMARC default) SPF passes and aligns. You now have both SPF and DKIM aligned.
Why bother, if DKIM alignment already gives you a DMARC pass? Three concrete reasons:
- Redundancy. If a DKIM signature is ever broken in transit (a forwarder that rewrites the body, an aggressive content filter), aligned SPF is your fallback so DMARC still passes.
- Bounce handling. A custom Return-Path on your domain keeps bounce processing cleanly associated with your brand rather than Postmark's shared domain.
- Reputation clarity. Receivers see a consistent organisational domain across From, Return-Path and DKIM, which is exactly the coherent signal DMARC was designed to reward.
Do this even though it is optional in Postmark's onboarding. It is fifteen minutes of DNS and it removes a whole class of "why did this one message fail DMARC" investigations later.
Putting the DNS records together
For a domain yourbrand.com sending only through Postmark, with both DKIM and a custom Return-Path configured, your Postmark-related DNS looks like this (selectors will be your own):
; SPF on the From domain
yourbrand.com. TXT "v=spf1 include:spf.mtasv.net ~all"
; DKIM (CNAME style, Postmark-managed rotation)
20240101234500pm._domainkey.yourbrand.com. CNAME 20240101234500pm.dkim.mtasv.net.
; Custom Return-Path for SPF alignment
pm-bounces.yourbrand.com. CNAME pm.mtasv.net.
; DMARC policy (start at none, see below)
_dmarc.yourbrand.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com; fo=1"If you publish through a registrar that does not let you create the records by hand, our guide on publishing DNS records at common providers walks through the dashboards. The general pattern for stacking Postmark with other senders is covered in SPF for common providers.
Reaching DMARC enforcement when sending through Postmark
The goal is p=reject (or at least p=quarantine) so that anyone forging your From domain is rejected, while every genuine Postmark message sails through. You reach it in deliberate stages, driven by data, not guesswork.
Stage 1: publish p=none with reporting
Start in monitoring mode. This changes nothing about delivery; it just asks the world's receivers to send you reports.
_dmarc.yourbrand.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com; fo=1"The rua address collects aggregate XML reports. The fo=1 flag asks receivers to send a failure report whenever any underlying check fails, which is useful while debugging. If you do not yet have a DMARC record, generate one with the DMARC generator, and if you are unsure what the tags mean, the glossary defines each one.
Stage 2: read the reports and confirm Postmark aligns
Aggregate reports are XML and unpleasant to read raw. Drop them into the DMARC report analyzer, or have them parsed automatically with continuous monitoring. What you are checking:
- Mail sent through Postmark shows DKIM aligned, pass with
d=yourbrand.com. - If you configured the custom Return-Path, that same Postmark mail also shows SPF aligned, pass against
pm-bounces.yourbrand.com. - No legitimate source is failing. Transactional senders are notorious for hiding a few extra sources: a billing system using its own Postmark server, a status-page tool, a CRM that also sends through your domain. Every one of those must be authenticated before you enforce.
Stay here until you have a few weeks of clean reports covering your real sending patterns, including monthly or low-volume flows like invoices and renewal notices.
Stage 3: move to p=quarantine, optionally with pct
Once Postmark and every other legitimate source pass aligned, tighten the policy. You can ramp gradually using pct so only a percentage of failing mail is affected at first.
_dmarc.yourbrand.com. TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourbrand.com; fo=1"Watch reports for a week, raise pct to 50, then 100, then graduate to reject. The pct ramp is your safety valve: if something you missed starts failing, you see it in reports while only a quarter of it is being quarantined, and you can react before it becomes a full block.
Stage 4: enforce with p=reject
When quarantine at pct=100 has run cleanly, switch to reject:
_dmarc.yourbrand.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourbrand.com; fo=1"Now forged mail using your domain is rejected at the receiving server. Your Postmark transactional mail, signed with d=yourbrand.com and (with the custom Return-Path) SPF-aligned too, passes cleanly. This is also the policy that satisfies the bulk-sender requirements at Google and Yahoo; see requirements for the full checklist those mailbox providers enforce.
Keep reporting switched on permanently. Enforcement is not a one-time project. New tools get added, DNS records get edited by mistake, a key gets rotated wrongly. Reporting is how you find out before your customers do.
Strict versus relaxed alignment with Postmark
DMARC alignment defaults to relaxed, which means a subdomain counts as aligned with the organisational domain. This is what lets pm-bounces.yourbrand.com (Return-Path) align with yourbrand.com (From) for SPF. If you set strict alignment with aspf=s, that subdomain Return-Path would no longer count as SPF-aligned, because strict requires an exact domain match.
Practical advice: leave alignment relaxed unless you have a specific reason not to. Strict DKIM (adkim=s) is achievable with Postmark because you control the d= value, but strict SPF will break the custom Return-Path benefit. There is rarely a security gain worth that trade-off for transactional mail.
Subdomains: send transactional mail from a dedicated one
A pattern worth adopting from the start: send Postmark mail from a subdomain such as mail.yourbrand.com or notifications.yourbrand.com rather than the bare apex. Reasons:
- It isolates transactional reputation from anything else on the apex.
- It keeps DNS tidy: the subdomain gets its own SPF, DKIM and Return-Path records.
- It lets you set a focused subdomain DMARC policy without waiting for every other apex sender to be ready.
Remember that DMARC has a subdomain policy tag, sp. If you publish p=reject on the apex but want a different treatment for subdomains during rollout, set sp explicitly. If you leave sp out, subdomains inherit the apex p. The DMARC record guide explains how sp and the organisational-domain rules interact.
Troubleshooting common Postmark authentication failures
Postmark shows the domain verified, but DMARC reports show SPF unaligned. You enabled DKIM but not the custom Return-Path. SPF is authenticating Postmark's own bounce domain. Add the pm-bounces CNAME and the SPF side will align. DKIM alignment was already carrying your DMARC pass, which is why mail still delivered.
DKIM verification stuck on pending in Postmark. Almost always a DNS entry problem: a doubled domain suffix (pm._domainkey.yourbrand.com.yourbrand.com), a CNAME entered as a TXT or vice versa, or a TTL that has not expired yet. Verify the exact record with the DKIM checker and compare it character for character with what Postmark displays.
SPF permerror after adding Postmark. You exceeded the 10-lookup limit by stacking includes, or you accidentally created a second v=spf1 record. Run the SPF checker; it reports both conditions. Consolidate into one record and reduce lookups.
One specific type of email fails DMARC, the rest pass. A different system is sending as your domain and is not going through your authenticated Postmark setup. The DMARC report analyzer will show the source IP and the failing identifier so you can track down the rogue sender.
Mail to a mailing list or auto-forwarder fails SPF but DMARC still passes. That is DKIM doing its job. SPF breaks across forwarding because the forwarder becomes the new envelope sender; the DKIM signature survives intact, alignment holds, DMARC passes. This is exactly why DKIM is the mechanism to get right first.
If you want to confirm the full picture for your domain in one pass, the DMARC checker reports policy, alignment and the records receivers actually see, and the MTA-STS checker and BIMI checker cover the next layers once authentication is solid.
The practical takeaway
For Postmark specifically, the winning configuration is short and unambiguous:
- Add
include:spf.mtasv.netto your one SPF record, keeping total lookups under 10. - Enable DKIM in Postmark and publish the CNAME selector so signatures carry
d=yourbrand.com. This is your reliable, forwarding-proof DMARC pass. - Configure the custom Return-Path (
pm-bouncesCNAME topm.mtasv.net) so SPF aligns too and you have redundancy. - Publish
p=nonewithruareporting, confirm Postmark and every other sender align, then ramp throughquarantineandpcttop=reject.
The order matters: DKIM gives you the alignment, the custom Return-Path makes it robust, and reporting is what lets you reach reject without a single failed receipt or password reset along the way.
If you would rather not run the staged rollout by hand, our done-for-you DMARC service takes a Postmark-sending domain from p=none to p=reject for you, watches the reports, and alerts you the moment a record changes or a new sender appears. Start by running your domain through the DMARC checker to see exactly where it stands today.