How to create and add an SPF record for email authentication

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:

• identify the hostname, domain or IP address for servers authorized to send mail for a domain, using SPF records;
• authenticate digitally signed messages, using public keys stored in DomainKeys Identified Mail (DKIM) records; and
• notify email-receiving servers how to process email from a domain when it fails to authenticate, using Domain-based Message Authentication, Reporting and Conformance (DMARC).

These email authentication protocols all use DNS records to store information about email services provided by the domain holder:

• DKIM records include a public key used to authenticate email that has been digitally signed using the protocol.
• DMARC records include instructions for email-receiving organizations to indicate what steps they should take when an unauthenticated email is received.
• SPF records include guidance on how to identify valid IP addresses, domains and subdomains authorized to send email on behalf of the specific domain in the email header.

SPF and its sibling protocols all depend on using DNS to distribute the information email receivers need 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 for authenticating the email originated from the domain owners. Knowing how to add a DNS TXT record is a large part of the process of creating any SPF, DKIM or DMARC record.

All organizations that send email for their own domain can benefit from creating records in DNS that recipients can use for email validation. The process for creating DNS records varies depending on whether mail is sent by an email service provider, a hosting provider, an ISP or some other third-party mail server that sends email on behalf of an organization's domain. The process for creating the new SPF record also may be complicated depending on the domain owner's email infrastructure.

SPF TXT records contain IP addresses and domain names for mail servers that are authorized to send mail for the associated domain. Email-receiving servers do an SPF check to determine whether an email originated from an authorized IP address, domain or subdomain and to use that information to decide whether to deliver the email.

SPF record syntax

SPF syntax, as defined in Internet Engineering Task Force RFC 7208, specifies three components in SPF records: mechanisms, qualifiers and modifiers.

Mechanisms are the techniques SPF can use to verify that a specified domain is authorized to send email. A mechanism is said to match if some identified condition is met. Depending on the mechanism, a match means that the message can be validated. SPF mechanisms include the following:

• v is the version of SPF used in the record. This mechanism is required and must appear at the start of the record. The only valid value for this mechanism is v=spf1 -- for SPF version 1. This mechanism should match all messages.
• ALL is the mechanism to select all inbound messages. While not required, the recommendation is to include this mechanism in all SPF records -- as the last mechanism -- as it provides a default mechanism to match any incoming messages that aren't otherwise explicitly authenticated.
• A, or address, is the mechanism for identifying the address being used by authorized servers. "A" refers to the 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 matches.
• IP4 refers to the IPv4 network address. This mechanism can be specified as a network range when the address is provided with the prefix length to specify subnetting or as a single IPv4 address when specified without the prefix length.
• IP6 refers to the IPv6 network address, which can be specified as a network range when the address is provided with the prefix length to specify subnetting or when specified without the prefix length to reference a host at a specific IPv6 address.
• MX refers to the DNS MX or mail exchange record type. This mechanism is used to specify a domain or subdomain, and the receiving mail server processes this mechanism by querying for all the address records for that domain or subdomain. This mechanism matches when the MX records contain the same domain as used to send the message.
• PTR refers to the DNS PTR or pointer record type. The mechanism is considered slow and unreliable, and it also can stress DNS because it requires a relatively high number of DNS queries. While it is still included in the SPF specification, it is recommended not to use it for those reasons.
• EXISTS specifies a domain, and the receiving mail server queries DNS for address records for that domain. With any result -- if one or more address records are found -- this mechanism matches, no matter what the address is. This mechanism is used for special purposes, including reverse IP lookups and setting up exceptions for specific users.
• INCLUDE is a mechanism for recursive matching. This mechanism is specified with a domain, which is queried for an SPF record. If the domain does not have an SPF record, the mechanism returns fail. If that domain does have 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 a receiving email server matches the mechanism:

• +, or pass, indicates that matching this mechanism means the email passes authentication.
• -, or hard fail, indicates that matching this mechanism means the email fails authentication.
• ~, or soft fail, indicates that matching this mechanism probably fails authentication and should be treated as suspicious.
• ?, or neutral, indicates that matching this mechanism means 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 listed as -all would mean that all mail from the domain should be rejected. The mechanism matches for every incoming message from the domain, and the qualifier -- hard fail -- means that those matches mean the message should be considered unauthorized.

Modifiers are an additional, optional component of SPF records that provide additional information but don't change how messages are authenticated. The two valid modifiers defined for SPF are the following:

1. Redirect modifiers include a domain that should be queried for the valid SPF for the incoming message. When an email-receiving server sees this modifier in the SPF record for a message, the server must do a DNS lookup for the domain in the redirect modifier.
2. Exp modifiers include a domain that should be queried to receive an explanation for the reason a server rejects a message.

SPF records are generally text-only, and components are separated by spaces. The default qualifier is pass, so SPF records can be terse. Mechanisms with parameters like domains or IP addresses are entered in the SPF record after the mechanism name and a colon, for example:

v=spf1 a:example.com -all

Note: The A or address mechanism used here, a:example.com, lists the domain to be queried for addresses to match with the address of the sending email server. More examples of SPF records follow.

Examples of SPF records

A simple type of SPF record looks like this:

v=spf1 -all

In this case, the SPF record's message is: There is no authorized source for email from this domain. This is the recommended SPF record for nonsending domains; it literally means all email should be rejected. Two mechanisms are used, the v=spf1 version and the all mechanism, which, by default, always allows any domains not otherwise ruled out by previous rules. ALL is only used at the end of the SPF record for that reason. In practice, the protocol ignores any mechanisms that follow ALL in an SPF record.

A more useful example looks like this:

v=spf1 mx:mail.example.org -all

In this case, the first mechanism is mx, which, by default, permits mail from the DNS MX record for the domain mail.example.org. The hyphen qualifier used with the catchall -all mechanism means any mail that fails to match the DNS MX record for the sending domain should be processed as failed.

Another common example that relies on DNS to enable the domain owner to reference a different domain looks like this:

v=spf1 include:spf.protection.outlook.com -all

In this case, the include mechanism is used to add the SPF record for users of custom domains in Microsoft Office 365 (spf.protection.outlook.com).

Domain owners using Google Workspace for their email might use a record that looks something like this:

v=spf1
ip4: 198.51.100.0/24
include:_spf.google.com
include:mailservice.example.net
~all

Taking this record one line at a time, mechanisms are explained in the following table:

In this example, the domain owner authorizes email sent from servers located on its own IP network: 198.51.100.0/24 refers to the network address of 198.51.100.xxx and any host with an IP address on that network. Email originating from any other IP address range must be recursively matched through both Google's own SPF record (_spf.google.com) and the SPF record associated with the domain owner's email service provider (mailservice.example.net).

Incoming email that fails to match on any of these mechanisms -- IPv4 address, Google Workspace SPF record and the SPF record provided by the email service provider -- should be considered questionable and delivered to the recipient's spam folder.

It's best to use these examples of SPF records as starting points to develop a deployment strategy that includes coordination with email service providers, domain service providers, domain administrators and staff within the organization who administer email systems.

How to add an SPF record

Once composed, 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 picking the Add Record option from a pull-down menu and then entering the components of the record.

Domain administration for enterprises and other large organizations may be administered by IT and networking professionals using Microsoft's Active Directory service to add DNS TXT records to the enterprise DNS servers, but the changes must still be propagated into general distribution over the internet by the domain's DNS service provider.