How to Check If Your SPF Record Is Correct

An incorrectly configured SPF record causes authentication failures that directly hurt your email deliverability. Common issues include syntax errors, exceeding the DNS lookup limit, missing sending sources, having multiple SPF records, and void lookups. These problems affect every email you send, including transactional messages like order confirmations and password resets.

This guide walks you through the exact steps to validate your SPF configuration using three different tools, explains SPF record syntax in detail, provides real-world record examples for common providers, and shows you how to fix the most frequent SPF errors. Whether you manage email authentication for Gmail, Yahoo, or Microsoft compliance, getting SPF right is the foundation.

Tool 1: MXToolbox SPF Check (Step-by-Step)

MXToolbox is the most widely used free SPF validation tool. It performs a comprehensive check of your record, including syntax validation, DNS lookup counting, and nested include resolution.

How to Run the Check

1. 1 Go to mxtoolbox.com/spf.aspx in your browser
2. 2 Enter your domain name (e.g., yourdomain.com) in the lookup field
3. 3 Click "SPF Record Lookup"
4. 4 Wait for the results to load (typically 2-5 seconds)

Understanding the MXToolbox Results

MXToolbox returns several pieces of information. Here is what each section means:

• SPF Record Published: Shows the raw TXT record found in DNS. If this is blank, your domain has no SPF record at all and you need to create one.
• SPF Record Status: Displays pass (green), warning (yellow), or fail (red). A passing record has valid syntax and stays within all limits.
• DNS Lookup Count: Shows the total number of DNS lookups your record requires, including all nested includes. This must be 10 or fewer.
• Record Tree: Expands every include: mechanism to show the nested records underneath. This helps you understand exactly what IP ranges each include authorizes.
• Warnings and Errors: Lists specific problems such as duplicate mechanisms, deprecated syntax, missing records at referenced domains, or lookup limit violations.

Tool 2: Google Admin Toolbox Check MX

Google Admin Toolbox is a free diagnostic tool from Google that validates SPF, DKIM, and DMARC records. It is especially useful if you are working toward Gmail sender compliance because it shows exactly what Google's systems see.

How to Run the Check

1. 1 Go to toolbox.googleapps.com/apps/checkmx/
2. 2 Enter your domain name in the field
3. 3 Click "Run Checks!"
4. 4 Scroll down to the SPF section in the results

Understanding the Results

Google Admin Toolbox provides a broader view than MXToolbox because it checks MX records, SPF, DKIM, and DMARC together. For SPF specifically, it shows:

• Whether an SPF record exists and whether the syntax is valid
• Whether the record has issues that would cause problems when sending to Gmail
• Warnings about permissive policies like +all
• Any DNS resolution errors for included domains

Because Google Admin Toolbox tests what Google's own infrastructure sees, passing this check gives you confidence that SPF will work correctly for Gmail delivery. Pair this with checking your DKIM configuration and DMARC reports for a complete authentication audit.

Tool 3: Command-Line Checks with nslookup and dig

For technical users who prefer working in the terminal, or for situations where you need to check SPF from a specific network or server, command-line DNS tools provide the most direct results. These tools query DNS directly without any intermediary.

Using nslookup (Windows and macOS)

The nslookup command is available on all major operating systems. Use it to query TXT records for your domain:

nslookup -type=TXT yourdomain.com

This returns all TXT records for the domain. Look for the line that begins with v=spf1. Example output:

yourdomain.com  text = "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"

To query a specific DNS server (useful for checking propagation), add the server address:

nslookup -type=TXT yourdomain.com 8.8.8.8

Using dig (Linux and macOS)

The dig command provides more detailed output and is the preferred tool on Linux systems:

dig TXT yourdomain.com +short

The +short flag produces clean output with just the record values. To see the full DNS response including TTL and authority information:

dig TXT yourdomain.com

Following the Include Chain Manually

To understand your full SPF record, you need to resolve each include: mechanism. For example, if your record includes _spf.google.com, query that domain next:

dig TXT _spf.google.com +short

Continue resolving each nested include until you reach records that only contain ip4: or ip6: mechanisms. Count each include:, a:, mx:, redirect=, and exists: resolution along the way to verify your total lookup count.

Using PowerShell (Windows)

On modern Windows systems, you can also use PowerShell to query SPF records:

Resolve-DnsName -Name yourdomain.com -Type TXT | Select-Object -ExpandProperty Strings

Testing SPF with Real Emails

Validation tools check your DNS record, but testing with real emails confirms that everything works in practice when an actual message travels through your sending infrastructure:

