Sender Policy Framework (SPF)

Sender Policy Framework (SPF) is an email authentication method designed to prevent the forging of an email address during email delivery. It works by verifying that the email is sent from a server authorized by the domain owner. The goal of this article is to give a complete overview of what an SPF record is and how it works.

How SPF Works

When an email is sent, the receiving mail server checks the DNS record of the domain found in the envelope from (return-path) to see if the IP address of the sender is authorized to send emails on behalf of that domain. This list of authorized IP addresses is defined in the DNS record of the domain as an SPF record.

SPF Record

An SPF record is a DNS TXT record that lists all IP addresses that are authorized to send emails on behalf of your domain. Here is an example of an SPF record:

v=spf1 ip4: ip4: a -all

This record indicates that the IP addresses in the ranges to and the IP address are permitted to send emails for the domain. The “a” mechanism allows the domain’s A record IPs to send mail. The “-all” mechanism indicates that no other servers are allowed to send emails.

SPF Syntax guide

Now that we know what an SPF record is, let us now talk about the different parts of the SPF syntax. An SPF record will always start with the following:


The SPF record would then be proceeded by what is called an SPF “mechanism”. See the list of available mechanisms in the drop-down below:

SPF Mechanisms
Mechanism Definition
All This mechanism always matches. It usually goes at the end of the SPF record.
ip4: The parameter for the "ip4: " mechanism represents an IPv4 network range. In the absence of a specified prefix length, it is assumed to be /32, isolating a single host address.
ip6: The parameter for the "ip6: " mechanism denotes an IPv6 network range. If no prefix length is provided, it is assumed to be /128, isolating a single host address.
a All the A records associated with the domain get tested. If the client IP is present in any of these records, this mechanism becomes a match. In case the connection is established over IPv6, an AAAA lookup is carried out instead.
mx All the A records for each MX record of the domain are sequentially tested based on their MX priority. If the client IP is discovered within any of these records, this mechanism is considered a match.
ptr PTR queries are utilized to perform hostname lookups for the client IP or IPs. Subsequently, the obtained hostnames undergo validation: among them, at least one of the A records for a PTR hostname must correspond to the original client IP. Invalid hostnames are disregarded. If a valid hostname concludes with the specified domain, this mechanism is considered a match.
exists An A query will be executed on the provided domain. If any result is obtained, regardless of its content (e.g., it could be, it will be considered a match.
include: A search is performed to find a match for the specified domain. If the lookup does not produce a match or encounters an error, processing advances to the next directive. It is important to note that a PermError occurs if the domain does not possess a valid SPF record. As a consequence, certain mail receivers may reject messages based on this permanent error condition.

The most commonly used Mechanisms are going to the following:

  • all
  • a
  • mx
  • include
  • ip4

Once you have determined the Mechanisms that you want to use, you will need to determine which “Qualifiers” you will want to use with each mechanism that you use.

A qualifier is a prefix that you would add to the beginning

Qualifier Result
+ Pass
- Fail
~ SoftFail
? Neutral

The default qualifier is “Pass”, this means that if you do not prefix the mechanism with a qualifier the pass qualifier will be used.

Here is an example of how these Qualifiers can be used:

v=spf1 +ip4: ~all

What this example is telling us if your domain’s emails are sent from then they pass. However, if the emails were to send from anywhere else, they would receive a soft fail due to (~all).

A soft fail can be useful when testing your SPF record as a soft fail will generally result in a lesser spam score than a Hard fail (-all).

Once you have gotten your SPF record set in your DNS, you can use the SPF lookup tool below to test your SPF record:

SPF Evalution results

When a recipient server performs an SPF check as part of its Spam filtering, one of the following results can occur:

Result Explanation Intended action
Pass The SPF record designates the host to be allowed to send accept
Fail The SPF record has designated the host as NOT being allowed to send reject
SoftFail The SPF record has designated the host as NOT being allowed to send but is in transition accept but mark
Neutral The SPF record specifies explicitly that nothing can be said about validity accept
None The domain does not have an SPF record or the SPF record does not evaluate to a result accept
PermError A permanent error has occured (eg. badly formatted SPF record) unspecified
TempError A transient error has occured accept or reject

If you have any questions or encounter issues, please don’t hesitate to reach out to [email protected].