Postmark SPF, DKIM and DMARC setup, step by step

For ordinary Postmark sending, configure the DKIM TXT record generated in Sender Signatures → DNS Settings, then verify a custom Return-Path CNAME if you want SPF alignment. Postmark already handles SPF on its default bounce domain, so adding a Postmark include to your root SPF record is normally unnecessary. Postmark's SPF explanation

This guide applies to messages sent through Postmark's API or SMTP service using your domain. It does not configure inbound processing, your employees' mailbox provider, or another service sending with the same From address. “PostmarkApp” and “PostMark” in older material refer to the Postmark service discussed here.

Retain separate mailbox-provider authentication. For the distinction between a valid signature and one aligned to your brand, see EmailAuth's raw DKIM versus aligned DKIM guide.

Decide what you are verifying

Start with a real workflow, such as an application receipt or a password-reset notification. Record the Postmark account, server, message stream, visible From domain, and DNS administrator. Use authorized account access and confirm who may represent the whole domain: domain verification permits sending from addresses throughout that domain, not just one mailbox. Save existing DNS, provider settings and a restricted baseline message before the change, and name the recovery owner. Keep credentials out of the worksheet; record which configuration owns them instead.

Confirm that the application really sends through Postmark. A plugin displaying your domain or a test message from a different server is not enough evidence. Identify the exact action that will produce the acceptance-test email and an external mailbox you control where you can read its original source.

Keep these three outcomes separate:

• DNS publication: the intended records resolve publicly.
• Provider verification: Postmark accepts the records for the selected domain.
• Message authentication: a receiver reports the expected authentication results for the application's email.

A successful first step does not substitute for the next two. This distinction also makes troubleshooting faster: you can establish which boundary failed without randomly editing every record.

Postmark DNS records and their roles

The CNAME hostname must agree with the alias configured in Postmark. Do not guess it from a screenshot. Postmark's public pages use slightly different example spellings, so copy the live account's values and check the complete resulting DNS name. Postmark domain verification

Step 1: publish and verify the DKIM TXT record

1. Sign in to the correct Postmark account and open Sender Signatures.
2. Add the sending domain if needed, then select its DNS Settings.
3. Copy the DKIM hostname and full TXT value. Keep a dated copy with your change record.
4. Add the TXT record in the authoritative DNS zone and save it.
5. Return to Postmark and select Verify. After verification, messages sent using that domain can be signed with its DKIM identity. Postmark DKIM setup

Use the account's selector, not a date-like selector copied from another guide. A DNS panel may want the relative hostname rather than the full domain-qualified name. Confirm the saved owner name instead of assuming the panel interpreted your input correctly.

For a hypothetical full owner SELECTOR._domainkey.news.example.com, use relative SELECTOR._domainkey.news in the parent example.com zone, SELECTOR._domainkey in a separately delegated news.example.com zone, or SELECTOR in a delegated _domainkey.news.example.com namespace. Preserve existing NS delegation and publish at the actual authority. Do not replace another sender's selector.

If a long TXT value cannot be saved, consult your DNS host's supported method for storing a long TXT record. Multiple component strings must remain one logical TXT record and concatenate without inserted spaces. Preserve the complete tagged value. Do not truncate the public key or create several independent key records as a workaround. DKIM TXT concatenation Postmark specifically flags hostname suffix errors, text-entry problems, and TXT-length handling in its setup guidance. Postmark DKIM DNS guidance

The current DKIM support page states that Postmark uses 1024-bit keys. Use the actual account-issued record rather than manufacturing a 2048-bit replacement that Postmark cannot sign with. If your organization requires a different key size, resolve support and policy compatibility before rollout. Never publish private signing material or rotate an active key casually. Postmark signing-key documentation

Step 2: add a custom Return-Path

The Return-Path is the bounce identity. Postmark's documented default uses pm.mtasv.net. A custom Return-Path gives this identity a subdomain under your own domain while continuing to route bounce handling to Postmark.

In the domain's DNS Settings, review the Return-Path section. Publish a CNAME at the chosen hostname pointing to pm.mtasv.net, enter or confirm the matching alias in Postmark, and verify it. Choose an unused hostname rather than replacing a record used by another service. Postmark custom Return-Path instructions

For your implementation worksheet, use these placeholders:

DKIM TXT owner: COPY_EXACT_HOST_FROM_POSTMARK
DKIM TXT value: COPY_COMPLETE_PUBLIC_KEY_FROM_POSTMARK
Return-Path CNAME owner: COPY_SELECTED_HOST_FROM_POSTMARK
Return-Path CNAME target: pm.mtasv.net

