Postmark SPF: the custom Return-Path replaces the include

Search for "Postmark SPF include" and you'll find include:spf.mtasv.net in a lot of old client records. Postmark's own support article now opens with the answer: "It is no longer required to include Postmark in your own custom SPF record." It goes further and says that adding the include to your root domain "will do nothing for you." What Postmark recommends instead is DKIM, plus a custom Return-Path if you want SPF to align for DMARC. This page explains why.

Why the root-domain include doesn't help

SPF (RFC 7208) checks the envelope sender, the RFC 5321 MAIL FROM address that ends up in the Return-Path header. It doesn't check the From: address the recipient sees. Postmark's article explains that every message it sends already has a Return-Path on a Postmark domain whose SPF record covers Postmark's sending IPs, so "your emails sent through Postmark will always pass SPF by default."

The catch is that the default pass belongs to Postmark's domain. A receiver checking SPF never looks at the client's root SPF record for these messages, so include:spf.mtasv.net there has no effect on them. Postmark says the include "will not tie back to our/your Return Path domain in any way."

What passes DMARC

DMARC (RFC 9989) needs SPF or DKIM to pass and the authenticated domain to align with the From: domain. With Postmark you have two ways to get there.

1. DKIM (start here). Postmark calls DKIM "the golden standard for email authentication" and recommends setting it up for every sending domain. A DKIM signature for the client's domain aligns with a From: address on that domain, and DMARC passes no matter what SPF does. Copy the DKIM record from the client's Postmark account. Don't type it from a guide.

2. A custom Return-Path (aligned SPF). To make SPF align too, Postmark has you publish a CNAME on a subdomain of the client's domain. Postmark's example is pm-bounces.client.com pointing to pm.mtasv.net. Postmark then uses that subdomain as the envelope sender. Postmark says the CNAME target "already includes a TXT record for SPF," so the custom Return-Path "is already handling SPF for you."

On Oct 13, 2026, a live DNS check showed that pm.mtasv.net publishes v=spf1 include:spf.mtasv.net -all, and that spf.mtasv.net lists ip4 ranges only. This is an observation, not a documented guarantee.

The alignment rules that catch people out

• Use relaxed SPF alignment. Postmark says your DMARC record should use aspf=r, because the custom Return-Path is always a subdomain and "cannot meet the requirement aspf=s." Relaxed is the default under RFC 9989, so if the client's DMARC record has no aspf tag, you're fine.
• Don't put a TXT record on the Return-Path subdomain. Postmark notes that you can't have both a CNAME and an SPF TXT record on the same name. The CNAME is the whole configuration for that host.
• The CNAME goes on a subdomain, never the root. Pointing a root domain's CNAME at Postmark would override every other record there. Postmark points out that the Return-Path host is a dedicated subdomain for exactly this reason.

If a client insists on the include anyway

Postmark says that if you really want to, you can add it with this syntax: v=spf1 a mx include:spf.mtasv.net ~all, where the include is the Postmark part. It also says not to use this "as an alternative to adding the CNAME record," because the effect isn't the same. If you do add it, merge it into the existing SPF record rather than publishing a second one. Two v=spf1 records are a permerror under RFC 7208 §4.5. It also costs a lookup toward the limit of 10.

On most client domains, the cleaner move is to remove a stale include:spf.mtasv.net from the apex once DMARC reports show Postmark mail passing on DKIM, or on the custom Return-Path. That frees up a lookup.

What to tell the client

Clients and their developers often read "SPF include missing" in some scanner and assume Postmark isn't set up. A short explanation helps: "Postmark sends with its own bounce address, which already passes SPF. Your domain's own SPF record doesn't come into it. What makes your mail trusted under DMARC is the DKIM signature for your domain, and we've confirmed it's passing. If you want SPF to line up with your domain as well, we add one CNAME for a bounce subdomain. We don't need to change the main SPF record." That keeps the conversation on evidence from a real message header instead of a checklist line.

A client checklist

• Set up DKIM for each sending domain in Postmark, and confirm it verifies.
• If you want aligned SPF too, add the custom Return-Path CNAME on a dedicated subdomain.
• Check the DMARC record. aspf=s will block SPF alignment through Postmark.
• Send a test message and read the Authentication-Results header. You want dkim=pass with header.d on the client's domain, and smtp.mailfrom showing the Return-Path subdomain if you set one.
• Remove leftover include:spf.mtasv.net entries from apex records only after reports confirm that nothing depends on them.

Check the client's SPF now

Run the free SPF checker →

It walks the include tree, counts DNS lookups against the RFC 7208 limit of 10, names common senders, and flags duplicate records and +all or ?all endings, so you can see what a leftover include is costing.

Founding Partner: $1,999, one time. Clean up the leftover vendor includes across your client base and show each client a branded before-and-after. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →