Secure Your Email with SPF (Sender Policy Framework)

What is SPF?

SPF (Sender Policy Framework) is an email security mechanism that aims to mitigate email spoofing attacks, which is a common tactic used in phishing and spam campaigns. This allows domain owners to specify authorised mail servers that are permitted to send emails on behalf of their domain by publishing an SPF record in the DNS settings for the domain.

An SPF record is a TXT record that contains a list of IP addresses and hostnames that are allowed to send emails from that domain. When an email is received, the recipient’s mail server checks the SPF record for the sender’s domain to verify if the email was sent from an authorised server.

If the email fails the SPF check, it may be marked as spam or rejected outright, depending on the recipient’s email server configuration (see our article on DMARC for more information on how SPF works with DMARC).

Why is SPF Important?

SPF is one of the key components when securing email communications and protecting against email-based attacks. When coupled with DMARC and DKIM, it provides a well-rounded approach to email security.

By implementing SPF, domain owners can:

• Prevent Email Spoofing: By specifying which mail servers are authorised to send emails on behalf of their domain, SPF helps to prevent attackers from sending fraudulent emails that appear to come from a legitimate source.
• Improve Email Deliverability: Emails that pass SPF checks with DMARC and DKIM are more likely to be delivered to the recipient’s inbox, rather than being marked as spam or junk.
• Protect Domain Reputation: By preventing email spoofing, SPF helps to protect the reputation of the domain, which is important for maintaining trust with customers and other email recipients.

How Does Sender Policy Framework (SPF) Work?

SPF works by having the domain owner publish a DNS TXT record that specifies the authorised mail servers for the domain (or subdomain). The SPF record contains a list of IP addresses, hostnames (or a further record that includes a group of authorised senders) that are allowed to send emails from that domain.

When an email is received, the recipient’s mail server checks the SPF record for the sender’s domain to verify if the email was sent from an authorised server. This is done by performing a DNS lookup for the SPF record and comparing the IP address of the sending mail server against the list of authorised servers in the SPF record.

If the email passes the SPF check, it is delivered to the recipient’s inbox. If it fails the SPF check, it may be marked as spam or rejected outright, depending on the recipient’s email server configuration.

A basic example of an SPF record might look like this:

v=spf1 ip4:1.2.3.4 include:thirdparty.com ~all

In this example:

• v=spf1 indicates that this is an SPF version 1 record.
• ip4:... specifies that the IP address provided is authorised to send emails for the domain.
• include:... specifies that any IP addresses listed in the SPF record for thirdparty.com are also authorised to send emails for this domain.
• ~all indicates that any server not listed in the SPF record should be treated as a soft fail (i.e., marked as suspicious but not rejected outright).

Setting Up and Configuring an SPF Record

With SPF there are several main configuration options that can be used to define which mail servers are authorised to send emails on behalf of the domain.

The following table outlines the common options used in an SPF record:

Understanding the all Mechanism

Over the years there have been different interpretations of how the all mechanism should be used in an SPF record. The all mechanism is used to specify how to handle emails from servers that are not listed in the SPF record.

• -all (Hard Fail): This indicates that any server not listed in the SPF record is not authorised to send emails for the domain. Emails that fail this check should be rejected outright. This is the strictest option and is recommended for domains that want to enforce a strong SPF policy.
• ~all (Soft Fail): This indicates that any server not listed in the SPF record is not authorised to send emails for the domain, but emails that fail this check should be marked as suspicious rather than rejected outright. This option is less strict than -all and is often used during the initial implementation of SPF to monitor for any issues.
• ?all (Neutral): This indicates that the domain owner is not making any specific assertion about the authorisation of servers not listed in the SPF record. Emails that fail this check should be treated as neutral and not marked as spam or rejected outright. This option is the least strict and is not recommended for production use.
• +all (Pass): This indicates that all servers are authorised to send emails for the domain. This option effectively disables SPF and is not recommended.

In general, it is recommended to use either -all or ~all depending on the desired level of strictness for the SPF policy.

For the most part, if you have implemented a strong DMARC policy alongside DKIM, then utilising ~all is a good option to start with, and then move to -all once you are confident that all legitimate senders are included in the SPF record.

Best Practices for SPF Implementation

There are ultimately two options that could be used within an SPF record to define how to handle emails from unauthorised servers: -all (hard fail) or ~all (soft fail). It is highly recommended to not use ?all (neutral) or +all (pass), as these options do not provide any meaningful protection against email spoofing.

When configuring the authorised mail servers, it is not recommended to use IP addresses for two reasons:

1. If you do not have a static IP address, your SPF record will need to be updated whenever your IP address changes.
2. Including the IP address potentially could lead to an unintended disclosure of your infrastructure details (this may be acceptable for the most part, but in some cases if you have a back-end server that is not intended to be publicly accessible, it could be a risk).

Instead, utilise the a or mx mechanisms to authorise the IP addresses associated with your domain’s A/AAAA or MX records.

When using third-party email services (e.g., CRMs, hosted websites, etc.), ensure that you include their SPF records using the include mechanism. This ensures that emails sent from these services on behalf of your domain are properly authorised. Often, these services will provide guidance on how to include their SPF records.

Regularly audit and review your SPF record to ensure that it does not include legacy or unused senders to minimise the risk of unauthorised email sending.

Finally, monitor your email deliverability and SPF reports (if using DMARC) to identify any issues or unauthorised email sending attempts.

Common SPF Weaknesses and Vulnerabilities

First and foremost, if an SPF record is not published at all, then any SPF validation checks will essentially show as a neutral result, which means that the recipient’s mail server will not be able to determine if the email was sent from an authorised server or not. This can leave the domain vulnerable to email spoofing attacks.

SPF Record Misconfigurations

Misconfigurations in the SPF record can lead to legitimate emails being marked as spam or rejected outright. Common misconfigurations include:

• Omitting Legitimate Senders: If a legitimate mail server is not included in the SPF record, emails sent from that server may fail SPF checks and be marked as spam or rejected.
• Using +all or ?all: As mentioned earlier, using these options effectively disables SPF and does not provide any meaningful protection against email spoofing.
• Too Many DNS Lookups: SPF records are limited to 10 DNS lookups. If the SPF record includes too many include, a, mx, or ptr mechanisms, it can exceed this limit and cause SPF checks to fail. An example of this is an include mechanism that includes another include, which can quickly lead to a large number of DNS lookups.
• Incorrect Syntax: Errors in the syntax of the SPF record can lead to it being ignored or misinterpreted by recipient mail servers.
• Using Deprecated Mechanisms: Some mechanisms, such as ptr, are deprecated and should not be used in SPF records.

What SPF Cannot Do

Does Not Encrypt Emails: SPF does not provide any encryption for email messages, so the content of the email can still be intercepted and read by attackers if it is not sent over a secure connection (e.g., TLS).

Does Not Prevent All Types of Email Attacks: SPF is primarily designed to prevent email spoofing, but it does not protect against other types of email attacks, such as phishing or malware.

Requires Proper Configuration: SPF requires proper configuration to be effective. If the SPF record is not set up correctly, it can lead to legitimate emails being marked as spam or rejected, such as if they were sent from a third party that was omitted from the SPF record.

Does Not Guarantee Email Delivery: While SPF can improve email deliverability, it does not guarantee that all emails will be delivered to the recipient’s inbox. Other factors, such as the recipient’s email server configuration and spam filters, can also affect email delivery.

Previous Post What is Cross-Site Scripting? XSS and How to Prevent It

Next Post DMARC Email Security: Protect Your Domain from Spoofing