Without the Domain Name System, the internet as we know it today would be inconceivable. The system for name resolution itself, is based on DNS records. In these simply structured records in normal text files, a name is stored for each IP address. However, DNS records can do more than this. Also known as resource records, various types of them exist.
Imagine you receive an email from a sender you trust. The address looks real, and yet something isn't quite right. Could it be that the sender address was forged? After all, it's well known that scammers send malware-laden attachments pretending to be from familiar companies in order to abuse the trust of the recipient. This type of scam is called spoofing.
As the recipient, how can you tell whether the email is actually coming from the person who appears to be sending it? One common solution is the Sender Policy Framework (SPF), which allows mail servers to verify the authenticity of sender addresses. You can do this yourself by checking the SPF record. How exactly do you do that?
The problem: Is the sender real?
In theory, checking incoming emails is simple: The inbound mail server knows the domain of the sender. Example: When an email arrives from firstname.lastname@example.org, the recipient can find out the IP address of gmx.com. This address is 126.96.36.199 and is found in the mail header along with the sender's IP address.
However, big companies never use only one mail server. For example, the email provider gmx.com uses over half a dozen different servers. Furthermore, many large providers use specialized email filtering servers (such as mailchannels.com) to prevent spam emails from being sent through their systems. In this case, the recipient will see the IP address of the email filtering server, not that of the actual sender.
The solution: SPF (Sender Policy Framework)
SPF stands for Sender Policy Framework. This method allows mail servers to verify whether an email they receive is actually from the specified host server. This SPF check runs completely automatically in the background without you having to do anything.
Put simply, the SPF determines which mail servers are allowed to send mail for the domain. The mail servers are identified by their name or their IP address.
Example: An email from email@example.com may only be sent via one of the following IP addresses: 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11. These IP addresses are therefore listed in the SPF record for the domain gmx.com. The inbound mail server can then check whether the IP address that it reads in the header of the mail is on this list or not.
The list of authorized mail servers is stored on the domain name server (DNS) of the sending domain (gmx.com in this example) and can be accessed by any inbound mail server.
The SPF record is entered as a DNS record (a TXT record, to be exact) in the domain zone of the DNS (name server) associated with the domain. The record contains a list of IP addresses from which emails from this domain may be sent. It also includes other records, such as records for the email filtering servers that an email must pass through before it reaches the recipient. These “stopping points” are often entered using an include statement. The most common parameters of an SPF record are explained below:
|v||Version of the record; v=SPF1 indicates the currently valid version.|
|ip4||IP address; “IP4” is the name of the most well-known form of the IP address. New IP6 addresses also exist, but they're much less common.|
|-all||All other senders not listed here are unauthorized and should be rejected.|
|include||Indicates additional domains whose SPF record you want to look up.|
There is also a version of -all with a tilde: ~all. It indicates that all other senders are not authorized, but should still be accepted. This "soft fail" qualifier was originally introduced for testing purposes but is now used by various hosting providers.
Example: The SPF record of gmx.com
You can look up SPF records of a domain using tools such as EasyDMARC.
You usually don’t have to write and enter the SPF record manually. Good mail hosting providers offer special tools for this. See our help pages to learn how to create an SPF record for IONOS.
Testing the SPF record
The tool from mxtoolbox is the easiest way to check whether your email is actually verified with an SPF record:
- Send an email to ping.tools.mxtoolbox.com.
- After a short time you’ll receive a reply from firstname.lastname@example.org.
- This email contains a basic response and a link to detailed results.
Note that it can take up to 24 hours for an SPF record to become active. If the SPF record check reports an error, try again the next day.
You can also check the SPF record directly in the sent email:
- Send an email to yourself.
- Open the email and look at the email header or message source information. Depending on the mail client, you can do this from the "View" menu or by right-clicking to open the context menu.
- The SPF record is labeled “Received-SPF.”
You can copy the header into a header analyzer tool to view clearer, more detailed information about the email header.
What are the benefits of the SPF record? Pros and cons
More and more Internet service providers consider SPF records mandatory for security reasons. This means that any email from the inbound mail server that doesn’t have the appropriate authorization is either not delivered at all or delivered with a warning that the email is unsafe.
Easy implementation is the biggest advantage of SPF records: A simple TXT record is all that's needed. It can usually be created automatically by the service provider.
But as important as SPF records are, don’t overestimate their protective capabilities.
- SPF doesn't protect against spoofing. A scammer can display a fake sender name in the email despite SPF.
- SPF doesn’t improve the reputation of the sender. Even a spammer can use SPF.
- SPF doesn’t protect against unauthorized email senders. SPF won’t work if someone sends email through your mail server without authorization.