The Sender Policy Framework (SPF) is an email authentication protocol and part of email cybersecurity used to stop phishing attacks. It allows your company to specify who is allowed to send email on behalf of your domain. This is useful because in a typical phishing attack, the threat actor spoofs the sender address to look like an official business account or someone the victim may know.
What is an SPF Record?
An SPF record added to Domain Name Service (DNS) servers tells recipient email servers that a message came from an authorised sender IP address or could be from a phishing campaign. It’s an essential component in email security and gives administrators a way to block phishing emails from reaching an intended victim.
Why Do I Need an SPF Record?
An SPF record is a DNS entry containing the IP addresses of an organisation’s official email servers and domains that can send emails on behalf of your business. SPF discourages cybercriminals from spoofing your domain, spam filters will be less likely to blacklist it. This improved reputation improves the deliverability of your legitimate mail. If you use a third-party email system (e.g., Google Suite) to manage email, you need an SPF record that tells recipient email servers that the sender is authorised to send messages on behalf of your business. If you don’t have an SPF record, the recipient’s email server may warn the recipient that the message could be a phishing attacker. For some business email servers, the system drops the message or sends it directly to the recipient’s spam inbox, so the recipient may never receive it.
Since many recipients don’t read spam messages in their inbox, businesses unable to reach the intended recipient will have difficulties communicating with customers and potential leads. Many of the larger email systems already incorporate SPF detection, so every domain owner should take the time to add a record to their DNS servers so that email messages reach the recipient’s inbox. Personal third-party email systems such as Google, Hotmail, and Yahoo already incorporate SPF records, so you don't need to add a record for personal email accounts.
How Does an SPF Record Work?
Every domain uses a DNS server that links the web server’s IP address to the friendly domain name users type into a browser window. The record added to your DNS server allows a web browser or any other service that must contact your domain to match the friendly name (e.g., mydomain.com) with your server’s IP, but DNS servers can host several different types of records. The SPF record is a TXT entry that lists the IP address of your authorised email servers. You could have one or several IP addresses authorised to send email in the SPF entry.
When a legitimate user sends a message, and an SPF record is available, the recipient email server performs a DNS lookup to find the TXT entry to determine if the sender’s server IP matches the list of authorised IP addresses for the sender’s domain. If no SPF record is found, then the sender’s email message might receive a “soft fail” or a “hard fail.” Email server administrators define the rules behind a message’s ability to reach the user’s inbox. A “soft fail” might still reach the intended recipient, but it could also be dropped by the recipient email server, depending on the security settings. A “hard fail” will either be sent to the recipient’s spam box, or the server could simply drop and delete it.
Email security is based on the recipient and sender incorporating the proper settings and filters. Recipient email servers may have high-level security that blocks a message with no SPF record or drops messages that return any failure level. A sender should always have an SPF record to avoid being flagged by the recipient email server.
SPF Record Example
An SPF record has more than just an IP address. It also instructs the recipient server on what to do if the sender IP doesn't match the list of authorised IP addresses. Because IP addresses can be IPv4 or IPv6, you can define both versions in an SPF record. Each email message contains two “headers”, a visible header, which you can see at the top of any email message and a hidden, technical header. Each header contains a “from” email address: the one you see in the visible header (a.k.a. “header from” or “friendly from”) and the “envelope from” address that is contained in the hidden technical header of the email (a.k.a. Return Path or mfrom). Here are examples of what each header looks like:
Technical, hidden header:
Another example SPF record could look like the following:
v=spf1 ip4:188.8.131.52 ip6:2a05:d018:e3:8c00:bb71:dea8:8b83:851e include:authorized-domain.com -all
Breaking down each component in the above SPF record, the first component, “v-spf1”, provides the version of the SPF entry. The version will always be SPF1 for now, and it provides a way for the recipient’s email server to identify the TXT record that provides SPF information.
The “ip4” and “ip6” entries are the IPv4 and IPv6 addresses for your authorised email servers. You can list several IP addresses by separating each one with a space and using the prefix “ip4” or “ip6” and a colon. For example, the following SPF record defines two IPv4 addresses as authorised servers:
v=spf1 ip4:184.108.40.206 ip4:220.127.116.11 ip6:2a05:d018:e3:8c00:bb71:dea8:8b83:851e include:authorized-domain.com -all
The “include” directive indicates that the defined third-party domain can send mail on behalf of your organisation. For example, suppose that you send bulk marketing emails using a third-party provider. Include this third-party email provider in your SPF record, so that recipient email servers don't drop or spam box the messages.
Finally, the “-all” directive is important and tells the recipient server what policies to use if the sender does not use an authorised IP address. The “-all” directive tells the recipient server to set the flag to “fail”. There are two other options. The “~all” directive results in a “soft fail”, which could reach the recipient’s inbox but leave a warning that the message could be malicious. The “+all” directive bypasses any security restrictions and tells the recipient server to set the message to “pass”, which means any sender can reach the recipient’s inbox. The latter setting is considered an insecure policy and should be avoided.
How to Create an SPF Record
How you create an SPF record depends on your DNS host. If you use your domain registrar’s DNS server, the registrar typically has a dashboard where you can add and delete DNS entries. This dashboard is where you add an SPF record.
The first step is to craft your SPF record. You can use the previous examples as a template to build your own. Change the IP addresses to your own and delete the third-party domain if you don't have external email services sending messages on behalf of your business. After you craft the SPF entry, you’re ready to publish it to your DNS server.
An SPF record is a TXT entry, and your DNS provider lets you choose this entry type in the dashboard. Typically, your DNS server is a third-party provider, at your registrar, or available through the company that hosts your domain. If you need help, most host providers will help you with critical settings such as DNS entries.
To add the DNS entry, go to the provider that hosts your DNS server, and copy and paste your crafted record into the DNS settings and make sure you choose TXT for the entry type. After you save the record, it could take up to 72 hours for changes to propagate across the internet. Make sure you consider this before you test the new settings.
You can test the new changes by sending a message from your email provider to a recipient. For example, if you use Google Suite and added an SPF record for your domain, you could send a message from your business account to your personal account to test it. You must look at the email headers to determine the result of the SPF lookup.
For example, you can view Gmail headers by clicking the “More” button on a message and choosing the “Show Original” menu option. The header window opens, and the top section of the header shows you the results of the SPF lookup. The following image is an example from Gmail:
Notice that the SPF record passes, so this message was considered a legitimate email in Gmail and reached the recipient’s inbox. You can go through your spam inbox to find records that fail SPF and notice that Gmail labels them with a warning message.
As phishing attacks continue to be a primary tool for threat actors, SPF records and other email security help warn users when they receive malicious messages. With SPF records, attackers cannot use your domain to launch phishing campaigns against a targeted victim. It protects your business reputation and your users from becoming victims.
Many organisations have invested in email fraud training for employees and consumers. But despite this investment, people continue to be deceived by business email compromise (BEC)—highly-targeted, low volume attacks that trick employees by spoofing trusted corporate identities—and credential phishing scams. And they work. According to Verizon, 30 percent of phishing messages get opened by targeted users and 12 percent of those users click on malicious attachments.
Email authentication, not people, should always be your first line of defence against impostor email attacks. It removes the guesswork for targeted recipients by identifying and blocking bad messages before they reach the inbox. However, SPF, on its own, is not sufficient to block phishing emails targeting your employees and customers. It has a few major challenges:
Accuracy: the vendors sending email on your brand’s behalf often change and multiply. If you don’t have visibility into these changes in real time, your SPF records will become out of date.
Tolerance: SPF is one of many signals that email providers use to inform their delivery decision. An SPF failure does not guarantee that the message will be blocked.
Immunity: If an email is forwarded, the SPF record breaks.
Protection: SPF does not protect the “header from” address, which users see in their email clients, from being spoofed. Cybercriminals can pass SPF by including a domain they own in the “envelope from” address and still spoof a legitimate brand’s domain in visible from address.
Luckily, other email authentication technology can fill these gaps.
The Next Evolution of Sender Policy Framework: Hosted SPF
Sender Policy Framework, or SPF for short, first originated two decades ago to prevent scammers from sending messages from a spoofed domain.
Proofpoint Hosted SPF Technical Overview
Proofpoint Hosted SPF is a DNS service available to customers of Proofpoint Email Fraud Defense.
What Is DKIM?
DKIM protocol allows organisations to send messages in a way that can be securely authenticated by email providers. Learn how a DKIM record works and more.