Hackers like to fake malicious email on domains they don’t have to carry out their evil schemes. A great way to respond to spammers is to announce the email servers, IP addresses, and domains that are authorized to send mail on behalf of that domain. Implementing the Sender Policy Framework protocol by creating an SPF record is a great way to start a resistance.
This tutorial introduces basic SPF concepts, including the syntax of an SPF record, and demonstrates how to create an SPF record. Examples of SPF records are also included, as well as instructions on how to add an SPF record to the DNS by creating a new DNS TXT record.
What is SPF and how does it work?
SPF is one of three email authentication protocols that work together to protect against email spoofing, spam, and phishing by giving email senders a set of tools to accomplish the following:
- Determine the host name, domain, or IP address of servers authorized to send mail to a domain using SPF records;
- authentication of digitally signed messages, using public keys stored in Domain Key Identified (DKIM) mail records; And the
- Notify receiving email servers how to process email from a domain when they fail to authenticate, using Domain-Based Message Authentication, Reporting and Conformance (DMARC).
These email authentication protocols use DNS records to store information about email services provided by the domain owner:
- DKIM records include a public key that is used to authenticate email that has been digitally signed using the protocol.
- DMARC records include instructions for organizations receiving email to indicate what steps they should take when receiving unauthenticated email.
- SPF logs include instructions on how to determine which valid IP addresses and which domains and subdomains are authorized to send e-mail on behalf of the domain specified in the e-mail header.
SPF and its sibling protocols rely on the use of DNS to distribute the information an email receiver needs in order to authenticate incoming email without affecting email deliverability. These protocols work by having the email sending organization create DNS TXT records to publish rules to authenticate email generated from domain owners. Knowing how to add a DNS TXT record is a big part of creating any SPF, DKIM, or DMARC record.
All organizations that send email to their own domain can benefit from creating records in the DNS that recipients can use to validate the email. The process for creating DNS records varies depending on whether the mail is sent by your email service provider, hosting provider, ISP, or another third-party mail server sending email on behalf of the organization’s domain. The process of creating a new SPF record can also be complicated depending on the email infrastructure of the domain owner.
SPF TXT records contain the IP addresses and domain names of mail servers that are authorized to send mail to the associated domain. Email receiving servers check the SPF system to determine if the email was originated from an authorized IP address, domain, or subdomain and to use this information to determine whether to deliver the email.
SPF record structure
The SPF syntax, as defined in Internet Engineering Task Force RFC 7208, defines three components in SPF records: mechanisms, identifiers, and modifiers.
Mechanisms are techniques that SPF can use to verify that a specific domain is authorized to send email. It is said that there is a mechanism that matches if some specific condition is met. Depending on the mechanism, matching means that the message can be validated. SPF mechanisms include:
- Fifth The SPF version used in the registry. This mechanism is required and must appear at the beginning of the log. The only valid value for this mechanism is v = spf1 – For SPF version 1. This mechanism must match all messages.
- All It is the mechanism for identifying all incoming messages. Although not required, the recommendation is to include this mechanism in all SPF records – as a last resort – because it provides a default mechanism to match any incoming messages that are not explicitly authenticated.
- a, or address, is the mechanism for determining the address used by authorized servers. “A” stands for DNS A or address record type. This mechanism specifies that all IP address records for the specified domain should be tested. If the source IP address of the mail server is found in any of the address records, the mechanism will match.
- IP4 Indicates the IPv4 network address. This mechanism can be specified as a network range when the address is provided with a prefix length to specify the subnet, or as a single IPv4 address when specified without the prefix length.
- IP6 Indicates an IPv6 network address, which can be specified as a network range when the address is provided with a prefix length to specify the subnet or when specified without the prefix length to refer to a host at a specified IPv6 address.
- MX Indicates DNS MX, or mail exchange record type. This mechanism is used to select a domain or subdomain, and the receiving mail server processes this mechanism by querying all address records for that domain or subdomain. This mechanism matches when the MX records contain the same domain used to send the message.
- PT Indicates a DNS PTR or pointer record type. The mechanism is slow and unreliable, and it can also stress DNS because it requires a relatively large number of DNS queries. While still listed in the SPF specification, it is recommended Not to use it for these reasons.
- EXISTS Specifies a domain, and the receiving mail server queries the DNS for address records for that domain. With any result – if one or more address records are found – this mechanism matches, regardless of the address. This mechanism is used for special purposes, including reverse IP lookups and setting exceptions for specific users.
- included It is a recursive matching mechanism. This mechanism is specified by a queried scope of the SPF record. If the domain does not contain an SPF record, the mechanism is returned fail. If this field contains an SPF record, the receiving server processes that SPF record, and if it matches, the mechanism returns pass.
Qualifiers are prefixes that can optionally be added to mechanisms to specify what happens when the receiving email server matches the mechanism:
- +or pass, indicates that matching this mechanism means that the email goes through authentication.
- –or severe failure, indicates that matching this mechanism means email authentication has failed.
- ~or a minor failure, indicates that the matching of this mechanism may fail authentication and should be treated as suspicious.
- ?, or neutral, indicates that matching this mechanism means that the SPF record does not pass or fail the message and has no information available to validate the sender. Mail that matches this mechanism is accepted.
For example, the mechanism is listed as -All It means that all mail from the domain must be rejected. The mechanism matches every message from the domain, and the qualifier – severe failure – means that those matches mean the message should be considered unauthorized.
Modifiers are an optional plug-in for SPF records that provide additional information but do not change the way messages are authenticated. The two valid SPF specific modifiers are as follows:
- Redirect modifiers Include the valid SPF domain that should be queried for the incoming message. When the receiving email server sees this modifier in the SPF record of a message, the server must perform a DNS lookup for the domain in the redirect modifier.
- exp rates Include the domain that must be queried to receive an explanation for why the server rejected the message.
SPF records are generally text-only, and components are separated by spaces. The default qualifier is SUCCESS, so SPF records can be succinct. Mechanisms with parameters such as domains or IP addresses are entered in the SPF record after the name of the mechanism and a colon, for example:
v=spf1 a:example.com -all
NB: a or the address mechanism used herein, A: example.com, lists the domain to query for addresses that match the address of the sending email server. More examples of SPF records follow.
Examples of SPF Records
A simple SPF record looks like this:
v=spf1 -all
In this case, the SPF log message is: There is no authorized source of email from this domain. This is the recommended SPF record for unsent domains; This literally means that all emails should be rejected. Two mechanisms are used, v = spf1 version and All A mechanism, which, by default, always allows any domains that were not otherwise excluded by the previous rules. ALL is only used at the end of the SPF record for this reason. In practice, the protocol ignores any ALL tracking mechanisms in the SPF record.
A more useful example looks like this:
v=spf1 mx:mail.example.org -all
In this case, the first mechanism is mixwhich by default allows mail from the domain’s DNS MX record mail.example.org. Hyphenation qualification used with the collector -All A mechanism that means that any mail that fails to match the sending domain’s DNS MX record must be treated as a failure.
Another common example that relies on DNS to enable a domain owner to point to a different domain looks like this:
v=spf1 include:spf.protection.outlook.com -all
In this case, the included A mechanism is used to add an SPF record for users of custom domains in Microsoft Office 365 (spf.protection.outlook.com).
Domain owners who use Google Workspace for their email might use a record that looks like this:
v=spf1
ip4: 198.51.100.0/24
include:_spf.google.com
include:mailservice.example.net
~all
Taking this log one line at a time, the mechanisms are explained in the following table:
| SPF log line | Notes |
|
v = spf1 |
SPF version 1 |
|
ip4: 198.51.100.0/24 |
It is allowed to send email from an email server in the IP address range from 198.51.100.1 to 198.51.100.255. |
|
Include: _spf.google.com |
Recursively match the SPF record stored in the named DNS TXT record _spf.google.com. This is where Google stores its customers’ SPF history in Google Workspace. |
|
Include: mailservice.example.net |
Recursively match the SPF record stored in the named DNS TXT record mailservice.example.net. This is a name referring to an SPF record published by your mail service provider. |
|
~ all |
Anything else that doesn’t match the above mechanisms should be treated as a minor failure and sent to your junk mail or spam folder. |
In this example, the domain owner authorizes email sent from servers on their IP network: 198.51.100.0/24 Indicates a network address 198.51.100.xxx and any host with an IP address on that network. Email from any other IP address range must be frequently matched against Google’s SPF record (_spf.google.com) and an SPF record associated with the domain owner’s email service provider (mailservice.example.net).
Incoming email that doesn’t match any of these mechanisms – an IPv4 address, a Google Workspace SPF record, and an SPF record provided by your email service provider – should be considered suspicious and delivered to the recipient’s spam folder.
These examples of SPF records are best used as starting points for developing a deployment strategy that includes coordination with email service providers, domain service providers, domain administrators, and employees within the organization who manage email systems.
How to add an SPF record
Once configured, the SPF record must be published as a DNS TXT record. This is not an action to be taken lightly – adding a DNS record affects how the domain is used by the entire Internet.
DNS TXT records are commonly added using the DNS service provider’s web portal or application. The process may be as simple as selecting a file add record option from the drop-down menu and then enter the registry components.
Domain management for enterprises and other large organizations may be managed by IT and network professionals using Microsoft’s Active Directory to add DNS TXT records to enterprise DNS servers, but changes to the public distribution still have to be propagated over the Internet by the domain’s DNS service provider.