SPF Record Syntax

SPF is the basic email authentication protocol used by organizations for boosting email delivery and marketing efforts. An SPF check is attempted using an SPF record that is made up of syntax. SPF record syntax is a DNS TXT record type that has a single string of text. It begins with the ‘v’ tag that indicates the version used, and as of now, there’s only one version- so, all valid SPF records for email-sending domains begin with v=SPF1.

An SPF record structure instructs the sources of a host to send an email message from the domain by clearly stating additional information. There are three major elements of SPF record syntax- SPF Mechanisms, SPF Qualifiers, and SPF Modifiers. 

Let’s understand everything about SPF record syntax for a DNS record.

SPF Mechanism

The list of the syntax of SPF records includes a total of 8 SPF mechanisms, each of which directs the recipient’s server what to match and how to handle messages coming from your domain.

1. ALL

The ‘all’ mechanism is added at the end of an SPF record and always matches. Any other SPF syntax after this is ignored. It also displays default results like ‘-all’ for IPs that don’t match. 

2. A

This mechanism specifies a domain name with an A or AAAA address record as a match. It directs to the sender’s address and is applied for the TXT lookup result of both A and AAAA records produced in a domain for deliverability.

3. Ipv4

A successful match is achieved only if the email sender uses the ip4-network address range listed in the SPF record syntax created for the particular domain. It’s added with a prefix-length that signifies a subnet or network range. In the case of no prefix, /32 is used by default. 

For example: 192.0. 2.146

4. Ipv6

A successful match is achieved only if the mail sender uses the ip6-network address range listed in the SPF record created for the particular domain. It’s added with an ip4 directive and a prefix-length that signifies a subnet or network range. In the case of no prefix, /128 is used by default. 

For example: 2001:0db8:85a3:0000:0000:8a2e:0370:7334

5. MX

This part of the SPF record syntax permits senders using the same kind of IP address as the one added to the specified MX record. MX records include IP addresses and priority values for all the servers that are authorized to accept incoming emails on behalf of an organization. 

When an MX record belonging to a domain includes an IP address the same as the sender’s IP address, the sender is allowed to send emails on behalf of that domain. 

Why Should MX Mechanisms Not be Used?

The use of MX mechanisms should be avoided in an SPF record as it causes more number of SPF DNS lookups, which may result in a Permerror error. 

6. PTR

The PTR mechanism is the opposite of an A record which means it resolves an IP address to a domain name.

Why is the PTR Mechanism Deprecated? 

As per RFC 7208 section 5.5, it shouldn’t be included in an SPF record as it’s a slow and unreliable mechanism. In fact, many receiving servers outrightly ignore this mechanism or even the entire SPF record if the PTR mechanism is included.

7. EXISTS

The SPF record Exists syntax performs lookups for DNS records of type ‘A’ for provided domain names. A successful match is achieved only if a valid A record is located. This is regardless of the maximum SPF lookup limit. 

8. INCLUDE

The SPF record Include syntax permits third-party mail senders to send emails on your behalf. Sender authorization happens when its IP address is the same as the IP address or domain added to the SPF record. If the IP address isn’t mentioned in the SPF record syntax, a permanent error comes up. 

Image sourced from uriports.com

SPF Qualifiers

SPF Qualifiers aren’t required mechanisms; they are optional. They instruct Gmail and other mailboxes on how to treat emails when there’s a match with a SPF Mechanism value. 

They work as per their order of occurrence in a valid SPF record. So, SPF authentication passes if a mechanism doesn’t have a Qualifier and a match is observed. However, in the case of no match, the default action is neutral, which means a message neither passes nor fails SPF checks.

Each mechanism can be grouped with one of the four qualifiers mentioned in the following table. 

Qualifier Value	Result	Action Taken by Receiving Server with a Match
+	Pass	It represents that the email has passed the SPF authentication check, and the sending server can send messages. This is the default action taken when a record lacks a Qualifier value.
–	Fail	This indicates that the email has failed the SPF verification process, which means the sending server isn’t allowed to send emails from that domain. In this case, the email gets rejected.
~	Softfail	The server of the recipient accepts the email, and it lands in the spam folder.
?	Neutral	In this case, the email neither passes nor fails authentication checks since the SPF record doesn’t explicitly state whether the sender is authorized to send messages. It represents that there wasn’t a match when checked against your permitted IP address and domain.

SPF record syntax for other results is explained as-

None

An SPF record for the domain isn’t located, or it didn’t return a result.

TempError

A transient error is usually due to DNS configuration issues.

PermError

You’ll see a permanent error because of SPF record structure or formatting errors.

SPF Modifiers

SPF modifiers determine the operational parameters of the syntax of the SPF record and include name or value pairs separated by the ‘=’ symbol that displays details like usage exceptions or alteration of default configurations.

Modifiers show up only once at the end of an SPF record, and unrecognized modifiers are ignored.

The Redirect Modifier is used when you want to use the same SPF record for one domain. Ensure using this only if you have control of all the domains. The Redirect Modifier gets overlooked when the ‘all’ mechanism is used in the SPF record.

The exp Modifier’s job is to explain why the receiving server returned a Fail SPF Qualifier when a mechanism matches.

Summary

A correct SPF record structure is crucial for email security and deliverability as it gives instructions to receiver servers (of a client, prospect, etc.) on treating emails coming from your domain. If any mail server outside the list tries to send an electronic mail using that domain or subdomain, it’ll be marked as unauthorized and will get rejected by the mailbox of the recipient. 

It’s suggested you use a set of addresses belonging to the ipv4 or ipv6 range in combination with DKIM and DMARC for protection against phishing and spoofing. 

Reach out to us for more information and explanation on the same.