Choose the Postmark route and identities
This guide covers outbound messages actually submitted to Postmark, not a website merely using Postmark for inbound processing. Record the application, Postmark server and message stream, the intended From domain, and the DNS administrator. A receipt sent by a different application must be tested separately even when its branding looks identical. Before changing DNS, save the existing records and a baseline message from the exact workflow.
Postmark's domain-verification workflow supplies a DKIM TXT record and custom Return-Path CNAME. A verified domain permits sending from addresses throughout that domain, so domain verification should be owned by the team authorized to represent it. Use the values shown for your domain, not values from a different tenant. Postmark domain verification.
Enable signing before changing policy
Open Sender Signatures, choose the domain and enter DNS Settings. Copy the DKIM hostname and value to a TXT record at the authoritative DNS provider. Check whether the DNS editor appends the zone name; a duplicated suffix will put the key at the wrong location. Return to Postmark and verify the record. Postmark documents automatic checks within 48 hours and a manual Verify control. Signing begins after verification. DKIM setup.
Do not treat the green status as the final acceptance test. It establishes that the provider found a record, not that your production application used the intended From address or that a later gateway preserved the signature. Schedule a controlled send after verification and preserve the receiver's original message, including all DKIM signatures.
Add the supported Return-Path separately
Use the Return-Path hostname displayed in the same domain settings and its CNAME target, documented as pm.mtasv.net. Reserve an unused hostname for this purpose. Do not place an SPF TXT record alongside a CNAME at the same owner name, and do not replace your apex records with the bounce CNAME. Postmark documentation shows differing default hostname spellings, so the live account value takes precedence over a copied example. Domain verification.
Postmark does not require its include in the customer's apex SPF record. The SPF check follows the actual envelope domain. Adding an apex include cannot convert a provider-owned Return-Path into a customer-owned one. The documented custom Return-Path is a subdomain; Postmark advises relaxed SPF alignment for this route. A strict SPF requirement is not fixed by adding more includes. Preserve the domain's approved policy and use a verified aligned DKIM path where appropriate. Postmark SPF guidance.
Prove the application result
The following is a synthetic acceptance design, not a captured delivery. Replace every example with the observed value and keep the test's timestamp and message ID.
- Evidence: Visible From; Illustrative value: receipts@example.com; Acceptance question: Is this the approved application identity?
- Evidence: Envelope domain; Illustrative value: pm-bounces.example.com; Acceptance question: Did the custom Return-Path activate on this message?
- Evidence: DKIM signing domain; Illustrative value: example.com; Acceptance question: Did the trusted receiver validate this signature?
- Evidence: DMARC; Illustrative value: pass; Acceptance question: Which aligned passing method produced this result?
- r a From domain of example.com and a bounce subdomain beneath it, relaxed SPF alignment can work while strict SPF alignment does not. An exact-domain passing DKIM signature can still satisfy DMARC. Evaluate the observed signature, not a promise that every message is signed. DMARC alignment.
Test a real receipt and a password-reset event through their respective application paths. Compare their streams and sender configuration. If one passes and the other fails, investigate the divergent route before altering shared DNS. Do not resend genuine financial receipts to customers as a test.
Diagnose and recover
If DKIM is absent, confirm the application's From domain matches the verified domain and that signing is active. If the signature exists but fails, preserve the receiver's reason and inspect the exact selector lookup and any content-modifying relay. If SPF passes but is unaligned, inspect Return-Path activation rather than adding apex permissions. If DNS verification fails, compare authoritative answers, complete hostname and record type with the account's values.
Pause only the affected application stream if acceptance fails. Restore the saved record or sender setting through the change owner, then retest a controlled event. Do not remove an old selector while queued mail may still need it. Retire unused bounce delegation and signing records only after confirming no other Postmark application shares them. This manuscript is based on documentation; no tenant, DNS change or live delivery was tested.
Compare strict and relaxed outcomes explicitly
For written case PM-01, assume From receipts@example.com, MAIL FROM bounce@pm-bounces.example.com and a trusted SPF pass for pm-bounces.example.com. Under ordinary same-organizational-domain relaxed alignment, that SPF path aligns; with aspf=s it does not exactly match example.com. Separately assume a passing signature d=example.com, s=demo1: that path aligns exactly and can satisfy DMARC even in the strict-SPF case. If DKIM becomes unknown rather than passing, do not retain a pass based on the earlier premise. These are stipulated inputs, not a captured Postmark delivery or advice to weaken a policy.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.