What is Sender Policy Framework (SPF)?
Sender Policy Framework (SPF) is a technical standard designed to provide a layer of protection against fraudulent email activities such as spam, spoofing $\text{[forging the sender’s identity]}$, and phishing $\text{[a malicious attempt to acquire sensitive information by disguising as a trustworthy entity]}$. Essentially, SPF is a form of e-mail authentication.
Consider an imaginary situation where a website address is https://sanjibsinha.fun. The site owner uses several email addresses for various purposes, such as receiving customer replies or sending newsletters. One of these addresses is support@sanjibsinha.fun.
If the SPF configuration for this domain is not correctly implemented—that is, if the regulated technical standard is not maintained—a malicious third party could easily send emails impersonating the legitimate address, $\text{support@sanjibsinha.fun}$. This process of exploiting weak SPF records is referred to as “poisoning” the web application’s SPF. The goal of this analysis is to understand how this can be done and, more importantly, how to protect against it.
Therefore, SPF is formally defined as a mechanism to validate that an e-mail message is sent from an authorized mail server. It is mandatory for every web application to have strong SPF records in order to detect forgery and spam. The basic protocol used for sending email, SMTP (Simple Mail Transfer Protocol), does not include any authentication mechanism by default. For this crucial reason, SPF is designed to supplement SMTP.
The importance of this issue has been recognized by the Internet Engineering Task Force (IETF), which published a detailed technical report in a Request for Comments (RFC) document. You can keep yourself updated on the standard by referring to this link: https://tools.ietf.org/html/rfc7208.
Implementing and Testing SPF Records
SPF is fundamentally a representation of a Domain Name Service (DNS) record. It specifically identifies which mail servers are permitted to send email on behalf of your domain, utilizing IP addresses for identification. The SPF record is included in an organization’s DNS database as a specially formatted DNS text record (TXT record). There are simple steps that can help you write the SPF entries for your clients.
Steps to Create an SPF Record
- Identify authorized mail servers: The first step to implement SPF is to identify which mail servers the domain will use to send email.
- List sending domains: Next, a complete list of all sending domains must be compiled.
- Create the SPF record: The process of creating the record itself is relatively simple.
An SPF record always starts with a v=spf1 (version 1) tag and is followed by the IP addresses of authorized senders and specific directives.
For example, the DNS text record of a domain like https://sanjibsinha.fun might look like this:
v=spf1 +a +mx +ip4:94.130.19.124 ~all
Since the SPF record is published in DNS as a text record, the hosting provider is able to validate it.
Testing for Spoofing Vulnerability
To test for vulnerability, one can try to send an email to $\text{support@sanjibsinha.fun}$ using any fake mailer service like Emkei.cz or sendanonymousemail.net.
If this mission is unsuccessful (i.e., the email is undelivered to the inbox despite the fake mailer displaying a message like “Thank you, your message has been sent”), it is because the SPF record of https://sanjibsinha.fun has been set in accordance with the technical standard. The email stays undelivered if your SPF record maintains the correct technical standard, as the receiving server will reject mail from an unauthorized source.
Therefore, one can conclude that there are sufficient SPF records in the tested website, https://sanjibsinha.fun. However, it is essential to check whether any other vulnerabilities or limitations exist in that SPF record.
Examining the Vulnerabilities and Limitations of SPF
Although SPF is the fundamental technical standard for mail server authentication, the question remains: Is it enough to protect your emails from all forms of spoofing or phishing? There are indeed some limitations that security professionals need to be aware of.
The Problem with the ‘From’ Header
Crucially, SPF does not validate the From header, even though this is the header that is shown in most email clients as the actual sender of the message. Instead of validating the From header, it uses the envelope from to determine the sending domain.
The envelope from is essentially the return address. It tells receiving mail servers where to return, or bounce, the message back to if it fails to deliver. This is contained within the hidden email message header, which includes technical details that servers use to determine the recipient, the software used, and other technical details.
SPF and Email Forwarding
SPF may also break when an email is forwarded. This is because each forwarder becomes the new sender of the message. At this point, the SPF checks performed by the new destination server may fail the technical standard, even though the original email was legitimate.
The Role of DMARC
In this scenario, DMARC $\text{[Domain-based Message Authentication Reporting and Conformance]}$ plays a vital role. DMARC is an email validation system designed to protect any web application’s email domain from being used for email spoofing or phishing.
Since SPF lacks any mechanism for reporting, DMARC adds that major function. Domain owners publish a DMARC record in their DNS, which helps them gain insight into who is sending email on behalf of their domain and what actions the recipient server should take (e.g., quarantine, reject) if a message fails authentication checks (SPF and/or DKIM).
Your clients will always want to ensure one thing: their customers will receive emails that only they have sent—not any malicious actor who uses a fake mailer to send emails anonymously.
The Threat Landscape
According to a report by DMARC Analyzer, spear phishing $\text{[highly targeted phishing attacks]}$ attacks were rampant until 2016 and continue to be a significant threat. You can visit https://www.dmarcanalyzer.com for more information, or search about “phishing attacks.” Overall, this type of attack is aggressively rampant.
If website or domain owners had been more conscious and adhered to technical standards like DMARC, it would have curtailed the crime a little bit. The list from the report is quite long, highlighting the severity of the problem:
- 70% of all global emails are malicious.
- The volume of spam emails increased 4× in 2016.
- 9 out of 10 phishing emails contained some form of ransomware in March 2016.
- 78% of people claim to be aware of the risks of unknown links in emails. And yet they click anyway.
- In the year 2016, more than 400,000 phishing sites were observed each month on average.
- 30% of phishing emails get opened.
Verification and Reporting for Clients
As a security professional or a pen tester, it is your responsibility to examine your client’s domain and verify that they have an SPF record. To do this, you can validate the record through specialized websites.
Two popular validation tools are:
Using Kitterman’s SPF Validator
Testing https://sanjibsinha.fun on http://www.kitterman.com/spf/validate.html provides the following detailed report:
SPF record lookup and validation for: sanjibsinha.fun
SPF records are published in DNS as TXT records.
The TXT records found for your domain are:
v=spf1 +a +mx +ip4:94.130.19.124 ~all
Checking to see if there is a valid SPF record.
Found v=spf1 record for sanjibsinha.fun:
v=spf1 +a +mx +ip4:94.130.19.124 ~all
evaluating...
SPF record passed validation test with pySPF (Python SPF library)!
Use the back button on your browser to return to the SPF
checking tool without clearing the form.
The validation test indicates that the SPF record is valid and properly formatted.
Using MX Toolbox for a Comprehensive Check
Simultaneously, inspecting the domain on https://mxtoolbox.com (specifically the SPF record lookup tool) reveals the published record:
The tool confirms that https://sanjibsinha.fun has a proper SPF record, which looks like this:
v=spf1 +a +mx +ip4:94.130.19.124 ~all
However, upon further examination, potential problems become apparent in other related areas, specifically regarding DMARC records.
The report from https://mxtoolbox.com shows that it has not found any DMARC record. Furthermore, it has not found any DNS record in the DMARC zone. Security professionals should always include these images and findings in their reports.
The critical takeaway for any report to a client is that a website owner should know for sure that all their visitors or customers will only see emails that they have sent. Therefore, the DMARC record is a must for every domain owner. Securing email with DMARC is important, because it gives email recipients confidence that an email seemingly originating from your websites is legitimate.
Command Line Tools for Linux Users
Finally, for readers acquainted with Linux commands, there are command line tools available that can be used to show and verify current SPF records. For example, the compare.sh script can be used for verification. You can download these SPF command tools from the official repository: https://github.com/spf-tools/spf-tools.