Set up DMARC and see who's sending email using your brand's domain.

How do I set up SPF for Postmark?

Do I need to create an SPF record for Postmark#

It is no longer required to include Postmark in your own custom SPF record.

Years ago when email standards were being formed, email providers used the SPF records of the From/Sender address’ domain to check for alignment. This meant that it was necessary for Postmark users to add a custom SPF record to their DNS in order to pass SPF alignment. This has since changed, and email providers no longer check the From field’s domain when evaluating SPF and determining the results.

The Return-Path domain is now used by receiving email domains to check for SPF alignment. This means your emails sent through Postmark will always pass SPF by default, without any necessary action on your end, since the Return-Path of all emails sent through Postmark already includes our outbound sending IPs and SPF record.

You’re not sure what SPF is, and acronyms make your head spin? Fear not, we’ve made a really easy to understand SPF guide. 🙂

I want my emails to pass DMARC#

Firstly, it is important to note that either DKIM or SPF are sufficient for an email to pass DMARC check. So, if you haven’t already done so, we recommend you go ahead and set up DKIM for your domains, as that is the golden standard for email authentication.

However, if you want your message sent via Postmark to pass DMARC’s more strict SPF alignment requirements, you would need to set up a custom Return-Path with us so that the From address’ domain and the Return-Path’s domain match.There are some things to keep in mind, though. 

Can I use aspf=s in my DMARC policy when sending via Postmark?#

In order for emails sent via Postmark to pass DMARC based on SPF, your DMARC policy should always be set as aspf=r (relaxed alignment). Your custom Return-Path will always have to be on a subdomain containing your domain name and therefore cannot meet the requirement aspf=s (strict alignment). If the Return Path was on your domain, we'd have no way to track bounces for you in the UI, nor have information on how our senders are performing (and therefore catch and prevent any potential cases of abuse or misconduct).

If you don’t have DMARC monitoring set up yet, you can check out DMARC Digests, our DMARC Monitoring service.

Can I add both custom Return-Path (CNAME) and SPF to my DNS?#

You cannot have both a CNAME and a TXT record (for SPF) on your subdomain at the same time. Adding a CNAME record is a powerful change which overrides other DNS records for that subdomain (TXT, MX, A...), and most DNS providers won't let you even attempt to add anything else if you already have CNAME in place. 

However, the custom Return-Path CNAME record (by pointing to already includes a TXT record for SPF. So this CNAME record will already allow SPF to pass and align with your own domain. So in reality, CNAME in the custom Return-Path is already handling SPF for you. Cool, right?

I already have a CNAME record for that domain, can I add the Return-Path to my DNS?#

Yes! As with DKIM, you can have multiple CNAME records for a domain. 

Wait, but didn't we say CNAME overwrites everything else? 

Yes, that is true, but to be really specific, our CNAME record points to a sub-domain and not the root domain the customer uses, as it would otherwise override everything else. But, by pointing it to (which in turns points to, it is ok for CNAME for the custom Return Path to overwrite everything, as you will not need to create any other records for that sub-domain that we could overwrite when you add our CNAME record to your DNS.

I already have an existing SPF record that I want to add Postmark to#

While not required, if for whichever reason you really want to, that is possible. You can add Postmark to your SPF by following this syntax: 

v=spf1 a mx include: ~all. (part in bold is Postmark)

More on that:

However, please note that you should not try adding Postmark to your SPF record as an alternative to adding the CNAME record. The effect will not be the same, as the "include" statement in a TXT record isn't the same thing as a CNAME record.

In reality, adding include: to your SPF record will do nothing for you because it will be for your root domain which is not used in your Return Path. in your SPF record will not tie back to our/your Return Path domain in any way. 

Last updated February 28th, 2024

Still need some help?

Our customer success team has your back!