The capitalized strings are instructions to you, not DNS values. A CNAME delegation is not an additional SPF TXT record at the same owner. Keep the delegation intact after verification; it remains part of the configuration.

For an illustrative bounce owner pm-bounces.news.example.com, use pm-bounces.news in the parent example.com zone or pm-bounces in an authoritative delegated news.example.com zone. The account's selected alias controls, not this example. Keep the dedicated bounce CNAME away from the apex and existing nameservers, MX or website owners. At its exact owner, do not add TXT, A, AAAA, MX or another CNAME. Coordinate any collision instead of deleting active records. DNS alias rule

For the required literal alias on Cloudflare, use DNS only and turn an applicable per-record Flatten control off. Ensure applicable whole-zone flatten-all does not suppress the CNAME, coordinating shared-setting changes with the owner before acting. If mandatory apex or same-zone behavior prevents the literal answer, stop and agree a supported configuration; do not invent an override or remove shared delegation. Cloudflare proxy status · Exact flattening controls

SPF pass, SPF alignment, and strict mode

SPF evaluates the actual SMTP MAIL FROM identity, or the applicable HELO identity for a null reverse path and relevant HELO checks, not the visible From by itself. SPF identities Postmark's default SPF handling is not a guarantee that every forwarded or modified route will pass; inspect actual receiver results.

An SPF pass on Postmark's own bounce domain does not establish alignment with your visible From domain. The custom Return-Path is the relevant change for ordinary Postmark SPF alignment; adding an include at an unrelated DNS name does not fix an identity mismatch.

Postmark explicitly says its custom Return-Path uses a subdomain and requires relaxed SPF alignment, aspf=r, for SPF-based DMARC success in this setup. Do not describe it as satisfying aspf=s. If your organization requires strict SPF alignment, review that requirement with the mail owner rather than promising a DNS-only fix. Postmark SPF and strict-alignment guidance

DMARC can pass through a passing, aligned DKIM signature even when SPF is unaligned. Strict alignment means identical domains; relaxed alignment uses the Organizational Domain. Check the actual policy and identities on the message. DMARC specification, RFC 9989

For a hypothetical From receipts@example.com, a passing envelope at pm-bounces.example.com aligns in relaxed mode but not strict mode. A passing intended Postmark DKIM signature with d=news.example.com also aligns only in relaxed mode; a passing d=example.com aligns in both. These are stipulated identities, not captured delivery results. Alignment rules

Do not weaken an existing enforcement policy merely to make a setup screen look successful. Resolve this route, then review any wider policy change separately with all legitimate senders in scope.

Preserve DMARC policy and approved report destinations

Read direct and applicable inherited policy for the intended From domain. Preserve enforcement, subdomain policy, alignment modes and authorized report recipients; do not duplicate DMARC or overwrite a working policy with a monitoring example.

Only when no direct or applicable inherited policy exists, and the owner approves an appropriate monitoring plan, a first-policy example is:

Type: TXT
Full owner: _dmarc.example.com
Value: v=DMARC1; p=none

Use relative _dmarc in the example.com zone. For _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in an authoritative delegated news.example.com zone. These owner examples do not authorize a parent-policy override. p=none alone requests no reports; add rua only for an approved destination and monitoring process. Do not use obsolete pct for a new rollout.

When a report destination is in a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization supplied by the report-destination operator. A destination within the same Organizational Domain is excepted; a different hostname alone is not external. Report authorization This DNS requirement does not replace the owner's privacy decision on metadata sharing, recipients, access and retention. Do not copy a tutorial report mailbox or add message-level failure reporting without separate privacy approval.

Exception: Sign in with Apple email relay

If your application emails Apple's private relay addresses, ordinary Postmark setup is not the entire job. Postmark's June 2026 guide calls for DKIM, a custom Return-Path, an SPF record authorizing spf.mtasv.net, and registration of sending origins in the Apple Developer account. Follow that specific workflow if it applies. Postmark's Apple Private Email Relay guide