1. Send a test email from each sending system (primary email, marketing platform, transactional service, etc.)
2. Open the received message and view the raw message headers
3. Find the Authentication-Results header
4. Look for spf=pass along with the sending IP and Return-Path domain

If you see spf=fail or spf=softfail, the sending system's IP address is not authorized in your SPF record. Identify the IP from the header and add it to your record, or add the correct include: for that sending service.

Understanding SPF Record Syntax

Before you can fix SPF problems, you need to understand the building blocks of an SPF record. Every SPF record is a DNS TXT record that begins with v=spf1 and contains one or more mechanisms that define which servers are authorized to send email for your domain.

SPF Mechanisms Explained

Mechanism	Purpose	Example	DNS Lookups
ip4:	Authorizes a specific IPv4 address or range	ip4:192.168.1.0/24	0
ip6:	Authorizes a specific IPv6 address or range	ip6:2001:db8::/32	0
include:	References another domain's SPF record	include:_spf.google.com	1+ (nested)
a	Authorizes the domain's A record IP	a:mail.yourdomain.com	1
mx	Authorizes the domain's MX record IPs	mx	1 (+ 1 per MX host)
redirect=	Replaces the current SPF with another domain's record	redirect=_spf.example.com	1+
exists:	Passes if the domain resolves (advanced macro use)	exists:%{i}._spf.example.com	1
all	Catchall mechanism (must be last)	-all or ~all	0

Qualifiers

Each mechanism can be prefixed with a qualifier that determines what happens when the mechanism matches:

• + (Pass): The sender is authorized. This is the default if no qualifier is specified.
• - (Fail): The sender is explicitly not authorized. Receivers should reject the message.
• ~ (SoftFail): The sender is not authorized, but the domain is transitioning. Receivers should accept but mark the message.
• ? (Neutral): The domain makes no assertion about the sender. Rarely used in practice.

How SPF Evaluation Works

When a receiving mail server gets a message, it performs SPF evaluation in this order:

1. Extract the Return-Path (envelope sender) domain from the message
2. Query DNS for TXT records on that domain
3. Find the record starting with v=spf1
4. Evaluate each mechanism from left to right
5. Stop at the first mechanism that matches the sending IP
6. Return the result based on the matching mechanism's qualifier

This left-to-right evaluation means the order of mechanisms matters. Place your most frequently used sending sources first for optimal performance.

SPF Record Examples for Common Configurations

Here are SPF records for the most common email service configurations. Replace yourdomain.com with your actual domain.

Google Workspace Only

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

