SPF record: Protect your domain reputation and email delivery

What is an SPF record? #

SPF (Sender Policy Framework) is an email authentication standard that helps protect senders and recipients from spam, spoofing, and phishing. By adding an SPF record to your Domain Name System (DNS), you can provide a public list of senders that are approved to send email from your domain. Receiving servers can then cross-check that email originated from a server with permission to send on your domains’ behalf.

Here’s a practical example: imagine you are using an email API like Postmark to send your transactional email, and email software like Campaign Monitor to send your marketing emails. You will include both services as approved senders in your list by using an SPF record that looks like this:

v=spf1 a mx include:spf.mtasv.net include:_spf.createsend.com ~all

This way, receiving mail servers will be able to check that your messages originate from a server that’s on your list—spf.mtasv.net is Postmark’s SPF record and _spf.createsend.com is Campaign Monitor’s—and if they aren’t, then the receiving server can consider it fake and act accordingly. 

Likewise, if you use separate IP addresses and subdomains to send your marketing vs. transactional emails (which we recommend), you will include both IPs as approved sending sources.

Why should I add an SPF record to my domain? #

You can still send emails without setting up SPF, but having an SPF policy provides an additional trust signal to ISPs so you can increase the likelihood that your emails reach your recipient’s inbox.

SPF won't solve all of your delivery problems, but it’s an additional layer that, combined with standards like DKIM and DMARC, can improve your delivery rates and prevent abuse.

Understanding the limitations of SPF #

The SMTP protocol, which is the standard for email transmission, has no protections on the From field in an email: as long as it’s a valid email address, there is no further validation. This means a malevolent actor can impersonate your bank, your employer, or anyone at all—and that’s what led to the creation of SPF.

Here’s the thing, though: SPF does not validate against the From domain. Instead, it looks at the Return-Path value (aka: the email address used by receiving servers to notify the sending mail server of delivery problems like bounces) and uses it to validate the originating server. This means an email can pass SPF regardless of whether the From address is fake.

Plus, even if a message fails SPF, there's no guarantee it won't actually be delivered: that final decision about delivery is up to the receiving ISP.

So yes, SPF isn’t perfect. But it’s a rather elegant and simple solution, in that it uses existing architecture pieces to make it a little harder for bad actors to impersonate your domain. Plus, we’re lucky to have more authentication tools available to protect our brands and our recipients from the bad folks out there. In addition to SPF, you should also set up DKIM (a security standard designed to make sure messages aren’t altered in transit between servers) and DMARC (a clever standard that builds on top of DKIM and SPF to stop spammers from using your domain to send email without your permission.)

You can learn more about DMARC with our handy DMARC guide.

How do SPF records work? #

Now that you have the big picture behind SPF, let’s take a look at an SPF policy in action and see how the process unfolds:

At a high level, here is the workflow of how a mail server checks SPF:

• The server with the IP address of 1.2.3.4 sends an email, and that email is using bounces@example.com as the Return-Path.
• The receiving mail server grabs the Return-Path domain and checks out the domain’s DNS records for example.com, looking for the SPF record.
• The receiving server found the SPF record for example.com! Now, it checks if any of the IP addresses listed as valid senders for the domain match the address that was used to send the email.
• In this example, it’s a match! The sending IP 1.2.3.4 is listed as an approved sender, so SPF passes. ✅  If the IP addresses don’t match, that would cause SPF to fail. This would likely make the receiving server suspicious and they might reject the mail.

How do I implement an SPF record on my domain? #

Before you jump right into implementing SPF, let’s look at whether your sending setup even requires you to take action.

1. Understand your Return-Path #

Remember that SPF is all about the domain used in your Return-Path, not your FROM domain. So first of all you’ll have to find out what Return-Path is used for your email sending.

Some email sending services (ESPs), including Google, will use your domain in the Return-Path. In this case, you’ll have to set up SPF for your domain.

Other ESPs, including Postmark, will use their own domain in the Return-Path. In this case, your ESP must set up SPF (and you don’t need to fiddle with it. Yay!).

Investigating your email headers is the easiest way to find out what Return-Path is at work for your emails:​​

Here’s an example email header with an mtasv.net Return-Path. That’s a Postmark Return Path so you don’t have to worry about setting up SPF.

However, there might be cases where brands use an ESP but want to set up a custom Return-Path with their own domain instead of using the EPS’s default Return-Path. (That’s often a required step done if you want to achieve 100% DMARC alignment.) In this case, you’d have to set up SPF for your domain as well.

You’re using your own domain in the Return-Path? Alright friend, you’ll need to move on to step 2!

2. Create your SPF record #

When you’re using an email service provider to send your emails and want to add them to your SPF record, the easiest way to do that is to just search their help documentation to find the right SPF info for your sending services.

