How Does Sender Policy Framework (SPF) Work?<\/h2>\n\n\n\n
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\u2019s domain hosting provider.<\/p>\n\n\n\n
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\u2019s sending domain matches the Email Header\u2019s 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\u2019s sending domain does not match the published DNS records, the email may be rejected or sent to a spam folder.<\/p>\n\n\n\n To understand how SPF works, it is important to understand the SPF file structure and file options.<\/p>\n\n\n\n The Internet Engineering Task Force (IETF)<\/a> 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\u2019s 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.<\/p>\n\n\n\n The basic file structure uses the syntax:<\/p>\n\n\n\n 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:<\/p>\n\n\n\n SPF provides authentication with a narrow scope. A more robust solution will also implement the DKIM and DMARC authorization frameworks as well.<\/p>\n\n\n\n DKIM:<\/strong> DomainKeys Identified Mail<\/a> (DKIM) enables an organization to digitally sign emails from their domain using public key cryptography.<\/p>\n\n\n\n DMARC:<\/strong> Domain-based Message Authentication Reporting and Conformance<\/a> (DMARC) enables more direct control over emails that fail SPF and DKIM and enables reporting on legitimate and spoofed emails<\/a>.<\/p>\n\n\n\n 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\u2019d complete the following steps:<\/p>\n\n\n\n While simple in theory, many organizations will have specialized requirements that require additional options or modifications. For example, both Google<\/a> and Microsoft<\/a> 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.<\/p>\n\n\n\n For organizations that need additional assistance there are many services that can operate on the organization\u2019s behalf to draft and enable SPF. These services are available either as a standalone service or in a package with DKIM and DMARC deployment<\/a>.<\/p>\n\n\n\n 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 \u201cspf=pass.\u201d<\/p>\n\n\n\n Of course, it can be easy to incorrectly deploy the SPF, so if any issues are encountered, the organization should check for:<\/p>\n\n\n\n Email authentication vendors such as dmarcian<\/a> will offer free tools that can provide a quick analysis of the SPF record and help an organization to troubleshoot issues.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019s mail server. This will help to protect the reputation of the company by blocking spam emails trying to use the organization\u2019s brand. Additionally, it can block phishing attacks attempting to spoof the organization\u2019s own employees \u2014 such as when a phishing attack attempts to impersonate the CEO.<\/p>\n\n\n\n When an organization does not establish an SPF, email servers that receive the organization\u2019s emails may flag or reject them because authenticity of the organization\u2019s domain cannot be verified. Establishing an SPF improves the reputation of the organization\u2019s domain and improves the deliverability rate of legitimate emails.<\/p>\n\n\n\n SPF provides protection against spam, spoofing, and phishing email and bolsters email security<\/a> worldwide. However, it also suffers from numerous, although more minor, limitations.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n SPF only verifies the sending domain in the email header and does not compare against the \u201cfrom\u201d 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\u2019s reputation and validated emails.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019t higher than 50%<\/a>.<\/p>\n\n\n\n SPF can be adopted by any organization \u2014 even malicious actors and spammers. Since a SPF check does not include the \u201cFrom\u201d 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 \u201cFrom\u201d field visible through the email program.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n![\"eSP:](\"https:\/\/www.esecurityplanet.com\/wp-content\/uploads\/2023\/06\/eSP-SPF-1024x793.png\")
SPF Fundamentals<\/h3>\n\n\n\n
Basic SPF File Structure<\/h4>\n\n\n\n
SPF File Options<\/h4>\n\n\n\n
<version> <IP4 and\/or IP6 address> <include: domain> <all tag><\/pre>\n\n\n\n
\n
\n
\n
\n
Related Email Standards<\/h3>\n\n\n\n
How to Set Up SPF<\/h2>\n\n\n\n
\n
Verifying and Troubleshooting SPF<\/h3>\n\n\n\n
\n
SPF Advantages<\/h2>\n\n\n\n
Impersonation Mitigation<\/h3>\n\n\n\n
Improved Domain Reputation<\/h3>\n\n\n\n
Limitations of Sender Policy Framework<\/h2>\n\n\n\n
Challenging to Maintain<\/h3>\n\n\n\n
Breakable via Improper Email Forwarding<\/h3>\n\n\n\n
Incomplete Solution<\/h3>\n\n\n\n
Large Organization Issues<\/h3>\n\n\n\n
Poor ROI Measurements<\/h3>\n\n\n\n
Potentially Spoofable<\/h3>\n\n\n\n
Requires Proper Email Server Settings<\/h3>\n\n\n\n
SPF FAQS:<\/h2>\n\n\n\n
What is a Sender Policy Framework (SPF) record?<\/h3>\n\n\n\n
What is an SPF record check?<\/h3>\n\n\n\n
Bottom Line: SPF – A Critical First Step to Eliminate Phishing<\/h2>\n\n\n\n