SPF records define which mail servers are authorized to send email on behalf of a domain. As email-based threats continue to increase, accurate SPF configuration has become a core part of domain authentication governance. SPF is also a foundational requirement for DMARC compliance. When SPF and DMARC are configured correctly and aligned, they work together to reduce domain spoofing risk across inbound mail flows.

SPF record syntax follows a specific structure, and implementation errors are common when the components are not clearly understood. This guide covers SPF record syntax, format, and structure in detail, including mechanisms, qualifiers, and modifiers, so administrators can configure and maintain SPF records accurately.

SPF Record: Basic Syntax

An SPF record is a type of DNS record that lists all the IPs permitted to send an email using a specific domain. To understand what SPF is, think of it as a way to publish which servers are authorized to send email for your domain. 

If a server outside the list sends mail for that domain, the message can return an SPF fail result, and the receiving server decides how to handle it. 

This authentication standard helps receiving servers identify unauthorized sending sources. It can also support deliverability because authenticated messages are less likely to be rejected or marked as spam. Implementing SPF and DKIM together with DMARC is the best way to strengthen domain authentication.

SPF records contain instructions telling receiving servers how to validate emails from your domain and what to do when authentication fails. A specific component represents each instruction.

The following examples break down each element of the record:

v=spf1 ip4=192.0.2.0 ip4=192.0.2.1 include:examplesender.net -all

The above example indicates the record type, lists approved IP addresses, and includes an authorized third-party. It also tells receiving servers how to handle non-compliant emails. Here’s how each element of the SPF record does this:

• v=spf1 tells the recipient server that this is an SPF record. All SPF records must start like this.
• The next part of the SPF record syntax indicates the IP addresses authorized to send emails for this domain. In the above example, we have  ip4:192.0.2.0 and ip4:192.0.2.1.
• The ‘include:examplesender.net’ portion of the above example indicates third-parties authorized to send emails for the domain. The ‘include’ tag tells recipient servers to check the included domain’s (examplesender.net) SPF record for IP addresses that are also authorized. Numerous domains can be included within an SPF record, but only for valid domains.
• Lastly, -all returns an SPF hard fail result for senders not listed in the SPF record. In most environments, ~all is recommended instead. Hard fail does not add meaningful enforcement when DMARC is configured, and misconfigured hard fail policies can affect legitimate mail flows.

Two additional examples illustrate common configurations. The below SPF record example authorizes all servers with an IP address between 192.168.0.0 and 192.168.255.255, as well as Gmail accounts using google.com.

v=spf1 ip4:192.168.0.0/16 include:_spf.google.com ~all

The following SPF record example is similar. It authorizes servers between 192.168.0.0 and 192.168.255.255, Gmail accounts, and includes a third-party service: Send Your Mail.

v=spf1 ip4:192.168.0.0/16 include:_spf.google.com include:sendyourmail.com ~all

If you only want Gmail accounts sending emails from your organization, the SPF record syntax would look like this:

v=spf1 a mx include:_spf.google.com ~all

This SPF record syntax tells recipient servers that messages sent from the domain’s A record, MX record, or Google’s included SPF record should be treated as valid, while other sources return a soft fail result. 

You can use EasyDMARC’s free tool to generate SPF records. But you must first understand each component, how it works, and what it means. Let’s take a look at the advanced SPF record structure.

SPF Record: Advanced Syntax

SPF records are usually published as DNS TXT records types and follow an SPF record format specification. As mentioned, it always starts with the ‘v=’ element that denotes the SPF version used. There’s only one version currently, so ‘spf1’ is used. 

Each SPF record has specific terms that work as rules for which hosts can send emails from the domain or display additional information. 

SPF record syntax comprises three major elements: SPF Mechanisms, SPF Qualifiers, and SPF Modifiers.

SPF Mechanisms

Mechanisms are SPF tags used in the SPF record structure to tell receiving servers what to match and how to deal with emails.

1. all: It always matches and must be the last mechanism listed at the end of the SPF record. Any mechanisms after this are ignored. It also shows default results like ‘-all’ for unmatching IPs.

2. a: Defines a domain name with an A or AAAA address record as a match as it resolves to the sender’s address. The current domain is used if this SPF record syntax is unspecified. It’s typically applied when queries for A or AAAA records are generated in a domain with a sender’s IP address.

3. ip4: A match is successful when the sender’s IP matches the given ipv4 address or address range in the SPF record. A single IP address can be used on its own, or a range can be specified with a prefix. If no prefix is given, /32 is used by default.

