Have you ever had someone (playfully or maliciously) take your phone and text someone pretending to be you? It doesn’t feel very good, does it? Even after you clarify the truth with the recipient, they’ll likely be wary of all your texts in the future. And you’ll probably be a lot more careful who you let borrow your phone. Trust has been broken.
A similar scenario is possible in the world of email, and would-be phishers don’t need your username and password to impersonate your business. Scary, right?
Fortunately, we know a simple, not-so-secret trick to protecting your brand’s reputation. It’s called Sender Policy Framework (SPF), and it’s an email reputation lifesaver.
When email is sent from one server to another, simple mail transfer protocol (SMTP) is used to get a message from the sender to the receiver. As an SMTP service, Twilio SendGrid facilitates this process.
One security weakness in the infrastructure of email is the ability of any sender or host to identify themselves, and their email, as any domain they want (kind of like how people have created TONS of Donald Trump Twitter accounts). This makes it difficult for receivers to trust that a message is actually from who it says it’s from. It also makes senders uneasy knowing anyone out there can send mail from their domain and potentially damage their brand’s reputation.
Recipients lose trust in email authenticity and senders are paranoid imposters are posing as their brand— not good for anyone! Part of the solution is the SPF record that’s stored in a txt record in the DNS. In this article, we’re going to explore all things SPF—from what it is to discovering errors with your own, we’re covering it all.
What is an SPF Record?
SPF stands for Sender Policy Framework. It’s an email authentication method that helps identify the mail servers that are permitted to send email from a particular domain. Using this validation protocol, ISPs can determine when spoofers and phishers are trying to forge emails from your domain to send malicious email to your users.
With SPF, recipients can feel confident that the email messages they receive come from who they’re expecting. And senders can rest easy knowing phishers aren’t email spoofing or phishing their audience from their brand.
More technically, an SPF record is a short line of text that the administrator of a domain adds to their txt record. The txt record is stored in the DNS (domain name system) alongside their A, PTR, and MX records. An SPF record looks something like this:
“v=spf1 ip4:12.34.56.78 include:example.com -all”
How SPF works
The above line of text is used to tell the receiving SMTP server which hosts are allowed to send mail from a given domain.
The SPF record is usually checked very early in the SMTP conversation, well before the body of the message has been transmitted. When an attempt is made to send a message, a TCP connection is opened between the sender and the receiving server.
Once the connection is established, a HELO command is issued, which essentially tells the receiving server which domain is trying to send it mail. This is followed by a MAIL FROM command that tells the receiving server what email address the message is coming from. The domain found in the MAIL FROM (also known as the envelope from and return path) command is the domain used for the SPF record check.
So suppose a message has been received, and the MAIL FROM address is [email protected]. The receiving server will check the public DNS records for example.com and look for a TXT record that begins with v=spf1. If there is no TXT record that begins with v=spf1, authentication will pass. If there is more than one TXT record that beings with v=spf1, an error may occur.
Assume one is found, and it looks like our example from before:
“v=spf1 ip4:12.34.56.78 include:example.com -all”
The receiving server will now check to see if the IP address of the SMTP client trying to send the message is included in the SPF record. If the IP address is listed, the message will pass SPF authentication.
The nitty-gritty: breaking down each piece of the SPF record
An SPF record is made up of various mechanisms, including:
INCLUDE
Always followed by a domain name. When the receiving server comes across an include mechanism, the SPF record for that domain is checked. If the senders’ IP shows up in that record, the mail is authenticated and the SPF check is over. If it isn’t found, the SPF check moves on to the next mechanism.
A
Also followed by a domain name. However in this case, the SPF simply checks for IP addresses associated with that domain. If it matches the sender’s IP, it passes, and the SPF check stops. If not, it moves on to the next mechanism.
MX
Similar to “A.” It is always followed by a domain name. If the domain listed resolves to the sending client’s IP address, authentication passes, and the SPF check is done. If not, it moves on to the next mechanism.
IP4 and IP6
Always followed by a specific IP address or CIDR range. If the sending client’s IP is listed after any IP4 or IP6 mechanism, authentication will pass and the SPF check is done. If not, it moves on to the next mechanism.
PTR
Should never be included in SPF records. For some technical reasons, they are prone to errors and cost a lot of memory and bandwidth for receiving servers to resolve. Some servers will fail an SPF authentication based on the presence of a PTR mechanism.
REDIRECT
While technically a modifier, not a mechanism, this allows the administrator of a domain to point a domain to another domain’s SPF record. If the REDIRECT function is used, no other mechanisms can be included in the SPF record, including the “all” mechanism. Sample redirect record: “v=spf1 redirect:example.com”
The “INCLUDE,” “A,” “MX,” “PTR,” “EXISTS,” and “REDIRECT” mechanisms all require DNS lookups, so there can be no more than 10 of these. This seems simple enough, but this also includes nested DNS lookups, meaning an “INCLUDE” that leads to another SPF record that has two more “INCLUDE” mechanisms would count as three DNS lookups. They add up fast!
What about Twilio SendGrid customers?
Most of our senders have set up a CNAME that points their sending domain to sendgrid.net. This means the receiving server sees the CNAME pointing to sendgrid.net, and checks that SPF record instead. So do not be surprised if most of the SPF records you query are identical.
For more Twilio SendGrid-specific questions, take a look at our Sender Policy Framework docs page. It has additional answers to some commons questions and scenarios.
How do I check my SPF record?
Not everyone uses SPF authentication, but receivers that reject based on SPF failure will reject delivery. Some receivers may also quarantine mail that fails SPF without blocking it.
Each SPF record will be a bit different, but you should check to make sure you’ve got it right. Here are three tools that can help validate your records:
- Scott Kitterman’s SPF Testing Tools: Check to see if an SPF record already exists for your domain, check its validity or test its performance.
- OpenSPF.org: Review a series of forms and email-based testers.
- SPF Record Check: The SPF Record Check acts as an SPF record lookup and validator. It’ll lookup an SPF record for the queried domain name and run diagnostic tests against the record, highlighting errors that could influence email deliverability.
- SPF Wizard: SPF Wizard is a browser-based SPF record generation tool. Fill out the form and the site generates an SPF record for you.
Make Sender Policy Framework a priority
Simply put, malicious email messages hurt your business and degrade the email channel. When phishers see your Sender Policy Framework-protected domain, they’ll be more likely to move on to easier targets. While SPF won’t prevent spam, it can serve as a deterrent and make you less vulnerable to attacks. And who doesn’t want that, right? That’s why we encourage all email clients to create an SPF record.
Combined with Sender ID, DKIM, and DMARC, SPF provides an extra level of email security that will better support your users by helping ISPs properly identify your email and in turn, the spammers.