How to Set Up SPF, DKIM and DMARC for Postmark (2026)

Postmark is a transactional email delivery service used by developers and product teams to send application-triggered email at scale. If your domain sends through Postmark without SPF, DKIM, and DMARC in place, inbox providers have no cryptographic basis to trust that mail, and you leave your domain open to spoofing. By the end of this guide you will have all three records published, aligned, and verified passing.

Before you begin

• Write access to the DNS zone for the domain you are sending from (via your registrar or DNS host — Cloudflare, Route 53, GoDaddy, etc.).
• Admin access to your Postmark account with permission to manage sender signatures or server domains.
• The ability to send a test email from the domain and view its raw headers (a Gmail or Yahoo address works well for this).
• An existing SPF record on that domain, if one is already published — you will be editing it rather than replacing it blindly.

Step 1: Identify what's sending from Postmark

Postmark routes outbound mail through its own sending infrastructure. All mail sent via Postmark's API or SMTP should originate from Postmark's IP ranges, not your own mail server. This matters for SPF because your SPF record must explicitly authorize Postmark's infrastructure using the include: mechanism Postmark publishes. If you are also sending from Google Workspace, Microsoft 365, or another ESP from the same domain, each of those sources needs its own include: in the same SPF record. Check whether any Postmark-specific subdomains (for example, a dedicated sending domain or a custom Return-Path domain you configured in Postmark) are in scope — those subdomains need their own SPF records too.

Step 2: Add the SPF include

Postmark requires you to add their authorized sending domain as an include: mechanism in your SPF TXT record. Based on Postmark's published documentation, the include string is include:spf.mtasv.net — verify this is still current in Postmark's support documentation before publishing your record.

If your domain already has an SPF record, add the include to it. Do not create a second TXT record with v=spf1 — only one SPF record is permitted per name.

Before (no Postmark authorization):

your-domain.com.  TXT  "v=spf1 include:_spf.google.com ~all"

After (Postmark added):

your-domain.com.  TXT  "v=spf1 include:_spf.google.com include:spf.mtasv.net ~all"

If your domain has no existing SPF record, the minimal record authorizing only Postmark looks like this:

your-domain.com.  TXT  "v=spf1 include:spf.mtasv.net ~all"

SPF lookup limit warning: The SPF specification permits a maximum of 10 DNS lookups during evaluation. Each include:, a:, mx:, and redirect= mechanism that triggers a DNS query counts toward this limit — and includes chain into sub-includes you do not control. If you are using several ESPs from the same domain, you can breach the 10-lookup ceiling without realizing it. A breached SPF record returns PermError, which causes authentication failures. Use a tool such as MXToolbox SPF checker to count your current lookups before and after adding new includes.

Step 3: Enable DKIM in Postmark

DKIM requires you to publish a public key in DNS that receiving servers use to verify the cryptographic signature Postmark attaches to outbound messages. The general workflow is:

1. Log in to your Postmark account and navigate to the sender signature or domain authentication section. Postmark organizes this under Sender Signatures or under a server's Domains settings — check Postmark's current UI, as screen names change between product versions.
2. Locate the domain you want to authenticate. Postmark will display a DKIM public key and the selector name you need to use as the DNS record hostname.
3. Copy the full DKIM value. Postmark generates this key per sender signature or per domain; it will look like a long base64 string prefixed with v=DKIM1; k=rsa; p=....
4. Create a new TXT record in your DNS zone using the hostname and value Postmark provides.

The DNS record takes the following general form:

Record type:  TXT
Host/Name:    <selector>._domainkey.your-domain.com
Value:        v=DKIM1; k=rsa; p=<your-public-key-from-postmark>

Postmark's selector naming convention has historically followed a pattern like pm or a server-specific token (for example pm._domainkey.your-domain.com), but Postmark assigns the selector — you do not choose it yourself. Copy the exact hostname string from the Postmark dashboard rather than constructing it manually.

If the public key value is very long, some DNS providers split it across multiple quoted strings in a single TXT record. That is valid per RFC 4408 as long as both strings sit within the same record. If your DNS provider wraps the value in quotes automatically, confirm the full key is present and untruncated after saving.

After the record propagates (typically a few minutes to an hour), return to the Postmark dashboard and use any Verify or Check DNS button to confirm Postmark can see the record resolving correctly.

Step 4: Publish your DMARC record

DMARC ties SPF and DKIM together and tells receiving servers what to do with mail that fails both checks. Publish a p=none policy first so you can collect reporting data for at least 14 days before moving to enforcement. Moving directly to p=quarantine or p=reject without understanding your sending sources will cause legitimate mail to be blocked or junked.

Publish this record at _dmarc.your-domain.com:

