What is SPF? Sender Policy Framework Explained & How to Configure It

SPF (Sender Policy Framework) is an email security mechanism, defined in RFC 7208 , that aims to mitigate email spoofing attacks, which is a common tactic used in phishing attacks 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).

SPF records are an important part of an email security strategy and can help to protect against email spoofing and safeguard the reputation of the domain. They are commonly validated alongside DKIM signatures and DMARC policies during an external penetration test to identify the potential for email spoofing and to ensure that the SPF record is properly configured.

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.

Verifying your SPF record

Once the record is published, it is worth confirming it is syntactically correct and resolves as expected. DNS lookup tools and online SPF checkers can parse the record, flag syntax errors, and count the number of DNS lookups (the limit is 10, as discussed below).

Sending a test email to a service that returns full email headers is also a useful check. The Authentication-Results header will show whether SPF passed, produced a soft fail, or failed for your sending IP, giving you a real-world view of how recipient servers are evaluating the record before you move to stricter DMARC enforcement.

Common SPF weaknesses and vulnerabilities

During external penetration testing, SPF is checked as part of a broader review of email security configuration. Missing or misconfigured SPF records come up regularly across organisations of all sizes.

The most straightforward finding is no SPF record at all. Without a published record, any SPF validation check returns a neutral result, meaning recipient servers cannot determine whether an email was sent from an authorised server. The domain is effectively unprotected against spoofing from the SPF side.

SPF record misconfigurations

Beyond a missing record, the misconfigurations we see most often in engagements are:

• +all in the record: Occasionally found on older or unmanaged domains, +all instructs receiving servers to accept email from any server as authorised. It completely nullifies SPF. Any domain carrying +all is fully spoofable regardless of what else is in the record.
• DNS lookup limit exceeded: SPF records are limited to 10 DNS lookups. Records that chain multiple include mechanisms, each of which may pull in further records, can breach this limit. When exceeded, the SPF check returns a permerror result, which can cause legitimate email to be rejected or SPF to be ignored entirely. This is a common finding on domains that have accumulated third-party senders over time without auditing the record.
• Legitimate senders omitted: Where a third-party service (a CRM, marketing platform, or transactional email provider) sends on behalf of the domain but is not in the SPF record, emails from that service fail SPF checks. This either causes delivery problems or forces the DMARC policy to remain at p=none to avoid breaking delivery.
• ?all (neutral) in use: Less common than ~all, but found occasionally. ?all makes no assertion about unlisted senders, so SPF contributes nothing to the domain’s email security.
• Deprecated ptr mechanism: ptr performs a reverse DNS lookup and is deprecated in RFC 7208. It adds unnecessary lookups and behaves inconsistently across mail servers. Replace it with ip4, ip6, a, or mx as appropriate.

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.