Lookproof Browse tools

DMARC, SPF and DKIM for Postmark

Updated 2026-11-06

Postmark is an email API for transactional mail. You add your domain under Sender Signatures, publish a DKIM key and, optionally, a custom Return-Path at your DNS host. You publish DMARC yourself. This guide follows Postmark's own support articles. For background on each standard, see SPF explained, DKIM explained and DMARC explained.

What Postmark sends from

The visible From address is your own domain, for example [email protected].

The envelope sender (Return-Path, also called MAIL FROM or bounce address) is not your domain by default. As of November 2026, Postmark documents the default as Return-Path: <[email protected]>.

Postmark uses that address to collect bounces. Receivers run SPF against this domain, so SPF passes for Postmark's servers, but on pm.mtasv.net, not on example.com.

With a custom Return-Path the envelope domain moves to a subdomain of yours. As of November 2026 the default hostname is pm-bounces, so the header becomes Return-Path: <[email protected]>. Postmark's API documentation says the custom Return-Path must be a subdomain of your From domain.

DKIM: once your DKIM record is verified, Postmark signs mail for that domain with the key you published under example.com. Postmark does not document which signature, if any, unverified domains get, so do not rely on one.

SPF

Postmark does not ask for an SPF include on your own domain. Its support article says: "It is no longer required to include Postmark in your own custom SPF record." The reason is that SPF is evaluated on the Return-Path domain, and that domain is either Postmark's pm.mtasv.net or your custom Return-Path, which points to it.

The custom Return-Path is a CNAME, as of November 2026:

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

Postmark explains that this CNAME "already includes a TXT record for SPF". Through the CNAME, pm-bounces.example.com inherits the SPF and MX records of pm.mtasv.net. So SPF for Postmark mail lives on the bounce subdomain, not on example.com. Postmark's general SPF guide says that with a custom Return-Path you would have to set up SPF for your domain as well; its Postmark-specific support article is more precise: the CNAME carries the SPF record, so you add nothing else. A name with a CNAME cannot also hold a TXT record, so do not publish your own SPF record at pm-bounces.example.com.

Your root domain still needs SPF for services that use example.com itself in the Return-Path, such as your mailbox provider. A typical record looks like this, where include:_spf.example.net is a placeholder for "another service":

example.com TXT v=spf1 include:_spf.example.net ~all

This record uses 1 DNS lookup in the record itself. The include adds its own nested lookups, which depend on that service. The limit is 10 lookups for the whole tree (RFC 7208); the SPF lookup counter counts it. See also too many SPF lookups.

Postmark does document an optional root record, v=spf1 a mx include:spf.mtasv.net ~all, but it states that adding include:spf.mtasv.net to your root domain "will do nothing for you" because the root is not your Return-Path. It is not a replacement for the CNAME. When we counted it with real DNS on 7 November 2026, include:spf.mtasv.net cost 1 lookup in total, because that record held only IP ranges; Postmark can change it, so check your own tree with the SPF lookup counter. If you add it anyway, merge it into your existing record: one name may only have one SPF record (multiple SPF records).

DKIM

Postmark DKIM is a TXT record, not a CNAME. As of November 2026 the documented steps are:

  • In Postmark, open Sender Signatures.
  • Under your domain, click DNS Settings (or Add a DKIM DNS record).
  • Copy the Hostname and Value shown in the DKIM section.
  • At your DNS host, create a TXT record with that Hostname and Value.
  • Wait for verification. Postmark checks automatically and says the key shows as verified within 48 hours; the Verify button starts a manual check.

The selector is generated per domain. Postmark's examples vary in form, but all end in pm: jan2013pm and 20131031155228pm in the API docs, 20130425164621.pm in a troubleshooting article and 2023060112345pm in the DKIM setup article. The documented shape of the record is:

20131031155228pm._domainkey.example.com TXT k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCFn...

The value above is Postmark's own truncated placeholder. Use the exact Hostname and Value from your DNS Settings page. If your DNS host appends the domain, enter only the part before example.com, or you get ...example.com.example.com.

Key length: as of November 2026 Postmark says it "uses 1024-bit DKIM keys to sign emails". There is no documented option for another length. 1024 bits is the minimum the DKIM standard calls for, as Postmark's DKIM guide notes; see weak DKIM key for what our check reports.

Rotation: as of November 2026 Postmark suggests a new key at least once every 3 months. Click Generate New under the existing key, publish the new TXT record, then Verify. Postmark then revokes the old key. Keeping the old TXT record for a few days is optional; it lets mail in transit verify.

DMARC alignment

DMARC passes when SPF or DKIM passes and that result aligns with the From domain. SPF alignment compares the RFC5321.MailFrom (Return-Path) domain with the From domain. DKIM alignment compares the signature's d= domain with the From domain. Relaxed alignment means both are in the same organisational domain. Strict alignment (aspf=s, adkim=s) means the domains must be identical.

Without a custom Return-Path, SPF passes on pm.mtasv.net, which does not align with example.com. Postmark says so directly: ESPs "will fail the SPF DMARC alignment unless a custom Return-Path is used". Because the DKIM key is published under your domain, the signature's d= is your domain (our reading; Postmark does not show the d= value), so DKIM aligns. That alone is enough for DMARC.

