The battle against spam and email scams is never-ending, and several standards have evolved to help stem the tide as a result. An SPF (“Sender Policy Framework”) record is one of those standards: it enables a domain to state which servers may send emails on its behalf.
You don't have to understand every detail of an SPF record to use it, but a deeper knowledge can help you see the bigger picture. Let’s see how you can protect your domain reputation and improve your email deliverability.
- What is an SPF record?
- Why should I add an SPF record to my domain?
- How do SPF records work?
- How do I implement an SPF record on my domain?
- How does the SPF record syntax work?
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.
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.)
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:
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:
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 ESP, 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!
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 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.
