SPF Record Syntax: Structure and Components | EasyDMARC

SPF Record Syntax: Structure and Components

9 Min Read
Lock and key images on a blue background

Understanding what SPF is and bringing it into use is important for technology-driven businesses as the number of phishing and spoofing attacks rise. SPF or the Sender Policy Framework record is also necessary for DMARC compliance. Both protocols work together to avert email forgery of your domain or email account.

SPF records are complicated and can lead to implementation issues if done incorrectly. SPF record syntax comprises certain terminologies that can be challenging to understand. Not to worry. Below, you’ll learn everything about the SPF record structure.

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. If any server outside the list tries to send an email using that domain, it’ll be marked as unauthorized and rejected by a recipient’s mailbox. 

Thus, organizations must create SPF records for cybersecurity. 

This authentication standard is one way to protect your domain against spoofing and phishing. It also prevents your emails from getting marked as spam by recipients’ mailboxes. Implementing SPF and DKIM together with DMARC is the best way to secure your domain.

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.

Let’s break down each element using some SPF record examples. Here’s what basic SPF record syntax looks like:

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

The above example indicates the record type, lists approved IP addresses and included 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= and ip4=
  • 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 instructs receiving servers to reject emails with IP addresses or domains not listed in the SPF record (as they’re not authorized).

Let’s look at two more examples. The below DNS SPF syntax authorizes all servers with an IP address between and, as well as Gmail accounts using google.com.

v=SPF1 ip4: include:_SPF.google.com ~all

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

v=SPF1 ip4: 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 emails sent from any host whose IP address ends with google.com should be considered valid (m), while all other messages should be discarded (a). 

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 syntax structure.

SPF Record: Advanced Syntax

SPF records for all syntax are usually defined using a DNS TXT record type with a single string of text. 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 DNS 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 is linked to the given ipv4 address range in the SPF record. It’s added with a prefix that signifies a range’s length. In case of no prefix, /32 is used by default. 

4. ip6: A match is successful if the sender belongs to the given ipv6 address range. It’s added with ip4 directive along with a prefix specifying range length. In case of no prefix, /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. 

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 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 not recommended 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 permanent error result is returned when no SPF record is found for the listed third-party domain.

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.

QualifierResultAction Taken by Receiving Server With a Match
+PassEmail message passes authentication and the server is permitted to send emails. Messages are authenticated and this is the default action taken in case of no Qualifier.
FailEmail message fails authentication as the sending server isn’t authorized to send emails for the domain. The SPF record instructs the receiving mail server to reject the email.
~SoftFailThe receiver’s mailbox accepts the message, however it is marked as suspicious and lands in the spam folder.
?NeutralEmail message neither passes nor fails authentication as the SPF record doesn’t explicitly state whether an IP address is authorized. Indicates that no match was found for the sender when checked against your authorized IP addresses and domains.

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 the DNS SPF record syntax’s working parameters. They consist of name or value pairs separated by the ‘=’ symbol, pointing out additional information, specifying exceptions to rules, or changing certain defaults.

Modifiers can only appear once and only at the end of the SPF record. Unknown modifiers are ignored.

The ‘redirect’ Modifier directs to other SPF records for authentication. Experts use them when they want more than one domain to have the same 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.

Tips for SPF Records

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

  • A domain can’t have more than one SPF record.
  • An SPF record can’t contain any uppercase characters.
  • A character limit of 255 characters applies to SPF records. Any string exceeding this number will result in failed authentication.
  • 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. 
  • Use our SPF record analyzer for free.


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.

Various authors from EasyDMARC teams have contributed to our blog during company's lifetime. This author brings everyone together.


Inline Feedbacks
View all comments

succees We’re glad you joined EasyDMARC newsletter! Get ready for valuable email security knowledge every week.

succees You’re already subscribed to EasyDMARC newsletter. Continue learning more about email security with us