With a custom Return-Path at pm-bounces.example.com, SPF also aligns, but only under relaxed alignment. Postmark states that the Return-Path "will always have to be on a subdomain" and so cannot meet aspf=s. Keep aspf=r (the default).

Forwarding often breaks SPF but keeps the DKIM signature intact, so Postmark mail that is forwarded can still pass DMARC through DKIM.

Step by step to p=reject

  1. Check SPF on the root domain. Keep or publish one SPF record on example.com for the services that use your domain as Return-Path, such as your mailbox provider. Postmark itself needs no include there, and you should stay under 10 DNS lookups in total.
  2. Publish the Postmark DKIM key. In Postmark open Sender Signatures (click Add Domain if it is not there yet), then DNS Settings, copy the DKIM Hostname and Value, publish them as a TXT record, and wait until the key shows as verified (or click Verify to check manually).
  3. Add the custom Return-Path. Create the CNAME pm-bounces.example.com pointing to pm.mtasv.net, enter pm-bounces in the Return-Path section of DNS Settings, and verify it, so that SPF aligns under relaxed alignment as well as DKIM.
  4. Publish DMARC with p=none and a report address. Add a TXT record at _dmarc.example.com with v=DMARC1; p=none; rua=mailto:[email protected], which asks receivers for aggregate reports without changing delivery.
  5. Read the reports and fix other senders. Watch the reports for a few weeks or more (Postmark's DMARC guide says a few months at least), confirm that Postmark mail passes DKIM and aligned SPF, and give every other legitimate sender aligned DKIM or SPF before you tighten the policy.
  6. Move to p=quarantine. Change the policy to p=quarantine and keep reading reports, because failing mail now goes to spam and any sender you missed will show up quickly.
  7. Move to p=reject. When the reports show only legitimate mail passing and nothing legitimate failing, change the policy to p=reject.

The record for step 4:

_dmarc.example.com TXT v=DMARC1; p=none; rua=mailto:[email protected]

That record triggers our DMARC policy none note on purpose; it is the monitoring stage. The final record:

_dmarc.example.com TXT v=DMARC1; p=reject; rua=mailto:[email protected]

Postmark's DMARC guide suggests pct steps on the way up. Some receivers support pct (RFC 7489) or t=y (RFC 9989), but RFC 7489 says unknown tags are ignored, so a receiver may apply p=reject; t=y as a full reject. Do not treat either tag as a safety net (partial pct).

Common mistakes

  • Adding include:spf.mtasv.net instead of the CNAME. Postmark says the include on your root domain "will do nothing for you" for its mail. The custom Return-Path CNAME is what aligns SPF.
  • Using aspf=s. The Postmark Return-Path is always a subdomain, so strict SPF alignment cannot pass.
  • Proxying the Return-Path CNAME. Postmark says Cloudflare's orange cloud can get in the way of verification. Set the CNAME to DNS only.
  • Domain added twice. Some DNS hosts append the domain, producing pm.mtasv.net.example.com or ...pm._domainkey.example.com.example.com. Postmark suggests a trailing dot on the CNAME value, or entering only the host part.
  • A second SPF record. One name may have only one SPF record (RFC 7208). Merge includes into the existing record.
  • Forgetting subdomains. Each sending subdomain needs its own DKIM and Return-Path records in Postmark.
  • Deleting the old DKIM key at once. After rotation, keep the old TXT record for a few days; Postmark calls this optional.
  • No report address. Without rua you cannot see what fails (DMARC without rua).

How to check it

Run the email security check on example.com to read SPF, DKIM and DMARC together. Use the SPF lookup counter on your root domain to count the full lookup tree. Postmark generates selectors per domain, and in all its examples they end in pm, so they are hard to guess; copy yours from DNS Settings and enter it in the DKIM selector finder, for example 20131031155228pm. Build your policy with the DMARC record generator. To confirm the custom Return-Path, look for a CNAME at pm-bounces.example.com that points to pm.mtasv.net.

Sources

Frequently asked questions

Do I need to add Postmark to my SPF record?

No. Postmark says it is no longer required to include Postmark in your own SPF record. SPF is checked against the Return-Path domain, and Postmark's default Return-Path is on its own domain pm.mtasv.net. With a custom Return-Path, the CNAME to pm.mtasv.net brings the SPF record with it.

What does the Postmark DKIM record look like?

As of November 2026 it is a TXT record. Postmark shows the Hostname and Value under Sender Signatures, DNS Settings. In all of Postmark's examples the Hostname is a selector ending in pm, such as jan2013pm and 20131031155228pm, followed by ._domainkey, and the Value starts with k=rsa; p= or v=DKIM1; k=rsa; p=. Copy both exactly as shown.

Can I use aspf=s with Postmark?

No. Postmark says the custom Return-Path is always on a subdomain of your domain, so it cannot meet strict SPF alignment. Use relaxed SPF alignment (aspf=r, the default) if you want SPF to count towards DMARC.

Do subdomains need their own setup?

Yes. Postmark says each subdomain you send from must be added individually and gets its own DKIM and Return-Path records.