Record type:  TXT
Host/Name:    _dmarc.your-domain.com
Value:        "v=DMARC1; p=none; rua=mailto:dmarc-rua@dmarcbusta.pro; fo=1;"

Parameter notes:

• p=none — monitor-only mode; no mail is rejected or quarantined yet.
• rua=mailto:dmarc-rua@dmarcbusta.pro — aggregate report destination. DMARC Busta parses and visualizes these reports so you can see which sources are passing or failing before you enforce.
• fo=1 — requests a forensic/failure report when either SPF or DKIM fails (not only when both fail). This gives you richer failure data during the monitoring window.

Once aggregate reports confirm that all legitimate sending sources — Postmark and any others — are showing pass in your reports, graduate the policy:

"v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-rua@dmarcbusta.pro; fo=1;"

Start at a low pct value (such as 10) to apply the policy to only a fraction of mail while you watch for unexpected failures, then ramp up to pct=100 and eventually p=reject.

Step 5: Verify it works

Before sending a test email, confirm your DMARC record actually published. Use our free DMARC Checker to look up _dmarc.your-domain.com and verify the record is live, has the correct policy (p=none, quarantine, or reject), and is configured for aggregate reporting. While you are there, run the SPF Checker against your domain to make sure the SPF lookup tree is clean — once both records check out, the live email test below will give you the final confirmation.

Send a real transactional email through Postmark to a Gmail or Yahoo address you control. Open the message and view its full raw headers.

• In Gmail: open the message, click the three-dot menu (⋮) in the top-right of the email, select Show original. The summary at the top will display SPF, DKIM, and DMARC results.
• In Yahoo Mail: open the message, click the three-dot menu, select View raw message.

You are looking for all three of these results:

Alignment is the part most setups miss: DMARC only passes when the domain in the authenticated identifier matches the domain in the visible From: header. If Postmark signs with a different domain (for example, a shared domain or a subdomain), DKIM alignment may fail even if the signature itself is valid — resolve this by using a custom sending domain in Postmark that matches your From address.

You can also use mail-tester.com or learndmarc.com to get a structured breakdown of the authentication result for a test message.

Common errors with Postmark

• DKIM alignment failure despite a valid signature. If your From: header uses @your-domain.com but Postmark signs using a Postmark-owned domain (common on shared infrastructure or before custom domain DKIM is configured), DMARC will fail the alignment check. Fix this by completing the custom DKIM domain setup in Postmark so the d= tag in the signature matches your From domain.
• SPF alignment failure on the envelope sender. Postmark may use a Return-Path under a Postmark-controlled domain (for bounce handling) rather than your own domain. SPF alignment requires the envelope-from domain to match the From header domain. If Postmark's bounce domain is different from your From domain, SPF will fail DMARC alignment — but DKIM alignment alone is sufficient for DMARC to pass, which is why getting DKIM right is the higher priority.
• Truncated DKIM public key in DNS. Some DNS providers impose a 255-character limit per string in a TXT record. If the key is longer, it must be split into multiple quoted strings within the same record. A truncated or incorrectly split key causes dkim=fail (public key: not found). Verify the full key is present using a tool like MXToolbox DKIM lookup.
• Publishing a duplicate SPF record. Adding a second v=spf1 TXT record to the same hostname instead of editing the existing one causes a PermError. Receiving servers encountering two SPF records on the same name must treat this as an error. Merge all includes into one record.
• SPF lookup count exceeded after adding Postmark. If your domain already authorizes several services (Google, Microsoft, Mailchimp, Zendesk, etc.), adding another include: may push your lookup count over 10. Use an SPF flattening or delegation tool — or DMARC Busta's SPF Auto-Repair — to stay under the limit without manually managing IP lists.

How DMARC Busta helps

The steps above are a one-time manual process, but email authentication is not a set-and-forget configuration. Sending sources change, DKIM keys rotate, SPF includes drift over the 10-lookup ceiling, and DMARC policy should progress from p=none to p=reject on a timeline informed by real reporting data — not guesswork. DMARC Busta is designed to manage that ongoing work across 10,000+ domains from a single interface.

Autopilot mode monitors your DMARC aggregate reports and advances your policy from none → quarantine → reject automatically when the data supports it, without requiring you to manually re-edit DNS records. SPF Auto-Repair detects when a sending source changes its published IP ranges or when your SPF lookup count is at risk of exceeding the limit, and handles delegation automatically. Managed DMARC reporting parses the raw XML aggregate reports from every major inbox provider and presents them as actionable source-level pass/fail data — so you can see Postmark's authentication status alongside every other sender in your email ecosystem at a glance.

Start your free trial and put your email authentication on autopilot.