A password-reset email that fails authentication can look like a phishing attempt, even when your app sent it. For a SaaS business, that can disrupt sign-ins, receipts, alerts, and other messages customers expect immediately.
A correct Postmark DMARC setup ties your visible sender address to the authentication Postmark publishes in DNS. It also gives receiving mail systems clear instructions when someone tries to impersonate your domain.
Postmark DMARC Setup Begins With the Visible From Domain
DMARC is a DNS policy for the domain in the visible From: address. It checks whether SPF or DKIM passes and aligns with that visible domain. Postmark can authenticate messages it sends, but the DMARC record belongs in DNS for your domain, not in your Postmark account.
For example, if your app sends From: receipts@example.com, DMARC evaluates example.com. The Return-Path, sometimes called the envelope sender, can be different. However, SPF only supports DMARC when that domain aligns with example.com. DKIM supports DMARC when its signing domain aligns too.
Postmark’s DMARC guide explains the relationship between sender authentication and a domain’s published DMARC policy. The important distinction is simple: Postmark sends the email, while your DNS publishes the identity rules.
A DMARC record does not authorize Postmark by itself. It tells receivers how to evaluate the SPF and DKIM authentication attached to each message.
Under relaxed alignment, the default DMARC mode, related subdomains can align. A Return-Path of pm-bounces.example.com can align with From: alerts@example.com. Under strict alignment, the domains must match exactly. For most SaaS teams, relaxed alignment is the practical starting point.
Prepare Your Sending Domain and Sender Inventory
Choose the domain that customers already recognize in transactional mail. A common pattern is notifications@example.com, billing@example.com, or support@example.com. Keep it consistent across your product, help center, and billing flows.
Before you begin a Postmark DMARC setup, list every platform that sends mail using this domain. Postmark may cover product messages, while Google Workspace handles employee mail. Your support desk, CRM, billing platform, or marketing tool may also use the same visible From domain.
DMARC enforcement can affect all of them. If one legitimate sender is missing DKIM or SPF alignment, its messages may fail after you tighten the policy.
Create a basic inventory with the tool name, visible From domain, Return-Path domain, DKIM signing domain, and owner. This document becomes useful whenever someone adds a new automation or changes a vendor.
Your related guides on SPF records, DKIM keys, and DNS records should sit alongside this inventory. A separate guide on transactional-email domain strategy can also help when product mail needs a dedicated subdomain.
If your company uses news@example.com for marketing and alerts@example.com for application mail, you can still use one organizational domain policy. Yet separating operational mail onto a stable sending subdomain often makes ownership and troubleshooting easier.
Publish Postmark Authentication Records First
Log in to Postmark and open Sender Signatures. Add the sending domain, or select the domain you already use. Postmark will display the DNS records required for that domain. Copy them from the current Postmark screen, character for character.
A typical setup has three moving parts:
- Publish the DKIM record Postmark provides. DKIM adds a cryptographic signature to each message, and its
d=domain must align with your visible From domain for DMARC. - Add Postmark’s custom Return-Path record if it is available for your sending domain. An illustrative record might look like
pm-bounces.example.com CNAME pm.mtasv.net, but use the exact hostname and destination shown in your account. - Verify the records inside Postmark after DNS propagation. Postmark should confirm the domain’s DKIM and Return-Path status before you rely on them for DMARC alignment.
- If Postmark directs you to change SPF, merge its required mechanism into your existing SPF record. A domain must publish one SPF TXT record, not separate records for Google Workspace, Postmark, and other services.
Record formats can differ by configuration. Postmark may show a TXT record or a CNAME-based instruction for a particular authentication setting. Don’t copy a record from another company’s guide, even if the hostname looks familiar.
For DNS hosted at GoDaddy, Postmark also has a GoDaddy authentication walkthrough for DKIM, custom Return-Path, and DMARC. If you use Cloudflare, keep authentication CNAME records DNS-only rather than proxied.
Postmark’s DMARC support documentation notes that SPF-based DMARC authentication requires the Return-Path domain to align with the visible From domain. DKIM can also carry DMARC alignment on its own, but configuring both gives you a more complete setup.
Add a DMARC Record and Start in Monitor Mode
After Postmark verifies its authentication records, add a TXT record at _dmarc for the visible From domain. For example.com, the DNS host is usually _dmarc.example.com, although many DNS dashboards only require _dmarc in the host field.
Use this example as a structure only:
v=DMARC1; p=none; pct=100; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r
Replace dmarc-reports@example.com with a real mailbox or reporting service that your team monitors. Do not treat this sample as a finished production record. Your policy may need a different reporting address, subdomain policy, or alignment mode.
The p=none policy asks recipients to send aggregate reports without requesting quarantine or rejection based on DMARC. It gives you visibility into legitimate and unauthorized sources before enforcement begins.
Postmark recommends starting with p=none, and that is the right move for small teams too. Review reports over enough time to cover weekly billing, support, onboarding, and other scheduled workflows. Then confirm that every authorized platform passes DMARC with alignment.
Once the reports show clean results, move carefully to p=quarantine. Later, you can consider p=reject if the inventory remains accurate and authorized mail continues to align. These policies increase protection against spoofing, but they do not guarantee inbox placement.
Postmark’s free DMARC monitoring can send weekly visibility reports. A dedicated DMARC reporting tool may also make XML aggregate reports easier to read when several vendors send on your behalf.
Check Real Message Headers Before Tightening Policy
A green verification status in Postmark is useful, but a delivered message header is the final check. Send a real transactional message to a mailbox you control. In Gmail, open the message menu and choose “Show original.” Other providers offer a raw-source or message-details view.
Look for these fields and outcomes:
| Header or result | What you want to see | Why it matters |
|---|---|---|
Return-Path | A Postmark-managed custom bounce domain related to your domain | This gives SPF a domain that can align. |
spf=pass | smtp.mailfrom matches or shares the organizational domain of header.from | SPF must both pass and align for DMARC. |
dkim=pass | header.d=example.com or an aligned subdomain | DKIM must pass with an aligned signing domain. |
dmarc=pass | header.from=example.com | This confirms the receiver accepted aligned SPF or DKIM. |
A message can pass SPF but still fail DMARC. For instance, SPF may pass for a Postmark infrastructure domain that does not align with example.com. The same issue can occur when DKIM passes with an unrelated d= domain.
Check headers after every DNS or sender-domain change. Also test messages sent through API, SMTP, automations, and any separate Postmark server you use. Different streams may use different sender signatures.
Final Checks Before Moving Beyond p=none
- Confirm the visible From domain matches the domain you added and verified in Postmark.
- Copy Postmark’s current DKIM and Return-Path values exactly, rather than using generic examples.
- Keep one valid SPF record for each sending domain and avoid unnecessary DNS lookups.
- Publish DMARC at
_dmarcfor the domain customers see in the From address. - Route aggregate reports to a mailbox or service someone reviews regularly.
- Verify
spf=pass,dkim=pass, anddmarc=passin a real delivered message. - Review every authorized sender before moving to quarantine or reject policies.
- Update your sender inventory when a new automation, support tool, or email provider goes live.
A Safer Foundation for Transactional Email
A solid Postmark DMARC setup starts with domain alignment, not with a restrictive DMARC policy. Publish the Postmark records for the domain in your visible From address, inspect real headers, and use p=none to learn what is already sending.
Once your reports show that authorized mail authenticates correctly, stricter policy changes become an informed operational decision. DMARC works best when DNS, sending tools, and ownership stay in sync.
