• Sender Policy Framework SPF

Sender Reputation and Email Security – Part 2: Sender Policy Framework (SPF)

How can you know that the emails you have received today really originate from the specified senders? In other words: that the emails are authentic and that the senders indicated in the email client are the real senders?

Emails are a bit like letters – you can write whatever you want on the envelope and on the letterhead with a bit of trickery. With emails, trickery is even particularly easy. And cyber criminals exploit this shamelessly: Emails sent using fake sender addresses, for example, are a popular way to distribute attachments contaminated with Trojans and other malware.

What is SPF?

SPF, DKIM, DMARC and ARC are essential technologies for the detection of fake sender domains as well as for the defence against phishing attacks. Part 2 of our series of articles on sender reputation focuses on a method to authorise specific IP addresses to send emails: Sender Policy Framework (SPF) is a simple and effective method to prevent the misuse of sender domains.

How to specify legitimate IP addresses with SPF

An email always has two sender addresses:

Envelope Sender

The envelope sender is the address that is passed as the MAIL FROM: parameter and is ultimately relevant for the transport. It is usually not displayed in email clients.

Header From

The Header From is the address that is visible in the email client as the sender. It is comparable to the sender on the letterhead.

The problem arises when criminals try to send phishing emails via a fake ‘MAIL FROM’ address. This is exactly where Sender Policy Framework (SPF) comes into play.

How does Sender Policy Framework (SPF) work?

In the SPF record, the owner of a domain specifies in the Domain Name System (DNS) all IP addresses of the Mail Transfer Agents (MTAs), i.e. the servers that are allowed to send emails in the name of that domain. To do this, he or she creates a so-called SPF record in the corresponding DNS zone. Technically, this is a TXT record whose syntax is exactly specified in RFC7208.

The receiving server then checks which domain is specified in the ‘MAIL FROM’ address and determines by means of a DNS query whether an SPF record exists for the domain. If this is the case, it retrieves the information and compares the IP address of the sending MTA with the permitted addresses. If the IP address of the sending MTA does not appear in the SPF record of the domain, it is not authorised to send emails on behalf of this domain.

What does an SPF entry look like?

As already mentioned, an SPF entry is a simple TXT file. All SPF entries start with the version number. Currently, the corresponding specification is v=spf1. The expressions that follow are processed from front to back. Most of these expressions are so-called directives that make a statement about the authorisation of a sender. They describe whether the respective sender is authorised to send the email.


Qualifiers define authorised or unauthorised senders and describe how they are to be handled.

+PassThe sender is authorised (default), the email will be accepted.
FailThe sender is not authorised, the email will not be accepted.
~SoftFailThe sender is not authorised but the email will be accepted and marked as spam.
?NeutralNo evaluation, the email will be accepted.


A mechanism returns a match or no match for an IP address. Here is an overview of the most common mechanisms:

MechanismWhen does the policy apply?
aIf an A (or AAAA) record of the queried (or explicitly specified) domain contains the IP address of the sender.
mxIf an MX record of the queried (or explicitly specified) domain contains the IP address of the sender.
ip4If the specified IPv4 address is the address of the sender or the specified IPv4 subnet contains this address.
ip6If the specified IPv6 address is the address of the sender or the specified IPv6 subnet contains this address.
includeIf an additional SPF request to the domain specified in the include statement contains the IP address of the sender.
redirectIP address of the sender legitimised by the SPF record of another domain.

Example of an SPF record

v=spf1 +mx:netatwork.de +ip4: +ip4: include:spf.protection.outlook.com +a:vwp15685.webpack.hosteurope.de +ip4: +ip4: include:customers.clickdimensions.com -all

In this example, different mechanisms are used to legitimise IP addresses for sending:

mx: IP addresses listed in the corresponding MX record are allowed to send emails.
ip4: IP addresses explicitly named here are allowed to send emails.
a: Servers hosting the websites with the specified domains are allowed to send emails.
include: Additional domains whose SPF entries are included.
-all: All IP addresses not named here are NOT allowed to send!

How to check your SPF record

With the help of tools such as mxtoolbox, you can quickly and easily check whether there is an SPF record for your domain. You have two options to do this:

How to create an SPF Record

In our video we show you how to create an SPF Record step-by-step.


By loading the video, you agree to YouTube's privacy policy.
Learn more

Load video

Should I use SPF?

Yes, but the sole use of SPF records to protect one’s own domain and to check inbound emails is only helpful to a limited extent. If SPF alone is used, the email administrator must keep an eye on all changes to his infrastructure, because the SPF record must always be up-to-date. This includes not only the email servers responsible for sending, but also the associated IP addresses.

In addition, servers that are not in one’s own network and for which there is normally no authorisation must also be taken into account. This applies above all to newsletter delivery services or other services via which emails are redirected. However, reputable providers always offer their customers an ‘include’, which legitimises the corresponding MTA. But problems can also arise with redirections if the ‘MAIL FROM’ address contains the original domain, but the email was sent via a different IP address.

Without comprehensive monitoring of the infrastructure used, this can quickly lead to errors in the SPF check, because the server processing the email is usually not listed in the SPF record of the original sender domain.

The problem of redirection and forwarding is mitigated by the use of other technologies such as ARC, DKIM and DMARC, which we also highlight in this series of articles.

What SPF does not do

SPF is an easy-to-implement means to prevent domain abuse and is increasingly adopted and even required. Nevertheless, the impact of SPF on email security is limited:

  • SPF does not protect against forgery of the header-from address, i.e. spoofing of the sender address displayed by the email client.
  • Spammers might also use SPF.
  • SPF does not help if someone sends unauthorised emails via your email server.

Improve your email security with NoSpamProxy and SPF

NoSpamProxy consistently evaluates SPF entries and adjusts the Level of Trust score accordingly if the sending MTA is not listed in the respective SPF entry of the sender. If an email cannot be authenticated based on the SPF entry, no Level of Trust points are awarded – this only happens if the sender address of the email can be authenticated at least by a valid SPF entry or other criteria. A valid SPF entry thus improves the reputation rating by NoSpamProxy.

SPF is an important building block for improving email hygiene, but should always be accompanied by DKIM, DMARC and ARC.