The Sender Policy Framework (SPF) authentication method identifies the authorized mail servers permitted to send email on behalf of a given domain. The SPF standard helps to solve the problem of how to identify official sources of email from an organization. When an organization sets up SPF, it helps Internet Service Providers (ISPs), email security vendors, and other email providers to validate an organization’s email communication and distinguish authorized communications from spoofed emails or phishing attacks attempting to impersonate that domain.
This article helps to understand:
- How does Sender Policy Framework Work?
- How to Set Up SPF
- Sender Policy Framework Advantages
- Sender Policy Framework Limitations
- Sender Policy Framework FAQs
- Bottom Line: SPF – A Critical First Step to Eliminate Phishing
How Does Sender Policy Framework (SPF) Work?
SPF enables a form of email authentication that defines the domains and internet protocol (IP) addresses authorized by an organization to send emails. SPF deploys within the Domain Name Service (DNS) records with the organization’s domain hosting provider.
Email-receiving servers check the email header for the sending domain and then perform a DNS lookup to see if an SPF file exists that matches the sending domain. When the SPF Record’s sending domain matches the Email Header’s sending domain, the email passes the SPF check and may be delivered to the recipient. When an SPF record does not exist or the email’s sending domain does not match the published DNS records, the email may be rejected or sent to a spam folder.
SPF Fundamentals
To understand how SPF works, it is important to understand the SPF file structure and file options.
Basic SPF File Structure
The Internet Engineering Task Force (IETF) publishes the full information on the SPF and its standards which were last updated in 2014. At its core, the SPF file consists of a simple .txt file uploaded to the DNS record on an organization’s domain hosting provider. It is also important to note that SPF records cannot exceed 10 tags or 255 characters, which can cause significant limitations for larger organizations.
SPF File Options
The basic file structure uses the syntax:
<version> <IP4 and/or IP6 address> <include: domain> <all tag>
- Version will always be “v=spf1” as all other SPF versions have been discontinued
- IP Address
- Can be either the IP4 or IP6 address for IP addresses authorized to send email on behalf of the domain
- Will be in the format ip4:<ip4-address>, ip4:<ip4-network>/<prefix-length>, ip6:<ip6-address>, ip6:<ip6-network>/<prefix-length>
- The prefix-length will be assumed to be /32 for IP4 and /128 assumed for IP6; IP4 prefix-lengths less than /16 should not be used to avoid impact to smaller receivers
- Include syntax will be “include:senderdomain.net” where senderdomain.net is the domain of a third-party authorized to send emails on behalf of the organization; preceding the command with a “?” flags emails as neutral instead of pass if they match the sending domain
- All tags provide other servers with recommendations for how to handle emails that fail an SPF check:
- -all = reject emails that fail SPF check
- ~all = mark emails that fail SPF check as suspicious
- ?all = recipient server can determine what to do with emails that fail the SPF check
- +all = allow any domain to send emails on behalf of the organization (not recommended)
The Sender Policy Framework allows for many other options, but their use can be dangerous. Organizations seeking to use these options should work carefully with their vendors and IT staff to ensure correct syntax and usage. Examples of the more advanced options include:
- “a” mechanism provides a domain or network address within which all records are checked for matches
- “mx” mechanism provides a list of mail exchange ip addresses
- “ptr” will be used by an organization that allows all of its servers to send mail; not typically used
- “exists” performs a query on the domain looking for a match to the SPF record
Related Email Standards
SPF provides authentication with a narrow scope. A more robust solution will also implement the DKIM and DMARC authorization frameworks as well.
DKIM: DomainKeys Identified Mail (DKIM) enables an organization to digitally sign emails from their domain using public key cryptography.
DMARC: Domain-based Message Authentication Reporting and Conformance (DMARC) enables more direct control over emails that fail SPF and DKIM and enables reporting on legitimate and spoofed emails.
How to Set Up SPF
Sender Policy Framework (SPF) can be simple to set up and configure. At its most basic level, SPF just requires a simple one line change to a domain record in order to work. For example, with many hosting companies, you’d complete the following steps:
- Log into the domain registrar and click on the option to manage or configure DNS settings
- Find and click the “Add a New Record” option and choose a “TXT” record
- In the host name dialogue, enter either @ or the name of your domain.
- Copy-paste the SPF information into “value,” which defines SPF options
While simple in theory, many organizations will have specialized requirements that require additional options or modifications. For example, both Google and Microsoft publish specific instructions for including Gmail and Microsoft 365 mail servers into SPF files. After drafting an initial SPF, the organization should also check with their domain hosting provider and their various mail services (EX: HubSpot, Mailchimp) to ensure that the SPF has been properly drafted and configured.
For organizations that need additional assistance there are many services that can operate on the organization’s behalf to draft and enable SPF. These services are available either as a standalone service or in a package with DKIM and DMARC deployment.
Verifying and Troubleshooting SPF
After implementing SPF, it may take several days for the DNS record to propagate across the internet. However, after that takes place, the company can send emails and inspect the header of the email for “spf=pass.”
Of course, it can be easy to incorrectly deploy the SPF, so if any issues are encountered, the organization should check for:
- Incorrect syntax such as extra spaces, typographical errors, etc.
- More than 10 email senders, since this will cause errors. If an organization has more than 10 authorized sending domains, they may need to establish multiple SPF records using sub-domains.
- More than 255 characters between sending domains and optional flags — these will be invalid, so the SPF will need to be shortened, corrected, and refiled.
- Incorrect vendor information, which can create SPF fail conditions. Work with the vendor to make sure the information in the SPF reflects the specific IP address or domain used to send the emails instead of bounceback domains, website URLs, etc.
- Unnecessary “a” and “mx” entries, as these can cause confusion and errors since instead of reflecting the outbound email server IP address, the “a” address will typically be the domain’s web host IP address and the “mx” hosts are typically used for inbound emails.
Email authentication vendors such as dmarcian will offer free tools that can provide a quick analysis of the SPF record and help an organization to troubleshoot issues.
SPF Advantages
A properly configured SPF provides two key tangible benefits: impersonation mitigation and improved domain reputation. For most organizations, these benefits should outweigh the more numerous but minor disadvantages.
Impersonation Mitigation
The subset of email phishing attacks known as email spoofing attempt to impersonate legitimate organizations to improve the likelihood of tricking a reader. When deploying a properly configured SPF, it becomes more difficult to impersonate the organization.
When any mail server receives a spoofed email, it will compare the sending IP address against the SPF file and reject the spoofed email that does not originate from the organization’s mail server. This will help to protect the reputation of the company by blocking spam emails trying to use the organization’s brand. Additionally, it can block phishing attacks attempting to spoof the organization’s own employees — such as when a phishing attack attempts to impersonate the CEO.
Improved Domain Reputation
When an organization does not establish an SPF, email servers that receive the organization’s emails may flag or reject them because authenticity of the organization’s domain cannot be verified. Establishing an SPF improves the reputation of the organization’s domain and improves the deliverability rate of legitimate emails.
Limitations of Sender Policy Framework
SPF provides protection against spam, spoofing, and phishing email and bolsters email security worldwide. However, it also suffers from numerous, although more minor, limitations.
Challenging to Maintain
Organizations must keep their SPF records constantly updated even as their vendors change email servers, the organization changes ISP providers, or marketing adds new email newsletter services. Changes can be time-consuming and cumbersome to verify with all parties, which makes DNS updates difficult to do regularly.
Breakable via Improper Email Forwarding
Forwarded emails often change the sending IP address, which causes the SPF check to fail. Organizations should correct server settings so that forwarded emails retain the correct information, but many do not.
Incomplete Solution
SPF only verifies the sending domain in the email header and does not compare against the “from” email address presented to the user. If a phishing attacker applies their own SPF file with their own sending domain, the SPF will pass as valid. To be more robust, SPF, DKIM, and DMARC should be used in combination to protect an organization’s reputation and validated emails.
Large Organization Issues
The larger an organization, the more likely it is to have a large number of servers and services sending email for the organization. With a 255 character limit and a 10 address DNS lookup limit, larger organizations cannot publish all of their sending IP addresses in a single SPF record. Instead, they must use sub-domains to work around SPF limitations.
Poor ROI Measurements
Although the organization can recognize reputation improvements and more reliably deliverable emails, these benefits will be difficult to quantify for return on investment measurements. Additionally, the primary benefit generally applies to others: the email servers and email security tools that receive the emails and perform the check on the SPF record to block spam and phishing email. While the investment is low to implement SPF, the intangible ROI and benefits explain why adoption isn’t higher than 50%.
Potentially Spoofable
SPF can be adopted by any organization — even malicious actors and spammers. Since a SPF check does not include the “From” information in the body of the email, malicious actors can publish their own SPF file to authenticate their spoofed emails or spam using their own domain information and then present the email recipient with completely different information in the “From” field visible through the email program.
Requires Proper Email Server Settings
SPF only works on email servers set up to check for SPF or using email security tools performing the same task. Servers can easily skip SPF checks and allow spam and spoofing emails to proliferate.
SPF FAQS:
What is a Sender Policy Framework (SPF) record?
Until 2014, some SPF files could use their own file format, called an SPF record. Since 2014, an SPF record is a line of text that is stored in the DNS of a domain and contains all necessary SPF information.
What is an SPF record check?
An SPF record check, sometimes called an SPF validator, determines if an SPF record is valid by looking up the DNS record for a domain. SPF record check tools display any records found and test the record to flag potential issues that could affect mail delivery.
Bottom Line: SPF – A Critical First Step to Eliminate Phishing
Phishing remains the primary vector for cybersecurity and network attacks because too many spoofing emails remain unflagged. SPF is the first step in the SPF-DKIM-DMARC email authentication process that could block the vast majority of phishing emails if enough organizations adopt SPF along with DKIM and DMARC. While tedious to maintain, the low cost to deploy SPF should encourage all organizations to adopt SPF as a first step toward fighting email phishing world-wide — or at the very least protecting themselves against phishing impersonating their own domain.
