SPF, DKIM & DMARC for Postmark.
Postmark authenticates your domain from the account-level Sender Signatures → Domains area, and — unusually for a provider that technically has an "SPF include" — it deliberately does NOT want you to paste a shared SPF line on your root domain. Instead you add two records that live on your own domain: a DKIM TXT key at a Postmark-assigned selector, and a custom Return-Path CNAME (pm-bounces.yourdomain.com → pm.mtasv.net). Once both verify, Postmark sends as your domain with DKIM signed by you and SPF passing on an aligned Return-Path, so DMARC passes cleanly — and you never publish include:spf.mtasv.net on your root at all.
Why authenticate Postmark?
Postmark is a transactional-first provider — password resets, receipts, order confirmations, one-time codes — so inbox placement isn't cosmetic, it's the whole product. Since February 2024, Gmail and Yahoo have required every sender to pass SPF, DKIM, and DMARC with alignment (strictly enforced for bulk senders around 5,000+ messages a day), and Microsoft began rejecting non-compliant mail in 2025. If you send through Postmark without verifying your domain, Postmark can still deliver, but the messages are DKIM-signed by Postmark's own domain and ride a Return-Path on pm.mtasv.net, so neither DKIM nor SPF aligns to your From address. That's tolerated at DMARC p=none, but the moment you (or anyone on a shared parent domain) move to p=quarantine or p=reject, unaligned Postmark mail gets quarantined or bounced. Verifying the domain fixes it in two records: DKIM aligns to your domain, the custom Return-Path makes SPF align too, DMARC passes on both, and the sending reputation you build accrues to your domain instead of Postmark's shared infrastructure.
The SPF reality for Postmark
Postmark does have a shared SPF include — the host is include:spf.mtasv.net (mtasv is Postmark's mail-transfer infrastructure domain) — but Postmark deliberately stopped asking customers to add it to their root, and for almost everyone that is the correct choice. Here's why: SPF is validated against the Return-Path (the envelope MAIL FROM), not your visible From address. By default, Postmark's Return-Path lives on its own domain (pm.mtasv.net), so SPF already passes — but it passes for Postmark's domain, which does NOT align with your From domain, so it can't help DMARC. Adding include:spf.mtasv.net to your ROOT SPF does nothing to fix that, because your root domain isn't what appears in the Return-Path; the include would just sit there consuming a lookup for no benefit. The right move is a custom Return-Path: add a CNAME at pm-bounces.yourdomain.com pointing to pm.mtasv.net. That subdomain inherits Postmark's own published SPF (a live lookup confirms pm.mtasv.net publishes v=spf1 include:spf.mtasv.net -all) plus the bounce MX records, so SPF passes there AND the Return-Path is now on your organizational domain — which means SPF aligns for DMARC. Bottom line: the shared include (spf.mtasv.net) exists, but the modern, recommended Postmark setup is a custom Return-Path CNAME plus a DKIM TXT key, with nothing added to your root SPF. The include is only worth touching in the rare case where you specifically send from your apex through Postmark and want an explicit authorization there — and even then Postmark says it isn't required.
Two ways to set it up
Custom Return-Path CNAME + DKIM (recommended)
- Add a DKIM TXT key and a pm-bounces CNAME → pm.mtasv.net; nothing goes on your root SPF
- SPF passes AND aligns because the Return-Path is now on your own domain, so DMARC passes on SPF and DKIM both
- Adds zero DNS lookups to your root SPF record — there's nothing to merge into it
- This is exactly what Postmark's dashboard prompts you to do; it's the supported path
Add include:spf.mtasv.net to your root SPF (unnecessary)
- You'd paste v=spf1 a mx include:spf.mtasv.net ~all onto your apex yourself
- Postmark explicitly says this is NOT required — and it does nothing for alignment
- On your root it can't help DMARC, because your root isn't the Return-Path Postmark uses
- Only conceivably relevant if you send from your bare apex through Postmark; costs a lookup for no gain otherwise
Step by step
- 1
Open Sender Signatures → Domains
Log in at account.postmarkapp.com, open Sender Signatures from the account menu, then switch to the Domains tab. Verifying the whole domain (not just a single confirmed sender) is what gives every address on your domain SPF/DKIM alignment.
- 2
Add your domain
Click Add Domain and enter yourdomain.com. Postmark creates the record set and opens the domain's DNS Settings page, where the DKIM and Return-Path rows wait to be verified.
- 3
Copy the DKIM record
On the DNS Settings page, note the DKIM row: a TXT record whose Hostname is a Postmark-assigned selector ending in pm._domainkey (for example 20260727pm._domainkey) and whose Value is a long v=DKIM1; k=rsa; p=… key. This selector and key are unique to your domain.
- 4
Copy the Return-Path record
In the Return-Path section, note the CNAME: Hostname defaults to pm-bounces (i.e. pm-bounces.yourdomain.com) and Value is pm.mtasv.net. This is the record that makes SPF align to your domain. You can change the pm-bounces label, but it must stay a CNAME to pm.mtasv.net.
- 5
Add the DKIM TXT record
In your DNS host, create a TXT record. Host = the selector Postmark shows (e.g. 20260727pm._domainkey), Value = the full v=DKIM1;… string, pasted exactly. Postmark issues 2048-bit keys, so the value is long — see the gotcha about splitting it if your panel enforces a 255-character-per-string limit.
- 6
Add the Return-Path CNAME
Create a CNAME record: Host = pm-bounces, Value = pm.mtasv.net. Do not add any other record (no TXT, no A) on the pm-bounces subdomain — a CNAME can't coexist with other record types on the same name.
- 7
Leave your root SPF alone
Do NOT add include:spf.mtasv.net to your apex SPF. It isn't required and does nothing for alignment. If you already have a root SPF record for other senders (Google Workspace, Microsoft 365, etc.), keep it as-is — the pm-bounces CNAME handles Postmark's SPF on its own subdomain.
- 8
Publish or keep one DMARC record
If you don't already have DMARC, add a TXT record at _dmarc pointing to v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. If you already have one, leave it — you only ever keep a single _dmarc record for the whole domain.
- 9
Click Verify in Postmark
Back on the domain's DNS Settings page, click Verify next to DKIM and Return-Path. Propagation is usually minutes but can take up to 24–48 hours; both rows turn green when they resolve.
- 10
Send a real test and Show original
Once verified, send a test from an address on your domain through Postmark, open it in Gmail, and use ⋮ → Show original. You want SPF: PASS and DKIM: PASS both showing yourdomain.com (not mtasv.net), plus DMARC: PASS.
Records to add
Postmark generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| TXT | 20260727pm._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC…DKIM key. The selector (the YYYYMMDDpm._domainkey label) and the key are unique to your domain — copy the exact values from Postmark's DNS Settings page. 2048-bit, so it may need splitting into quoted strings. |
| CNAME | pm-bounces | pm.mtasv.netCustom Return-Path. This is what makes SPF PASS and ALIGN for DMARC — it inherits Postmark's SPF (verified live: pm.mtasv.net publishes v=spf1 include:spf.mtasv.net -all) and the bounce MX from pm.mtasv.net. Keep it CNAME-only on this subdomain. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYour DMARC policy — one record per domain, separate from Postmark. Start at p=none to monitor. |
| TXT | @ | v=spf1 a mx include:spf.mtasv.net ~allNOT required and not recommended — do not add this. Postmark stopped asking for it; on your root it does nothing for Return-Path alignment. Shown only so you recognize the legacy include if you find it already there. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Postmark's setup costs against that budget.
Postmark's recommended setup adds 0 lookups — all 10 stay free for the senders that do need an include.
DKIM
DKIM in Postmark is a TXT record you publish yourself — not a CNAME delegation like SendGrid or Mailchimp. Postmark assigns you a date-based selector ending in pm._domainkey (for example 20260727pm._domainkey) and generates a 2048-bit RSA key; you create a TXT record with that Hostname and paste the full v=DKIM1; k=rsa; p=… value exactly as shown on the DNS Settings page. Because it's a TXT record holding the public key (Postmark keeps the private key), Postmark can't silently rotate it the way a CNAME-delegated provider can — instead Postmark offers a manual Rotate DKIM Key action that generates a fresh key under a new selector and shows you a pending record to publish; once the new TXT verifies, Postmark switches signing over and you can remove the old one. Rotating periodically (a couple of times a year is a reasonable cadence) is good hygiene. Importantly, a verified DKIM key on its own is enough to make Postmark mail pass DMARC, because DKIM aligns to your domain — the custom Return-Path is what additionally gives you SPF alignment.
DMARC
DMARC is a separate policy record on your root domain — it is not one of the Postmark records, and you keep exactly one _dmarc TXT for the whole domain no matter how many senders you use. Publish it at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only, so it won't affect delivery while you confirm Postmark mail passes. Watch the aggregate (rua) reports for a week or two: with DKIM verified you'll see Postmark listed as DKIM-aligned and passing, and once the pm-bounces custom Return-Path is in place SPF will show aligned too. Only after Postmark (and every other legitimate sender) is passing aligned should you tighten to p=quarantine and eventually p=reject. Note the interaction Postmark itself flags: if your domain is at p=quarantine/reject and you skip the custom Return-Path, SPF won't align — you'd be relying on DKIM alignment alone, which works but leaves you no SPF fallback, so add the pm-bounces CNAME.
Check it actually worked
Don't trust the green "Verified" badges alone — confirm it on a real message. Send yourself a test from an address on your domain through Postmark, open it in Gmail, and choose ⋮ → Show original: you want SPF: PASS and DKIM: PASS both showing yourdomain.com (not mtasv.net), plus DMARC: PASS. Check the Return-Path / mailed-by line — it should read pm-bounces.yourdomain.com, which is the proof your custom Return-Path is doing its job. Prefer a report card? Run the domain through Qualisend's domain health check to confirm the DKIM TXT and pm-bounces CNAME resolve, use the SPF/DKIM/DMARC checker for a quick record read, and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — Postmark should show up as an aligned, passing source.
Common gotchas
- Breaks auth
Don't add include:spf.mtasv.net to your root SPF. Postmark deliberately stopped asking for it — on your apex it does nothing for alignment because your root domain isn't the Return-Path Postmark uses. Add the pm-bounces custom Return-Path CNAME instead.
- Coverage
The include host is spf.mtasv.net, not postmarkapp.com. MTASV is Postmark's mail-transfer infrastructure domain; the Return-Path target (pm.mtasv.net) and its bounce MX live there too.
- DNS setup
The pm-bounces subdomain must be CNAME-only. DNS doesn't allow a CNAME to coexist with any other record type on the same name, so don't also put a TXT or A record on pm-bounces.yourdomain.com or it will fail to verify.
- DNS setup
2048-bit DKIM values are long. Some DNS panels cap a TXT string at 255 characters and require you to split the key into multiple quoted strings — split it, don't drop characters, and don't introduce stray spaces inside the p= value.
- DNS setup
On Cloudflare, set the pm-bounces CNAME to DNS only (grey cloud). An orange-cloud proxied record won't resolve to pm.mtasv.net and Return-Path verification fails.
- DNS setup
Host-field doubling: many registrars auto-append your domain, so entering 20260727pm._domainkey.yourdomain.com becomes …yourdomain.com.yourdomain.com. Enter just the label (the selector, or pm-bounces) if the panel adds the domain for you.
- Coverage
A single confirmed Sender Signature is not domain authentication — it verifies one From address but doesn't give you DKIM/SPF alignment across the domain. Verify the whole domain (DKIM + Return-Path) under the Domains tab.
- Breaks auth
Keep exactly one SPF TXT and one _dmarc TXT on your root. If you send from other providers too, merge their mechanisms into a single v=spf1 record — two SPF records is itself a PermError.
Build your SPF record
Postmark doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listPostmark SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.