What Is Sender Policy Framework (SPF)?

The Sender Policy Framework (SPF) is an email authentication protocol designed to prevent email spoofing, a common technique used in phishing attacks and email spam. As an integral part of email cybersecurity, SPF enables the receiving mail server to check whether incoming email comes from a domain authorized by that domain’s administrators.

This authentication is helpful because, in a typical phishing attack, the threat actor spoofs the sender’s address to look like an official business account or someone the victim may know. By implementing SPF, organizations can help protect their domain from being misused by malicious actors who send out phishing or spam emails, thereby enhancing their email deliverability and overall reputation.

At the core of SPF is a simple technical process: it specifies a method for receiving mail servers to check that a host authorized by that domain’s administrators is behind incoming email. The Domain Name System (DNS) records lists a domain’s authorized sending hosts and IP addresses.

When an email is received, the SPF protocol enables the receiving server to verify that the domain’s owner authorized the email claiming to come from a specific domain. Once verified, the email is accepted. If it fails, the email is considered spoofed and typically marked as spam or rejected.

While SPF can effectively improve an organization’s email security posture, SPF alone is not enough. SPF should be one part of a multi-layered email security approach combining other techniques such as DKIM (Domain Keys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting & Conformance).

An SPF record is a type of DNS record that identifies which mail servers are permitted to send email on behalf of your domain. The purpose of an SPF record is to prevent spammers from sending messages with forged “From” addresses to email accounts under your domain.

In technical terms, an SPF record is an entry in a domain’s DNS, specifying which IP addresses and hostnames are authorized to send emails for that particular domain. When an email is received, the mail server can check the SPF record of the sending domain to ensure the email is legitimate. If the source of the email is found on the list of authorized servers, the message passes the SPF check. If not, the email delivery will fail, marking the email as spam or rejected.

Having an SPF record is an essential part of email authentication. It allows administrators to block phishing emails from reaching an intended victim.

An SPF record is a DNS entry containing the IP addresses of an organization’s official email servers and domains that can send emails on behalf of your business. SPF records specify which email servers are allowed to send emails for your domain, thereby reducing the chances of your emails being marked as spam. This improves your emails’ deliverability, ensuring they reach the recipient’s inbox rather than being redirected to the spam folder.

Maintaining an SPF record is vital for protecting your domain’s reputation. If your domain is used for spamming due to the absence of an SPF record, your legitimate emails might be blocked or end up in spam folders, which could tarnish your domain’s reputation.

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 authorized 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 inboxes, businesses 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.

SPF records require specific formatting and values to work appropriately, often relying on the setup of domain administrators. SPF is just one component of email authentication and works in conjunction with other standards like DKIM and DMARC.

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 authorized 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 at the top of an 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 contained in the email’s hidden technical header (a.k.a. Return Path or mfrom). Here are examples of what each header looks like:

Visible header:

Technical, hidden header:

Another example of an SPF record could look like the following:

v=spf1 ip4:48.213.51.127 ip6:2a05:d018:e3:8c00:bb71:dea8:8b83:851e include:authorized-domain.com -all

A few other specific examples of SPF records include:

SoftFail: This example allows email from the specified IP address but marks it as potentially suspicious.

V=spf1 ip4:192.0.2.0/24 ~all

HardFail: This SPF record example only allows emails to be sent from the specified IP address and rejects all other emails.

V=spf1 ip4:192.0.2.0/24 -all

Redirect mechanism: This example redirects to another domain’s SPF record.

V=spf1 redirect=_spf.example.com

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, providing a way for the recipient’s email server to identify the TXT record that includes SPF information.

The “ip4” and “ip6” entries are the Ipv4 and Ipv6 addresses for your authorized email servers. You can list several IP addresses by separating each with a space and using the prefix “ip4” or “ip6” and a colon. For example, the following SPF record defines two Ipv4 addresses as authorized servers:

v=spf1 ip4:48.213.51.127 ip4:31.217.43.153 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 organization. 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 because it tells the recipient server what policies to use if the sender does not use an authorized 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 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.

To create an SPF record, follow these simple steps:

1. Gather IP addresses used to send email: Make a list of all the mail servers and their IP addresses that you use to send email from your domain.
2. Create your SPF record: Use the gathered IP addresses to specify which servers are authorized to send email on behalf of your domain. The SPF record is a DNS TXT record that contains this information.
3. Publish your SPF record into your DNS: Once you have created your SPF record, you need to publish it into your DNS. This involves adding the DNS TXT record to your domain provider.
4. Test your SPF record: After publishing your SPF record, test it to ensure it’s set up correctly. This can be done using SPF record testing tools available online.

It’s worth noting that SPF record generators are available to help simplify creating an SPF record.

You can assess 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 header’s top section displays the SPF lookup results. 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 prevents your users from becoming victims.

Many organizations have invested in email fraud training for employees and consumers. 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, targeted users open 30% of phishing messages, and 12% of those users click on malicious attachments.

Email authentication, not people, should always be your first line of defense against impostor email attacks. It removes the guesswork for targeted recipients by identifying and blocking bad messages before they reach the inbox. However, SPF alone cannot 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 outdated.
• Tolerance: SPF is one of many signals email providers use to inform delivery decisions. 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 the visible “from” address.

Luckily, other email authentication technology can fill these gaps.

While SPF is an essential tool in email authentication, it’s just as important to understand its limitations.

• DNS lookup limitations: The SPF specification limits servers to 10 DNS lookups to fully resolve an SPF record. This limitation is intended to prevent denial of service (DoS) attacks. But it could also cause problems for users recklessly using the included modifier.
• Character limitations: SPF records have a 255-character limit for a single string, an inherent limitation of DNS TXT records.
• Incomplete solution: SPF does not provide complete end-to-end encryption or protect against phishing attacks that use lookalike domains. Thus, SPF is just one part of a more comprehensive email authentication solution.
• Difficulty maintaining SPF records: SPF records can be challenging to maintain, especially for organizations with complex email infrastructures. As organizations add more email servers or third-party email services, keeping the SPF record up to date can become difficult.
• Breakable via improper email forwarding: Improper email forwarding can break SPF authentication. If an email is forwarded through a server not authorized in the SPF record, the email may fail SPF authentication.
• Large organizations may require multiple SPF records: Large organizations with multiple domains may need multiple SPF records, which can be challenging to manage.

Despite these limitations, SPF is still an integral security protocol that can help prevent email spoofing and phishing attacks.

To get the ball rolling, try Proofpoint’s DMARC Creation Wizard, a free online tool that helps organizations create a DMARC record for their domain. Here, you can check your domain’s DMARC record and SPF records as well.

The tool is part of Proofpoint’s Email Fraud Defense, a comprehensive email security solution that supports SPF and DMARC to protect against email spoofing and social engineering attacks like phishing. It’s streamlined to check your domain’s DMARC and SPF records and identify legitimate senders while ensuring they’re properly authenticated.

Email Fraud Defense offers visibility into who is sending email on behalf of your domains, allowing you to authorize legitimate senders and block unauthorized messages. See activity via an intuitive reporting portal and leverage regular meetings with a Proofpoint consultant to help you strengthen your email security posture.