4. ip6: A match is successful if the sender’s IP matches the given ipv6 address or address range. A single IP address can be used on its own, or a range can be specified with a prefix. If no prefix is given, /128 is used by default. 

5. mx: This mechanism authorizes senders with an IP address matching the one contained in the MX record specified. MX records consist of an IP address and a priority value for each server meant to accept messages, which can be confirmed through an MX record lookup.

If an MX record of a domain contains an IP address matching the sender’s IP address, the sender has permission to send emails using the domain.

6. ptr: Defines the authorized domain using PTR records which resolve IP addresses to subdomains or domains (the opposite of DNS A records). The receiving server reverse-maps the sending IP address using a PTR record lookup to find associated domain names.

For each exact domain match or subdomain, a forward lookup is then performed to find the IP address. If the sending IP address is the same as any IP addresses found during the lookup, then it’s a match and the email is validated.

The PTR mechanism is slow and unreliable as it requires multiple lookups. As such, it is deprecated and must not be used, according to the RFC 7208 guidelines. 

Some receiving servers ignore the PTR mechanism or even the entire SPF record with the PTR mechanism.

7. exists: This SPF mechanism executes a DNS A record search for the domain provided. A match happens when a valid A record is found, regardless of the actual lookup result. Using macros, you can set up per-user exceptions with this mechanism.

8. include: This mechanism is used to authorize third-party email senders by specifying their domains. A sender is authorized when its IP address matches the IP addresses or domains contained in the SPF record of the listed domain. A failure result is returned when no SPF record is found for the listed third-party domain. (Permanent errors are typically caused by duplicate mechanisms, void lookups, or exceeding the 10 DNS lookup limit.)

For larger domains with many third-party senders, managed SPF for large domains can make these updates easier to maintain.

SPF Qualifiers

An SPF Qualifier is an optional prefix to a mechanism. Adding an SPF record to your DNS with SPF Qualifiers tells receiving mail servers how to treat an email when there’s a match with a Mechanism value. 

Mechanisms are verified in the order of their occurrence in an SPF record. If a Mechanism lacks a Qualifier and there’s a match, SPF authentication passes. However, when there’s no match, the default action is neutral; the email message neither passes nor fails authentication.

Each mechanism can be combined with one of four qualifiers.

For most implementations, ~all is the recommended qualifier. Hard fail (-all) does not provide additional enforcement benefit in environments where DMARC is configured, and should not be treated as a stronger or preferred alternative to soft fail.

Other returned results include:

• None: No SPF record was found for the domain, or the SPF record didn’t return a result.
• TempError: A transient error usually due to DNS configuration issues.
• PermError: A permanent error usually due to SPF record syntax or formatting errors.

SPF Modifiers

SPF Modifiers decide how the SPF record format works. They consist of name or value pairs separated by the ‘=’ symbol, pointing out additional information, specifying exceptions to rules, or changing certain defaults.

The redirect and exp modifiers should appear at the end of the SPF record and must not appear more than once.

The ‘redirect’ Modifier directs to other SPF records for authentication. The redirect modifier is typically used when multiple domains need to share identical SPF record content.

Only use this SPF Modifier if you control all the domains. The ‘include’ SPF Mechanism should be used for authorized domains outside of your control. 

If the ‘all’ Mechanism appears in the SPF record, then the ‘redirect’ Modifier is ignored.

The ‘exp’ Modifier explains why the receiving server returned a Fail SPF Qualifier when a mechanism matches.

For long or complex SPF records, review SPF flattening tools before making DNS changes.

Tips for SPF Records

Before you check your record, keep the following tips in mind:

• A domain can’t have more than one SPF record.
• Use lowercase SPF syntax for consistency.
• Keep each TXT string within 255 characters and avoid records that exceed DNS lookup limits.
• Remove any SPF Mechanisms resolving to the same domain.
• Remove any ‘ip4’ and ‘ip6’ SPF Mechanisms not in use and see whether any address ranges can be merged.
• You can create a subdomain to store SPF information by using ‘_spf.domain.com.’ This is ideal for large organizations with too many IP addresses to include in a single SPF record. 
• The SPF checker is available as a free tool for record validation.

Summary

The SPF record is a crucial part of your domain’s DNS record as it tells receiving mail servers how to authenticate emails from your domain. Technology-reliant business owners must pair SPF with DKIM and DMARC to increase protection against spoofing and phishing attacks using their names.

EasyDMARC’s EasySPF tool takes your email-sending sources management to a higher level. You can also reach out if you have any other difficulties implementing SPF. We’re here to help.