DNS lookups: 3 (Google's include chain resolves to nested includes for their IP ranges).

Microsoft 365 Only

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

DNS lookups: 2.

Google Workspace + Mailchimp

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

DNS lookups: 4.

Microsoft 365 + SendGrid

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

DNS lookups: 3.

Google Workspace + Mailchimp + SendGrid + Freshdesk

v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:email.freshdesk.com ~all

DNS lookups: 7. This is approaching the limit. Adding more services may require SPF flattening.

Complex Enterprise Configuration

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:amazonses.com ~all

DNS lookups: 8. The ip4: mechanism does not count as a lookup, which is why mixing direct IP authorization with includes helps manage the limit.

How to Fix Common SPF Errors

These are the most frequent SPF problems we encounter when auditing sender configurations, along with the specific steps to fix each one.

Error: Too Many DNS Lookups (Exceeding the 10-Lookup Limit)

This is the single most common SPF error for organizations using multiple email services. When your record requires more than 10 DNS lookups, SPF evaluation stops and returns permerror, meaning authentication fails for all email from your domain.

How to fix it:

• Audit your includes: List every include: in your record and verify each one is still needed. Remove includes for services you no longer use.
• Replace includes with IP addresses: If a service sends from a small, static set of IPs, replace the include: with direct ip4: or ip6: entries. These do not count toward the lookup limit.
• Use SPF flattening: Automated flattening tools resolve includes to their IP addresses, dramatically reducing lookup counts. See the SPF flattening section below.
• Use subdomains: Move some sending services to subdomains (e.g., marketing.yourdomain.com) with their own SPF records. Each subdomain gets its own 10-lookup allowance.

Error: Multiple SPF Records

If your domain has two or more TXT records starting with v=spf1, SPF immediately returns permerror. This is defined in RFC 7208 and there is no exception.

How to fix it:

1. Query your domain's TXT records to identify all SPF records:

   dig TXT yourdomain.com +short | grep "v=spf1"

2. Merge all the mechanisms from the duplicate records into a single record
3. Delete the extra TXT records from your DNS provider
4. Verify using MXToolbox that only one SPF record remains

Error: Missing Include for a Sending Service

When a service sends email as your domain but its IP addresses or include statement are not in your SPF record, those messages fail SPF. You will see spf=fail or spf=softfail in the Authentication-Results header for messages from that service.

How to fix it:

1. Identify the missing service by checking DMARC aggregate reports, which show all IPs sending as your domain along with their SPF results
2. Look up the correct SPF include statement in the service's documentation (e.g., include:sendgrid.net for SendGrid)
3. Add the include to your existing SPF record
4. Verify the updated record passes validation and stays within the 10-lookup limit

Error: Void Lookups Exceeding the Limit

RFC 7208 limits void lookups (DNS queries that return NXDOMAIN or empty answers) to two per SPF evaluation. This error occurs when your record includes references to domains that no longer publish SPF records.

How to fix it:

• Check each include: domain individually to confirm it still has an SPF record
• Remove or replace any includes that reference non-existent or inactive domains
• If you recently changed email providers, remove the old provider's include from your record

Error: Using +all (Allows Anyone to Send)

An SPF record ending in +all authorizes every IP address on the internet to send email as your domain. This completely defeats the purpose of SPF and leaves your domain wide open to spoofing.

How to fix it: Change +all to ~all (softfail) immediately. Once you have verified all legitimate sending sources are included, move to -all (hardfail) for maximum protection.

Error: SPF Record Too Long (Exceeding 255 Characters per String)

A single DNS TXT record string can hold a maximum of 255 characters. However, the SPF specification allows a record to span multiple strings that are concatenated. Most DNS providers handle this automatically, but some older providers or incorrect manual entry can cause truncation.

How to fix it:

• If your DNS provider's interface truncates the record, check whether it supports multi-string TXT records and use their specific formatting
• Reduce the record length by replacing verbose includes with ip4: mechanisms or using SPF flattening
• Move sending services to subdomains to distribute the SPF record across multiple domains

SPF Mechanisms and Their DNS Lookup Cost

Understanding which mechanisms consume DNS lookups is essential for staying within the 10-lookup limit. This table provides a quick reference:

Mechanism	DNS Lookups Used	Notes
ip4:	0	No DNS query needed; IP is specified directly
ip6:	0	No DNS query needed; IP is specified directly
all	0	Catchall; no DNS query required
a	1	Resolves A/AAAA record for the domain
mx	1 + (1 per MX host)	Resolves MX records, then A records for each MX hostname
include:	1 + nested lookups	Resolves the target SPF record and all its mechanisms
redirect=	1 + nested lookups	Replaces the current record with the target; counts like include
exists:	1	Performs a single A record query; used with macros
ptr:	1+	Deprecated; avoid using. Requires reverse DNS lookup plus validation

SPF Flattening: When and How to Use It

SPF flattening is the process of replacing include: mechanisms with the actual IP addresses they resolve to. This eliminates DNS lookups at evaluation time because ip4: and ip6: mechanisms require zero lookups.

When to Use SPF Flattening

• Your SPF record exceeds or approaches the 10-lookup limit
• You use many third-party sending services that each require an include
• You cannot reduce the number of sending services or use subdomains
• You have already removed all unnecessary includes and still exceed the limit

How SPF Flattening Works

A standard SPF record with includes:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net ~all

After flattening, the includes are replaced with their resolved IP addresses:

v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:167.89.0.0/17 ip4:198.2.128.0/18 ip4:205.201.128.0/20 ~all

The flattened version uses zero DNS lookups (all ip4: entries), compared to 4-6 lookups in the original.

The Critical Tradeoff

Automated Flattening Options

Several approaches automate SPF flattening by monitoring the IP addresses behind your includes and updating your DNS record when they change:

• Dedicated SPF management services: Tools that maintain a dynamic, flattened record for your domain. They typically use a single include pointing to their own servers, which they keep updated with the correct IPs.
• DNS hosting providers with SPF features: Some DNS providers offer built-in SPF flattening as part of their managed DNS service.
• Custom scripts: For organizations with engineering resources, a script that periodically resolves includes and updates the DNS record can work, but requires monitoring to catch failures.

Regular SPF Audits

SPF records require ongoing maintenance. Check your SPF record whenever you:

• Add a new email sending service or marketing platform
• Change email providers (e.g., migrating from one ESP to another)
• Update your mail server infrastructure or IP addresses
• Notice authentication failures in DMARC reports
• Receive bounce-back messages mentioning SPF failures
• Onboard a new SaaS tool that sends email on your behalf

Even without changes, audit your SPF record at least quarterly. Third-party providers can change their SPF includes or IP ranges without notifying you, which can push your lookup count over the limit or create void lookups. A quarterly check catches these issues before they affect deliverability.