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.
Series of articles: Sender reputation and email security
Part 1: Authenticated Received Chain (ARC)
Part 2: Sender Policy Framework (SPF)
Part 3: DomainKeys Identified Mail (DKIM)
Part 4: Domain-based Message Authentication, Reporting and Conformance (DMARC)
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
Qualifiers define authorised or unauthorised senders and describe how they are to be handled.
| Qualifier | Code | Description |
|---|---|---|
| + | Pass | The sender is authorised (default), the email will be accepted. |
| – | Fail | The sender is not authorised, the email will not be accepted. |
| ~ | SoftFail | The sender is not authorised but the email will be accepted and marked as spam. |
| ? | Neutral | No evaluation, the email will be accepted. |
Mechanisms
A mechanism returns a match or no match for an IP address. Here is an overview of the most common mechanisms:
| Mechanism | When does the policy apply? |
|---|---|
| all | Always |
| a | If an A (or AAAA) record of the queried (or explicitly specified) domain contains the IP address of the sender. |
| mx | If an MX record of the queried (or explicitly specified) domain contains the IP address of the sender. |
| ip4 | If the specified IPv4 address is the address of the sender or the specified IPv4 subnet contains this address. |
| ip6 | If the specified IPv6 address is the address of the sender or the specified IPv6 subnet contains this address. |
| include | If an additional SPF request to the domain specified in the include statement contains the IP address of the sender. |
| redirect | IP address of the sender legitimised by the SPF record of another domain. |
Example of an SPF record
v=spf1 +mx:netatwork.de +ip4:80.66.20.18 +ip4:80.82.206.0/26 include:spf.protection.outlook.com +a:vwp15685.webpack.hosteurope.de +ip4:193.37.132.2 +ip4:193.37.132.101 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:
- Open the SPF Record Check and enter your domain.
- Send an email to ping@tools.mxtoolbox.com. You will receive a reply with the corresponding result after a short time.
How to create an SPF Record
In our video we show you how to create an SPF Record step-by-step.
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.
