SPF Record Syntax Explained

A TXT SPF record includes a list of IP addresses and email servers belonging to an organization, its representatives, and third-party vendors who are officially allowed to send emails on their behalf. SPF records are complicated, and the instructions they impart using syntax should be done as per the rules laid down in RFC 7208 4.6 to ensure there are no errors. SPF records with permerror and other syntax issues fail to prevent phishing attacks.

SPF record syntax is categorized as mechanisms, qualifiers, and modifiers. 

SPF Record Example

This is what a standard SPF record looks like-

v=spf1 include:_spf.google.com include:example.com a:mail.example.com mx ip4:124.163.1.1 ~all

This SPF record authorizes Google’s servers, a specific IP address, and servers listed in the MX and A records of “example.com” to send emails on behalf of the domain. Emails that are sent by anyone outside of the service will be placed in the spam folder (“~all”).

Here, v=spf1 specifies the version 1 used. Since there’s only one SPF version as of now, all SPF records should begin with v=spf1. The ‘include’ tag directs receiving servers to check the included domain’s SPF record for IP addresses permitted to send messages. 

Image sourced from pair.com

SPF Record Advanced Syntax

Sender Policy Framework (SPF) record syntaxes are characterized as a single string of text in the DNS TXT record. It begins with v=spf1 and ends with either ~all or -all tag, specifying softfail or hardfail, respectively. Here’s more information on mechanisms, qualifiers, and modifiers. 

SPF Mechanisms

all

The ‘all’ mechanism has to match always in order to instruct recipient servers how to deal with unauthorized email messages sent from your domain. No mechanism after this is valid and is ignored. By default, it’s set to -all, but you can always change it to ~all or even add the ‘pct’ tag to apply the selected policy to only a predefined percentage of emails. It’s highly discouraged to use the +all tag, as it allows everyone to send messages using your domain name. 

a

It defines a domain name with an A or AAAA address record as a match since it resolves to the sender’s address. When there is no well-defined DNS SPF record syntax, the current domain is used. 

ip4

A successful match is observed for an email if the sender is associated with the given range of IP4-network IP addresses in the SPF TXT record. You have to add it with a prefix-length to tell the range’s length; however, /32 is used as the default prefix. 

ip6

A successful match is observed for an email if the sender is associated with the given range of IPv6 IP addresses in the SPF TXT record. You have to add it with a prefix-length to tell the range’s length; however, /128 is used as the default prefix. 

mx

It specifies that any server listed in the domain’s MX records is authorized to send mail. An MX record contains an IP address and a priority value for every server authorized and responsible for accepting emails. 

ptr

It’s a deprecated mechanism and is the opposite of a DNS A record. It resolves the queried IP address to its corresponding domain name. The mechanism is slow and unreliable, which is why SPF experts strongly discourage its inclusion in an SPF DNS record. 

exists

It performs a DNS A record search, and a successful match is observed when a valid A record is explored, irrespective of what the actual lookup result is. You need to introduce SPF macros in your record to establish per-user exceptions with this mechanism. 

include

The ‘include’ mechanism allows you to add the entire SPF record or exclusive sending sources to your SPF record. This ensures that if they send a message on your behalf, then receiving servers don’t misjudge them as illegitimate senders. 

SPF Qualifiers

Each mechanism can be combined with one of the four optional qualifiers. They define the action to be taken when a mechanism is matched.

• + (Pass): The client is authorized.
• – (Fail): The client is not authorized.
• ~ (SoftFail): The client is not authorized, but the message might still be accepted.
• ? (Neutral): No explicit authorization or denial.

SPF Modifiers

SPF Modifiers play a crucial role in shaping the behavior of DNS SPF records. They are expressed as name-value pairs separated by ‘=’ and are positioned exclusively at the end of the SPF record. These modifiers provide additional information, specify exceptions to rules, or modify defaults.

The ‘redirect’ Modifier is particularly significant, guiding authentication to other SPF records. It is beneficial when multiple domains share the same SPF content, but it should be used cautiously only when you have control over all the involved domains. If the ‘all’ Mechanism is present in the SPF record, the ‘redirect’ Modifier is disregarded.

For authorized domains beyond your control, the ‘include’ SPF Mechanism is recommended. It is vital to note that modifiers can only appear once, and any unknown modifiers are simply ignored.

In situations where a Fail SPF Qualifier is returned, the ‘exp’ Modifier becomes valuable. It explains the reason behind the failure when a mechanism matches, aiding in diagnostics and troubleshooting for better email authentication.