Technical | 10 min read

SPF Record Syntax Explained

A complete breakdown of SPF record syntax, mechanisms, qualifiers, and modifiers with real-world examples.

What is an SPF Record?

SPF (Sender Policy Framework) is an email authentication protocol defined in RFC 7208. It allows domain owners to specify which mail servers and IP addresses are authorized to send email on behalf of their domain. SPF records are published as DNS TXT records and are checked by receiving mail servers during the email delivery process.

Key Takeaways
  • A domain must have exactly one SPF TXT record; multiple records cause a permanent error
  • SPF evaluation is limited to 10 DNS lookups; exceeding this breaks SPF entirely
  • Use -all (hard fail) or ~all (soft fail) at the end of your record to define your default policy
  • The ip4 and ip6 mechanisms do not count toward the 10-lookup limit, making them efficient choices
In This Article
  1. What is an SPF Record?
  2. Basic SPF Record Structure
  3. Mechanisms Explained
  4. Qualifiers (+, -, ~, ?)
  5. Modifiers (redirect, exp)
  6. SPF Record Examples for Common Providers
  7. The 10-DNS-Lookup Limit
  8. Common SPF Mistakes
  9. Testing Your SPF Record

When a mail server receives an email, it looks up the SPF record for the domain in the envelope sender (Return-Path) address. It then evaluates whether the sending server's IP address is authorized by the record. The result is either pass, fail, softfail, neutral, or various error states.

Did You Know?

SPF was first proposed in 2003 by Meng Weng Wong as a way to combat email forgery. It was originally called "Sender Permitted From" before being renamed to "Sender Policy Framework." The protocol went through several revisions before being standardized in RFC 7208 in 2014, replacing the earlier RFC 4408.

Basic SPF Record Structure

Every SPF record follows the same basic structure. It starts with a version tag, contains one or more mechanisms that define authorized senders, and typically ends with an "all" mechanism that specifies the default policy for unlisted sources.

v=spf1 [mechanisms] [modifiers] [all]

Here is a simple, real-world example:

v=spf1 include:_spf.google.com ip4:203.0.113.50 -all

This record says: "Email from this domain can come from Google Workspace servers or from the IP address 203.0.113.50. Reject everything else."

Important rules for SPF records:

  • A domain must have exactly one SPF TXT record. Multiple SPF records cause a permanent error.
  • The record must begin with v=spf1 (note: it is spf1, not spf2).
  • The total record length cannot exceed 512 bytes for a single DNS UDP response, though multiple strings can be concatenated in a single TXT record.
  • SPF is evaluated against the envelope sender (Return-Path), not the From: header.

Mechanisms Explained

Mechanisms are the core building blocks of an SPF record. Each mechanism defines a set of IP addresses or hosts that are authorized (or not authorized) to send email for the domain. Mechanisms are evaluated left to right, and the first match determines the result.

ip4 - IPv4 Address or Range

Authorizes a specific IPv4 address or CIDR range. This mechanism does not require a DNS lookup.

v=spf1 ip4:203.0.113.50 ip4:198.51.100.0/24 -all

The first entry authorizes a single IP. The second authorizes an entire /24 subnet (256 addresses). You can use CIDR notation from /0 to /32, though ranges broader than /16 are unusual and may be flagged as suspicious.

ip6 - IPv6 Address or Range

Same as ip4 but for IPv6 addresses. Also does not require a DNS lookup.

v=spf1 ip6:2001:db8::1 ip6:2001:db8::/32 -all

a - Domain A Record

Authorizes the IP address(es) found in the domain's A (or AAAA) record. If no domain is specified, it defaults to the current domain.

v=spf1 a a:mail.example.com -all

The first a matches the A record of the domain itself. The second matches the A record of mail.example.com. This mechanism requires a DNS lookup for each usage.

mx - Domain MX Record

Authorizes the IP addresses of all mail servers listed in the domain's MX records. Like a, it defaults to the current domain if no domain is specified.

v=spf1 mx mx:backup-domain.com -all

