The Sender Policy Framework (SPF) is an email authentication protocol that specifies email authorization through Domain Name System (DNS) records. When an email is sent through the Simple Mail Transfer Protocol (SMTP), there is no requirement for authorized messages, which means that spammers can forge your domain in their phishing attacks.
However, the SPF protocol — alongside other policies, such as DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting, and Conformance (DMARC) — requires verification of authorized sources to deliver messages from your domain. An SPF check will identify whether the mail server sending the email message is authorized by the domain owner and determine the appropriate action for the recipient server.
This article identifies common risks that result from missing and misconfigured SPF records, as well as actionable tasks to remedy the findings.
What is Sender Policy Framework (SPF)?
The Sender Policy Framework defines the specifications for email authentication that permits email service according to DNS lookup. By setting up your SPF record, you can ensure that only authorized email servers can send messages or forward emails from your domain.
The Internet Engineering Task Force (IETP) defined the Sender Policy Framework in RFC 7208 in 2014, which was later followed by a 2020 update for international communications in RFC 8616. These standards represent a consensus on policies and practices related to web communications over email.
For more on email security, read our blog on What Is Email Security? Best Practices for 2023.
When you implement SPF with your DNS records, you can protect against malicious actors who may attempt to perform email spoofing with your domain. If attackers try to use your domain as the source for their nefarious actions, it will likely be captured by a spam filter that checks the SPF record.
If you do not set up an SPF record, untrustworthy emails from unauthorized sources can be sent to your employees and customers, seemingly from your domain. Because the unauthorized emails appear to come from your domain, your recipients may trust what they receive, which could include malicious links, fake domains, malware payloads, or other information that would put your organization's reputation at risk. While most phishing attempts can be recognized quickly by the sender's fraudulent email, these untrustworthy emails would appear to be legitimate emails sent on behalf of your domain.
If your employees or customers are impacted by fraudulent email deliverability, they will lose trust in your organization. A valid and up-to-date SPF record can help you maintain your domain's reputation and ensure SPF authentication for all messages coming from your mail servers.
Common SPF Risk Findings
If your Sender Policy Framework is not enabled or the configuration includes a syntax error, you'll receive the following notifications in UpGuard BreachSight:
- SPF not enabled
- SPF syntax error
Because SPF prevents fraudulent emails being sent as unauthorized emails from your domain, it is critical to enable SPF with proper configuration settings. Otherwise, spoofing emails with malicious information could be sent to your employees and customers.
BreachSight also performs a check to ensure that your SPF records are configured appropriately for email client filtration. You may be notified about each of the following filter mechanisms:
- SPF policy uses +all
- SPF policy uses ?all
- SPF policy uses ~all
The [.rt-script]+all[.rt-script], [.rt-script]?all[.rt-script], and [.rt-script]~all[.rt-script] configuration settings provide different instructions to the Sender Policy Framework, but each enables mail settings. The [.rt-script]+all[.rt-script] setting indicates that any server can send mail on behalf of the sending domain. The [.rt-script]?all[.rt-script] setting provides a neutral evaluation of sender allowance. The [.rt-script]~all[.rt-script] setting allows the receiving server to determine what to do with the email. Most often, this mechanism instructs that mail from unauthorized senders should route to the recipient's spam folder (known as a soft fail). Each of these settings enables unauthorized senders with varying levels of approval. Because only authorized users should be enabled to send emails from your domain, you should update the SPF record to [.rt-script]-all[.rt-script], which will disable all mail sent from unauthorized senders.
If you have set up your SPF with the PTR (Pointer) mechanism, you will receive the following notification:
- SPF ptr mechanism used
The [.rt-script]ptr[.rt-script] mechanism compares the domain name of the sender's email address to the IP address of the server that sent the email. Not only can this email authentication method be spoofed by a fraudulent DNS record, the [.rt-script]ptr[.rt-script] mechanism is known to be slow and unreliable as is documented in the IETF's RFC 7208 section 5.5.
How UpGuard Can Help
UpGuard BreachSight provides continuous monitoring of your external attack surface, conducting daily checks for cybersecurity risks impacting your specific domain.
To learn more about your particular domain's practices in relation to these SPF findings, log in and access your Risk Profile in BreachSight to search for each finding by name. If you're not a current UpGuard user and you want to review your public-facing assets for these findings and more, sign up for a trial.
How to Resolve Your SPF Findings
You can take quick actions to remedy these SPF-related findings upon notification that your organization could be exploited by these risks. Domain administrators must provide the required information in the DNS [.rt-script]TXT[.rt-script] record to allow specific hostnames as authorized email servers for the sender's domain.
To begin, create an SPF record if you do not already have one set up. You can follow our guide on How to Create an SPF Record when you are ready to add the [.rt-script]TXT[.rt-script] record to the DNS configuration for your domain. You can validate the syntax of your record with an online tool or test email to ensure that it is correct, but note that DNS propagation may take some time. When you test your setup, review the email headers and return path to assess your configuration.
When you create or update your SPF records, you can supply designated sender mechanisms that align to your business needs. Clarify your A record and MX record with the [.rt-script]a[.rt-script] and [.rt-script]mx[.rt-script] specifications. Ensure that you have set the [.rt-script]-all[.rt-script] mechanism and disabled the [.rt-script]ptr[.rt-script] mechanism. The [.rt-script]-all[.rt-script] setting will prevent any delivery of unauthorized mail. If your domain is used to send mail, provide the allowed IP addresses or domain with the include mechanism prior to the -all mechanism as any mechanisms after [.rt-script]-all[.rt-script] are ignored.
In addition to creating an SPF record, you can implement a DMARC policy to monitor the authentication of emails sent from your domain and take action against unauthorized activity.
