Detailed Guide On SPF Records: A Mail Authentication Standard To Prevent Sender-Address Forgery
Learn what SPF records are in detail.
First introduced in the year 2000, the SPF specification has gone through various changes in the subsequent years. Earlier it was called Sender Permitted Form, which later came to be known as Sender Policy Framework. The IETF, an SPF working group, tried to combine Microsoft’s caller ID proposal SPF. The next attempt involved the classic version of SPF in 2006, which led to the first experimental RFC and the proposed standard SPF in 2014.
Today, email authentication protocols like SPF records have evolved and helped develop the DMARC and DKIM techniques. SPF still assumes a significant role in determining if an email is authentic and DMARC compliant or not.
Table of Contents
SPF Record Breakdown Explained With A Simple SPF Record Example
An SPF record refers to the DNS record which a domain owner needs to add to their DNS zone. They can specify the IP addresses and hostnames authorized for sending emails from a particular domain in the SPF record.
The mail receiver uses the from address of an email (which is the return-path header) for confirming that the sending IP address is authorized to send emails. It happens before the mail receiver downloads the body of the message. If the SPF record does not include the sending email server from a specific domain, the mail receiver will mark the email as suspicious and, consequently, reject it.
Given below is the high-level workflow of the way a mail server checks SPF:
- The sample domain server with an IP address of 184.108.40.206 sends a message FROM email@example.com TO firstname.lastname@example.org.
- The shop.com mail server fetches the TXT type DNS records for zoo.com, searching for the SPF record.
- The shop.com mail server will then compare the 220.127.116.11 IP address against the SPF record parts of zoo.com.
- It will then accept or reject the message depending upon the SPF record’s parts, which it matches.
SPF Record Format
The typical format of defining an SPF record is as follows:
v=spf1 a MX include:spf.sampledomain.com ~all
The above SPF record can be understood in the following two parts:
- Version prefix:
a MX include:spf.sampledomain.com ~all
The version prefix is simple to define. It allows the parsers to know that the particular record is to be used to perform SPF checks. It is crucial because a domain may contain multiple TXT records. The SPF check then moves from left to right through the mechanisms that define different rules for checking the domain’s SPF. The above example has four mechanisms –
a, MX, include:spf.sampledomain.com, and ~all.
Diving Deeper Into The SPF Record Syntax
- The “a” mechanism: The sending IP address that matches the “A” record of the “from” domain will pass the SPF. Suppose a user sends an email from the IP 18.104.22.168 for the domain “sampledomain.com.” The mechanism will pass if the “sampledomain.com” contains an A record, which will return 22.214.171.124.
- The “MX” mechanism: The sending IP address, which matches the MX record of the “from” domain, will pass the SPF check. Every domain hosting emails contains more than one MX record. An MX record defines the email servers to be used when a user relays email. The “MX” mechanism approves these servers automatically.
- The “include” mechanism: From the previous example, the sending IP address, which matches the SPF record of spf.sampledomain.com, will pass the SPF check.
The SPF record syntax can contain the following qualifiers:
- + Pass: The IP address will pass the SPF if it matches the mechanism of this qualifier.
- – Fail: The IP address will fail the SPF if it matches the mechanism of this qualifier.
- ~ SoftFail: The IP address will soft fail the SPF if it matches this qualifier’s mechanism. It means that the host will accept the mail, but it will mark the message as SPF failure.
- ? Neutral: The IP address will neither pass nor fail the SPF if it matches this qualifier’s mechanism.
How Users Can Generate Records For Their Domain Using An SPF Record Generator
Users can create an SPF record for their domain easily with an SPF Record Generator. They can simply
- Enter the domain name for which they want to create the SPF record.
- Then, they need to define the IP addresses which they want to authorize for sending emails.
- Domain owners can then store the SPF record in its TXT form in the server’s DNS zone.
Cases When You Need To Update SPF Record Office 365
Organizations that use Office 365 for collaborating and cloud services already have included the SPF TXT record of Microsoft’s messaging servers in their DNS by default. However, users may need to update their SPF record in certain circumstances, which are
- Previously, Sharepoint Online users had to add a separate SPF record to their custom domains. It is no longer required. They can update their SPF records if they hit the ten lookup limit and receive errors like “too many hops” or “exceeded the lookup limit.”
- If an organization has an Office 365 or Exchange hybrid on-premise environment.
- If you intend to set up advanced mail authentication techniques like DKIM and DMARC.
How To Setup/Modify Godaddy SPF Record?
The primary step is to log in to the GoDaddy dashboard and verify the domain. Next, copy your SPF TXT records. GoDaddy will utilize the include mechanism while you are setting up the SPF record. The following scenario will pass the SPF check and is most commonly used
v=spf1 include:spf.em.secureserver.net ~all
If a user sends an email from the IP address 126.96.36.199 for the domain yourdomain.com, the mechanism will pass if the IP address passes the SPF record, and the domain’s SPF record contains yourdomain.com.
Since GoDaddy allows users to set up only one SPF record per domain, there is no need to worry if you have already set up an SPF record. You can create a GoDaddy SPF record and combine both the records, instead of having two separate SPF records. For example:
v=spf1 include:mycompanydomain.com include: spf.em.secureserver.net ~all
What Doesn’t SPF Record Check?
Although SPF is a robust mail authentication technique, organizations need to be aware of its limitations:
- The “from” header is the one that most clients see as the original sender of the message. SPF validates the “envelope from” and not the “header from” to validate the sending domain.
- SPF fails in case a user chooses to forward emails. In such a scenario, the new sender delivers the message, and the mail will fail the SPF check, which the new destination performs.
- Maintaining SPF is cumbersome because it lacks a reporting mechanism.
An SPF record on your DNS zone file can prevent spammers from spoofing your domain. Though it may have its limitations and may not be 100% effective because not all mail providers perform SPF checks, it is still a recommended mail authentication standard to reduce the number of bounce-backs and preserve your brand reputation.
Join the thousands of organizations that use DuoCircle
Find out how affordable it is for your organization today and be pleasantly surprised.