For that documented exception, the mechanism is include:spf.mtasv.net with no space after the colon. Review the exact registered sending domain with the application owner; do not place an SPF TXT alongside the custom bounce CNAME. Do not publish a second SPF policy where one already exists. Review the complete existing policy, preserve legitimate senders and the approved qualifier, and merge the mechanism before the terminal all where applicable. Any all mechanism makes redirect ignored regardless of its qualifier; preserve a redirect-based design instead of blindly appending all. Qualifiers specify results rather than deterministic delivery/rejection. SPF all processing Count the ten evaluated DNS-dependent terms, including nested includes and redirects, not merely ten visible includes. SPF processing limits Likewise, do not delete an existing Postmark include until you know whether this relay or another documented dependency needs it. This exception is why “Postmark never needs an SPF record” is too broad.

Have the authorized Apple developer-account owner register the actual domains/subdomains or communication addresses under Certificates, Identifiers & Profiles → Services → Sign in with Apple for Email Communication → Configure. Add the intended Email Sources, review and register them, then check their SPF status. Apple's SPF branch requires an exactly registered envelope domain, while its DKIM branch requires a verified signature covering From with d= exactly matching the registered From domain. Register every source actually used. This relay-specific exact-match rule is separate from relaxed DMARC; a root SPF edit is not a substitute for source registration. Apple relay configuration

Verify with public DNS and a real email

First query the exact record names from your account, using an authoritative nameserver and a public recursive resolver. Replace the placeholders before running:

dig TXT DKIM_FULL_HOSTNAME +short
dig CNAME RETURN_PATH_FULL_HOSTNAME +short

Record the answers, query time, and resolver. Empty short output is not enough: inspect full response status to distinguish missing data, timeout, SERVFAIL and cached results. Compare authoritative correctness before waiting for positive or negative cache expiry. The DKIM result must contain the complete expected public key. The Return-Path answer must match the configured Postmark target. Check Postmark's verification status again after public DNS is correct; its domain-verification guidance allows up to 48 hours for verification. Postmark verification process

Next trigger a new email through the actual application, server, and stream. In its original source, capture the visible From domain, Return-Path, DKIM d= and s=, and the trusted recipient system's authentication results. Use the signature's selector and signing domain to check the relevant key, rather than looking up a generic pm selector. DKIM specification

For branded DKIM acceptance, require the intended Postmark signature to pass and align with the intended visible From under current policy, plus trusted dmarc=pass for that From. A DMARC pass through SPF alone does not prove DKIM works. A rewritten provider-owned From is not successful authentication of the intended brand. Document the actual identities, not simply “SPF looks good.” If the custom Return-Path was part of the change, verify that it appears on the new message. Repeat for materially different From domains or application routes. One test cannot certify every server or stream.

Use results generated inside the actual receiver's known processing boundary. Establish from its documentation or administrator how externally supplied Authentication-Results are removed or distinguished. Neither header position nor matching authserv-id alone establishes trust. Ignore attacker-supplied fields; if necessary, use a controlled receiver with a documented boundary or its trusted trace. Authentication-Results trust boundary

Troubleshoot the symptom you actually see

DKIM remains unverified: Compare the full published hostname and TXT value with the account. Check for a doubled domain suffix, truncated key, or editing the registrar's unused DNS zone instead of the authoritative one.

Return-Path remains on Postmark's domain: Confirm the alias and CNAME match, the custom Return-Path has verified, and the message was sent after the change through the intended account.

SPF passes but alignment fails: Check whether the message still uses the default bounce domain or whether the DMARC policy requires strict SPF alignment. Adding a root include does not repair either mismatch.

SPF fails even when DKIM supplies DMARC pass: Diagnose fail/softfail against the connecting IP and evaluated envelope or HELO policy. For permerror, inspect duplicate policies, syntax and recursive processing limits. For temperror, investigate DNS availability and retry after recovery. Do not broaden an unrelated root policy or ignore errors because another mechanism passed.

Everything authenticates, but the message is missing: Check Postmark's delivery events, the recipient address, suppression state, and recipient filtering. Authentication alone is not a guarantee of inbox delivery.

Only Apple relay recipients bounce: Review the separate Apple registration requirements before treating all failures as ordinary SPF or DKIM problems.

Keep an acceptance row per application/server/stream with expected and observed From, envelope, SPF result, all DKIM d=/s=/results, alignment, DMARC, timestamp, DNS capture and restricted original-message reference. Test harmless receipt and password-reset events separately; do not resend real financial receipts to customers as a test.

If acceptance fails, pause only the affected stream and restore approved prior records/settings through the change owner, then retest. Retain old selectors while queued mail may depend on them, and retire bounce aliases only after checking shared application dependencies. Do not change MX, parent nameservers, DNSSEC or account security to match a tutorial. Human mail-security and exact-route acceptance remain required before production rollout.