Postmark transactional mail already passes SPF out of the box because it sends through its own Return-Path on mtasv.net, so you do not need to add Postmark to your domain's SPF record at all. The two records that actually earn a DMARC pass are the DKIM TXT record Postmark generates for your domain and a custom Return-Path CNAME pointing at pm.mtasv.net. Get those two right and your From domain aligns cleanly, which is the whole point.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
The trap most Postmark guides fall into is treating "SPF passes" as "SPF is done." Those are different questions, and DMARC only cares about the second one. Below is exactly what to add, why each record exists, and how to verify it.
Why Postmark SPF is a non-issue (and why that confuses people)
When Postmark sends your mail, the envelope sender (the Return-Path, also called MailFrom) defaults to an address on Postmark's own domain, something on pm.mtasv.net. The receiving server checks SPF against that envelope domain, not against your From header. Because Postmark publishes a valid SPF record for its sending IPs, the SPF check passes every time.
So you will see spf=pass in the Authentication-Results header without touching your DNS. That is real, but it is a pass for Postmark's domain, not yours. If you go add include:spf.mtasv.net to your own SPF record hoping to "fix SPF," you are solving a problem that does not exist and burning one of your ten SPF DNS lookups for nothing. Leave your SPF record for the senders that actually use your domain in the envelope, such as Google Workspace or Microsoft 365.
The nuance that matters: an SPF pass on Postmark's domain does nothing for your DMARC result, because DMARC ignores authentication that is not aligned with your From domain. That is what the rest of this guide fixes.
SPF passing versus SPF aligning: the distinction that runs everything
DMARC does not ask "did SPF pass?" It asks "did SPF pass and does the domain SPF authenticated match the From header domain?" That second half is alignment.
- SPF pass: the sending IP is authorized for the Return-Path domain.
- SPF alignment: the Return-Path domain matches your From domain (relaxed alignment accepts a shared organizational domain, so
pm-bounces.yourdomain.comaligns withyourdomain.com).
With Postmark's default Return-Path on pm.mtasv.net, SPF passes but the authenticated domain is pm.mtasv.net, which has nothing to do with yourdomain.com. That is an SPF pass with no alignment, and it contributes zero to DMARC. This is the exact same shape as the classic DKIM fails while SPF passes confusion, just pointed at the SPF side. If you want the full mechanics, see relaxed versus strict DMARC alignment.
For DMARC to pass, you need at least one aligned authenticated identifier. Postmark gives you two ways to get there: aligned DKIM (the primary path) and aligned SPF via a custom Return-Path (the reinforcement). You want both.
Step 1: add the Postmark DKIM record
DKIM is your primary route to DMARC alignment with Postmark. When Postmark signs your message, it uses your domain in the d= tag, so a valid DKIM signature aligns with your From domain automatically.
In the Postmark account, open Sender Signatures or Domains, add your domain, and Postmark shows you a DKIM record. It is a TXT record on a selector hostname that looks like this:
selector._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."
Postmark assigns the selector for you, so copy the exact hostname and value from the console rather than guessing. If your DNS host will not accept a long TXT value on one line, split it into quoted strings; the resolver concatenates them. Some providers expose this as a CNAME-based DKIM instead of a raw TXT block. Either works, and if you want the tradeoffs read DKIM CNAME versus TXT.
After the record propagates, click Verify in Postmark. Once it goes green, every message Postmark sends carries a signature with d=yourdomain.com, which aligns and satisfies DMARC on its own.
Why DKIM alignment is the one that survives forwarding
DKIM is worth prioritizing because the signature travels with the message. When a recipient auto-forwards your email, the forwarding server changes the envelope sender, which breaks SPF at the next hop. This is why forwarding breaks SPF. The DKIM signature, being cryptographic and content-based, keeps validating as long as the body and signed headers are not modified. DKIM alignment is the more durable half of DMARC, which is why you never rely on SPF alone.
Step 2: add the custom Return-Path CNAME (pm.mtasv.net)
This is the step that gives you SPF alignment, and it is the one thrown-together guides skip. Postmark lets you set a custom Return-Path on a subdomain of your own domain. You pick a subdomain and point it at Postmark with a CNAME:
pm-bounces.yourdomain.com CNAME pm.mtasv.net
Once you set this in both Postmark and DNS, Postmark uses pm-bounces.yourdomain.com as the envelope sender instead of its own pm.mtasv.net address. Now the SPF check runs against your subdomain. The CNAME resolves to Postmark's infrastructure, SPF still passes, and because the envelope domain is now a subdomain of yourdomain.com, it aligns under relaxed alignment with your From domain.
The result: SPF now passes and aligns for your domain, giving you a second independent path to a DMARC pass. If DKIM ever breaks on a particular message, aligned SPF still carries it. Belt and suspenders.
Use a dedicated subdomain like pm-bounces and do not reuse it for other services. If Postmark shows a different target hostname in your console than pm.mtasv.net, use exactly what the console displays.
Step 3: publish or confirm your DMARC record
With aligned DKIM and aligned SPF in place, you are ready for a DMARC policy that will actually pass rather than bounce your own mail. If you do not have a DMARC record yet, start at monitoring so you can watch results before enforcing:
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"
Let reports come in for a week or two, confirm Postmark and your other senders are aligning, then move the policy toward enforcement. The staged path from none to quarantine to reject is covered in DMARC policy: none, quarantine or reject, and the full record walkthrough is in how to set up DMARC. Do not jump straight to p=reject before you have verified alignment, or you risk quarantining legitimate mail from a sender you forgot about.
If the wider model of how these three records fit together is still fuzzy, SPF, DKIM and DMARC explained is the ground-up version.
Step 4: verify the finished result
Send a live test message from Postmark to an address you control, open the raw message, and read the Authentication-Results header. You want to see, for your domain:
dkim=passwithheader.d=yourdomain.comspf=passwith the Return-Path on yourpm-bouncessubdomaindmarc=pass
Then run your domain through the checker at the top of this page. It confirms the DKIM public key resolves, that the Return-Path subdomain is delegated correctly, and that your DMARC policy is present and syntactically valid, and it flags alignment gaps before your recipients' mail servers do. If DKIM shows up but alignment still fails, work through how to fix DKIM alignment.
Frequently asked questions
Do I need to add Postmark to my SPF record?
No. Postmark sends with its own Return-Path, so SPF passes without any change to your domain's SPF record. Adding include:spf.mtasv.net gives you nothing and wastes one of your ten SPF DNS lookups. The SPF work that matters is the custom Return-Path CNAME, not an include.
What is the pm.mtasv.net CNAME for?
It powers the custom Return-Path. By pointing pm-bounces.yourdomain.com as a CNAME to pm.mtasv.net, Postmark uses your subdomain as the envelope sender. SPF then passes for your subdomain and aligns with your From domain, giving DMARC a second valid path alongside DKIM.
Is DKIM alone enough for DMARC on Postmark?
Technically yes, because Postmark signs with d=yourdomain.com, which aligns and passes DMARC on its own. But you should still add the custom Return-Path for aligned SPF, because DKIM signatures can break when messages are forwarded or modified in transit. Two aligned identifiers are more resilient than one.
Why does my mail show spf=pass but dmarc=fail?
Because the SPF pass is for Postmark's pm.mtasv.net domain, which does not align with your From domain. DMARC ignores unaligned passes. Set up the custom Return-Path CNAME so SPF authenticates a subdomain of your own domain, and make sure DKIM is verified so at least one aligned identifier exists.