How to Create an Error-Free SPF Record

An SPF record is a DNS TXT record that lists all the authorized IP addresses and services permitted to send emails on behalf of your domain. Creating an error-free Sender Policy Framework record prevents mail servers from marking your legitimate outbound messages as spam or rejecting them outright. Without a properly configured record, attackers can easily spoof your domain, damaging your brand reputation and destroying your email deliverability.

To build your policy quickly and avoid syntax mistakes, you can use the SPF Record Generator on XiaTools to automatically construct and validate your DNS entry based on your exact email service providers.

Understanding SPF Record Anatomy

An SPF record always begins with a version declaration and ends with a global enforcement rule called a qualifier. Between these bookends sit your authorized mechanisms, which tell receiving mail servers where your mail originates.

The Standard Syntax Components

Every functional SPF record follows a rigid structure. Here are the core building blocks you need to know:

• v=spf1: The mandatory version tag. It must always be at the very beginning of the TXT string.
• ip4 and ip6: Explicitly authorizes specific IP addresses or CIDR subnets (e.g., ip4:192.0.2.1).
• include: Points to the SPF record of a third-party service provider, such as Google Workspace or Microsoft 365 (e.g., include:_spf.google.com).
• a and mx: Authorizes the server defined in your domain's A record or MX records.
• ptr: Deprecated and discouraged due to performance overhead and unreliability.
• exists: Advanced mechanism for complex matching scenarios.

Mechanisms vs. Modifiers

Mechanisms define who is allowed to send mail. Modifiers, on the other hand, set optional parameters that dictate how receivers should handle messages that fail evaluation. The two standard modifiers are redirect= (which points to another domain's SPF record) and exp= (which points to an explanation text record for failed checks).

Understanding Qualifiers

Qualifiers prefix mechanisms to determine what action to take when a match occurs. If you omit a qualifier, the default pass qualifier (+) is applied automatically.

• + (Pass): The sender is authorized.
• - (Fail): The sender is explicitly not authorized. Messages should be rejected.
• ~ (SoftFail): The sender is likely unauthorized, but accept the message and flag it in the headers.
• ? (Neutral): No policy stance; treat the message as neither authorized nor unauthorized.

Step-by-Step Guide to Creating Your SPF Record

Creating a clean record requires gathering a complete inventory of every system that sends email using your domain name. Follow these sequential steps to build and publish your policy.

Step 1: Audit Your Outbound Email Sources

Make a comprehensive list of all platforms, applications, and hardware devices that send emails using your domain in the Return-Path or From headers. Common sources include:

• Corporate email hosting (Google Workspace, Microsoft 365)
• Customer support platforms (Zendesk, Intercom)
• Marketing automation tools (Mailchimp, HubSpot)
• Transactional email gateways (SendGrid, Mailgun)
• On-premises servers or local printers

Step 2: Gather Required IP Addresses and Includes

For each identified source, obtain the precise configuration requirements. For third-party services, get their exact include domain string. For dedicated servers or cloud infrastructure, get the static IPv4 and IPv6 addresses or CIDR blocks.

Step 3: Construct the TXT Record String

Combine your version tag, mechanisms, and all-mechanism qualifier into a single string. For example, if you use Google Workspace and a dedicated outbound application server, your raw string will look like this:

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

Step 4: Publish the Record in Your DNS Provider

Log into your DNS hosting provider or domain registrar. Navigate to your domain's DNS management console (the exact menu path varies by provider, often labeled as "DNS Manager", "Zone Editor", or "Manage DNS").

Create a new record with the following parameters:

• Type: TXT
• Name / Host: Leave blank, use @, or input your domain name (e.g., example.com).
• TTL (Time to Live): Set to 3600 seconds or your provider's default.
• Value / Text: v=spf1 include:_spf.google.com ip4:192.0.2.15 -all

Save the record and allow time for global DNS propagation.

SPF Record Examples and Comparison

Different operational setups require different record designs. Review the following examples to match your organization's infrastructure.

Setup Scenario	Example Record String	Description
Simple Google Workspace	v=spf1 include:_spf.google.com ~all	Basic setup using only Google for corporate mail with a SoftFail policy.
Multi-Service Enterprise	v=spf1 include:_spf.google.com include:sendgrid.net ip4:192.0.2.0/24 ~all	Combines cloud email, a transactional sender, and an explicit corporate subnet.
Strict Lockdown	v=spf1 ip4:192.0.2.5 -all	Restricts outbound mail strictly to a single IP address with a hard fail policy.

Common Mistakes and How to Fix Them

Even experienced engineers occasionally make configuration errors that break SPF validation. Here are the most frequent pitfalls:

Exceeding the 10-DNS-Lookup Limit

SPF specifications enforce a strict limit of 10 recursive DNS lookups per evaluation. Mechanisms like include, a, mx, ptr, and exists trigger lookups. If your record requires 11 or more lookups, the evaluation fails permanently (PermError).

• The Fix: Flatten your SPF record by resolving nested includes into static IP addresses, or remove redundant third-party services.

Publishing Multiple SPF Records

If you publish more than one SPF TXT record for a single domain, receiving servers encounter a syntax error and reject the policy entirely.

• The Fix: Combine all authorized mechanisms into one single TXT record string per domain or subdomain.

Typos in Include Statements

Typing incude: instead of include: or misspelling a provider domain breaks validation instantly.

• The Fix: Copy and paste include strings directly from your provider's official documentation.

Using Hard Fail (-all) Prematurely

Implementing a strict -all qualifier before fully auditing your infrastructure causes legitimate messages from forgotten tools to bounce.

• The Fix: Start with a SoftFail (~all) policy during testing, monitor your reports, and switch to -all only after verifying full delivery success.

Pre-Publishing Checklist

Verify these items before deploying your configuration to production:

• Only one SPF TXT record exists for the root domain.
• The record begins with v=spf1 in lowercase.
• Total DNS lookups triggered by include, a, and mx are strictly 10 or fewer.
• All static IP addresses use valid IPv4 or IPv6 syntax.
• The record ends with an appropriate qualifier (~all or -all).
• Changes have been tested using command-line diagnostic tools.

Verifying Your SPF Record

Once published, verify your DNS configuration using command-line utilities or PowerShell.

To check your DNS records on Linux or macOS, run the dig command:

dig TXT example.com +short

To check your records on Windows using PowerShell, run:

Resolve-DnsName -Name example.com -Type TXT

If you need to test how receiving mail servers interact with your server configuration, you can test SMTP connectivity and TLS handshakes using OpenSSL:

openssl s_client -connect mail.example.com:25 -starttls smtp

Ensure that the output returns your exact string without truncation and that your lookup count stays well within safe thresholds.