This is useful when your MX servers also send outbound email. Each mx mechanism counts as one DNS lookup, plus additional lookups to resolve the MX hostnames to IP addresses.

include - Include Another Domain's SPF

The include mechanism references another domain's SPF record and evaluates it. This is the most common way to authorize third-party email services.

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

Each include counts as one DNS lookup. The included domain's SPF record is then evaluated, and its own includes, a, and mx mechanisms may trigger additional lookups. This is why include chains can quickly consume your 10-lookup limit.

Warning: Be careful with nested includes. An include that itself includes three other domains counts as 4 lookups (1 for the include + 3 for the nested includes). Always verify your total lookup count with a SPF checker.

Pro Tip

When possible, use ip4 and ip6 mechanisms instead of include for services with stable, well-documented IP ranges. Since IP mechanisms do not count toward the 10-lookup limit, this is one of the most effective ways to free up lookups for services that can only be added via include. Check with your ESP for their published IP ranges.

all - Default Result

The all mechanism matches everything. It is typically placed at the end of the record to define the default policy for IPs that do not match any previous mechanism.

Syntax Meaning Recommendation
-all Hard fail - reject unauthorized senders Strictest, recommended for domains with well-known senders
~all Soft fail - accept but mark as suspicious Most common choice, good balance of security and flexibility
?all Neutral - no assertion about unauthorized senders Rarely useful, provides almost no protection
+all Pass - authorize all senders Never use this, it defeats the purpose of SPF entirely

Qualifiers (+, -, ~, ?)

Every mechanism can be prefixed with a qualifier that determines the result when that mechanism matches. If no qualifier is specified, + (pass) is the default.

Qualifier Result Description
+ Pass The IP is authorized. This is the default if no qualifier is specified.
- Fail The IP is explicitly not authorized. Messages should be rejected.
~ SoftFail The IP is probably not authorized. Messages should be accepted but flagged.
? Neutral No assertion about the IP. Treated as if no SPF record exists for that mechanism.

Examples of qualified mechanisms:

v=spf1 +ip4:203.0.113.50 ~include:thirdparty.com -all

In this record, email from 203.0.113.50 passes (explicitly authorized). Email matching the third-party's SPF gets a softfail result. Everything else gets a hard fail.

Modifiers (redirect, exp)

Modifiers provide additional functionality beyond the basic mechanism matching. Unlike mechanisms, modifiers do not directly affect the SPF result. The two defined modifiers are redirect and exp.

redirect

The redirect modifier replaces the current domain's SPF evaluation with that of another domain. It is useful when multiple domains share the same email infrastructure.

v=spf1 redirect=_spf.example.com

This tells the receiver: "Evaluate the SPF record at _spf.example.com instead of this one." The redirect is only processed if no mechanisms have matched. If the record contains any mechanisms alongside the redirect, the redirect is ignored when a mechanism matches.

Tip: Use redirect instead of include when you want to completely delegate SPF evaluation to another domain and you have no other mechanisms to add. It is cleaner and saves a lookup compared to include:domain -all.

exp

The exp modifier specifies a domain whose TXT record contains a human-readable explanation string. This string is returned to the sender when SPF fails.

v=spf1 include:_spf.google.com -all exp=spf-explain.example.com

The TXT record at spf-explain.example.com might contain:

"Mail from example.com must be sent from an authorized server. See https://example.com/email-policy"

The exp modifier is rarely used in practice, but it can be helpful for debugging and communicating with server administrators who see SPF failures in their logs.

SPF Record Examples for Common Providers

Below are ready-to-use SPF record templates for the most popular email services. Combine multiple includes if you use more than one service.

Google Workspace

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

Microsoft 365

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

Amazon SES

v=spf1 include:amazonses.com ~all

Google Workspace + SendGrid + Custom IP

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.50 ~all

Microsoft 365 + Mailchimp

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ~all

Domain That Does Not Send Email

v=spf1 -all

If a domain or subdomain should never send email, publish this record to explicitly block all senders. This is an important security measure for parked or non-mailing domains.

~40%
of domains have SPF records with errors or suboptimal configurations, according to industry analyses. The most common issues are exceeding the 10-lookup limit and missing third-party senders.