For Postmark, for example, your SPF record looks like this:

v=spf1 a mx include:spf.mtasv.net ~all.

Adding multiple senders to your SPF record

It’s very normal for brands to not just have one but multiple tools to send email. Transactional emails, newsletters, emails from your help desk—it’s not uncommon for all these emails to come from different sources. And you’ll want to add them all to your SPF record.

It’s important to know, though, that a domain can only ever have one SPF text record. If you want to add another sender, you’ll add them into that existing record. Don’t create a brand new record—that’s a common error that can cause valid servers to fail SPF. Instead, a proper SPF record that includes three senders (in this case Postmark, Campaign Monitor, and Helpscout) will look like this:

v=spf1 a mx include:spf.mtasv.net include:_spf.createsend.com include:helpscoutemail.com ~all.

Want to know what the rest of that gibberish in an SPF record means? You’re a curious bunch! Jump ahead to the syntax section for the nitty-gritty details.

3. Update your domain’s DNS settings #

Now, let’s get your new SPF record added to the DNS settings for your domain! That’s done by navigating to your hosting provider and updating the DNS settings over there. This process might look slightly different depending on your hosting provider. We’ll use Namecheap for this example.

Log into your hosting provider and navigate to your domain’s DNS settings.

Here’s where you’d update your DNS settings for a domain hosted in Namecheap

Here you’ll be able to create a new DNS record. Pick TXT record as the Type, add an “@” to the Host field, and copy your SPF record from above into the value field.

And that’s it! We’ve successfully added Postmark as a legit sender for our example.com domain! ✅

How does the SPF record syntax work? #

SPF record syntax might look complicated and confusing at first, but it is fairly easy to understand once you know the basics.

Let’s look at a breakdown of the key elements (also called “mechanisms”) in an example SPF record entry of v=spf1 a mx include:spf.mtasv.net include:_spf.createsend.com ~all.

The first thing to note is the syntax of the SPF record. It’s broken down into the version prefix and one or more mechanisms:

The version prefix is pretty simple. Since there can be multiple TXT records for a domain, this is the way to let parsers know that this is the record to be used for SPF checking.

The second part of the SPF record are the mechanisms. These specify different rules on how to check for SPF.

What are SPF qualifiers? #

The mechanisms can also have a prefix that describes the action to take when a sending IP matches the qualifier. The default qualifier is +. So the Postmark SPF record is the same as:

Let’s go over what qualifiers are available.

• + Pass, an IP that matches a mechanism with this qualifier will pass SPF.
• - Fail, an IP that matches a mechanism with this qualifier will fail SPF.
• ~ SoftFail, an IP that matches a mechanism with this qualifier will soft fail SPF, which means that the host should accept the mail, but mark it as an SPF failure.
• ? Neutral, an IP that matches a mechanism with this qualifier will neither pass or fail SPF.

What are SPF mechanisms? #

The “a” mechanism

Let’s say that I send mail from IP 1.2.3.4 for the domain “example.com.” If “example.com” has an A record that returns 1.2.3.4 then this mechanism will pass.

The “mx” mechanism

Any domain that hosts email has one or more mx records. These records define which email servers can relay email. For instance, when using Google Apps, you insert several MX records into DNS. Including the “mx” mechanism automatically approves these servers and avoids you having to list them individually. This also avoids maintaining the list if they change later.

The “include” mechanism

Let’s say that I send mail from IP 1.2.3.4 for the domain “example.com.” If the SPF record for “example.com” includes spf.mtasv.net and 1.2.3.4 passes against the SPF record for spf.mtasv.net, this mechanism will pass.

The “all” mechanism

The "all" mechanism will match against everything, and in this case, the result will be a SoftFail for everything that gets to this point.

---

Here are some FAQs if you are still curious... #

Why doesn’t SPF focus on the From address? #

Though it seems like the From address is what spammers would want to impersonate, SPF protects the envelope sender, and it stops spammers from abusing mail systems with backscatter and other irrelevant traffic. DKIM protects the From address by cryptographically signing messages to verify the author.

If I add an SPF record to our DNS, will I see which emails are blocked? #

Not always. If you'd like a report on how an email from your domain performs against SPF checks, you can set up DMARC to get weekly reports.

Will the email sender get a bounce message, or does the email disappear if it fails SPF? #

It's really up to the recipient server to decide how they handle messages that don't align with SPF. Sometimes postmasters choose to bounce these failed messages, and other servers choose to discard messages that fail SPF.

Resources #

Learn more about email authentication with these Postmark guides:

• DMARC
• DKIM

Dive deeper into SPF:

• Open-SPF.org
• How to Explain SPF in Plain English