The 10-DNS-Lookup Limit

The SPF specification limits the total number of DNS lookups during SPF evaluation to 10. This is one of the most common and frustrating issues with SPF, especially for organizations that use many third-party email services.

Mechanisms that require DNS lookups:

  • include - 1 lookup per include, plus any lookups in the included record
  • a - 1 lookup per usage
  • mx - 1 lookup, plus additional lookups to resolve MX hostnames
  • redirect - 1 lookup
  • exists - 1 lookup per usage

Mechanisms that do NOT require DNS lookups:

  • ip4 - no lookup needed
  • ip6 - no lookup needed
  • all - no lookup needed

Warning: Exceeding 10 DNS lookups causes a permanent error (PermError). When this happens, SPF evaluation fails entirely, and most receiving servers treat the result as if SPF does not exist. This can seriously damage your deliverability.

Pro Tip

Consider using an SPF flattening service if you are running up against the 10-lookup limit. Flattening resolves all include mechanisms to their underlying ip4 and ip6 addresses at publish time, dramatically reducing your lookup count. Just be aware that flattened records need to be updated whenever your providers change their IP ranges, so use an automated service that refreshes the record regularly.

Strategies to stay within the limit:

  • Replace include mechanisms with ip4 or ip6 where possible
  • Remove unused or legacy services from your SPF record
  • Use SPF record flattening services that resolve includes to IP addresses at publish time
  • Move subdomains to their own SPF records (each domain gets its own 10-lookup budget)
  • Consolidate sending through fewer providers

Use our SPF Record Checker to see exactly how many lookups your current record uses.

Common SPF Mistakes

These are the most frequent SPF configuration errors we see when analyzing domains:

  1. Multiple SPF records: A domain must have exactly one SPF TXT record. Having two or more causes a PermError. If you need to add a new service, edit your existing record rather than adding a second one.
  2. Missing third-party senders: If you use services like Mailchimp, SendGrid, HubSpot, or Zendesk for email, their sending servers must be included in your SPF record.
  3. Using +all: The +all mechanism authorizes every server on the internet to send email for your domain. This completely negates SPF protection.
  4. Too many DNS lookups: Exceeding the 10-lookup limit causes SPF to break entirely. Always verify your lookup count after making changes.
  5. Using ptr mechanism: The ptr mechanism is deprecated and should not be used. It is slow, unreliable, and places unnecessary load on DNS servers.
  6. Syntax errors: Typos like v=spf 1 (space), include _spf.google.com (missing colon), or v=spf1include: (missing space) will cause the entire record to fail.
  7. Not ending with all: While technically valid, omitting the all mechanism means the default result for non-matching IPs is neutral, providing no protection.
  8. Using the wrong record type: SPF records must be published as TXT records. The dedicated SPF DNS record type was deprecated in 2014.
Quick Summary

SPF records authorize which servers can send email for your domain. Keep exactly one record per domain, stay within the 10-DNS-lookup limit, and always end with -all or ~all. Use ip4/ip6 mechanisms where possible to save lookups, and test thoroughly with an SPF checker after every change.

Testing Your SPF Record

After creating or modifying your SPF record, always test it before relying on it for production email. Our SPF Record Checker will:

  • Validate the syntax of your record
  • Count all DNS lookups (including nested includes)
  • List every mechanism and its resolved values
  • Identify common issues and misconfigurations
  • Show you the effective set of authorized IP addresses

For a complete audit of your email authentication setup (SPF, DKIM, and DMARC together), use the Domain Reputation Checker.

SenderReputation.org Editorial Team
Our team of email deliverability experts writes in-depth guides and analysis to help senders build and maintain strong sender reputations.
Share this article:
← Back to Blog

Related Tools

SPF Record Checker Sender Reputation Checker SPF Record Generator

Related Posts

Google and Yahoo 2024 Sender Requirements DMARC Policies Explained Why Your Emails Go to Spam

Check Your Domain

Get your free Sender Reputation Score and see how your email configuration stacks up.

Check Now