Learn how to set up SPF records correctly with this comprehensive step-by-step guide. Discover SPF syntax, avoid the 10 DNS lookup limit, prevent common mistakes, and ensure your emails pass authentication checks for better deliverability.

Setting up SPF (Sender Policy Framework) records is one of the most critical steps in protecting your email domain from spoofing and improving your email deliverability. However, many organizations struggle with SPF configuration, leading to authentication failures and emails landing in spam folders.

This comprehensive guide will walk you through the process of creating and implementing SPF records correctly, avoiding common pitfalls, and ensuring your emails reach their intended recipients.

What You Need Before You Start

Before diving into SPF record creation, gather the following information:

• Access to your domain's DNS management panel (through your domain registrar or hosting provider)
• A list of all services and servers that send emails on behalf of your domain (e.g., Google Workspace, Microsoft 365, Mailchimp, SendGrid, your web server)
• IP addresses of any dedicated mail servers you own
• Administrator permissions to modify DNS records

Understanding SPF Record Syntax

An SPF record is a TXT record added to your domain's DNS zone. The basic structure looks like this:

v=spf1 [mechanisms] [qualifier]all

Key components include:

v=spf1 - The version identifier (always required and always first)

Mechanisms - Define which servers are authorized to send email:

• ip4:192.0.2.0/24 - Authorizes specific IPv4 addresses or ranges
• ip6:2001:db8::/32 - Authorizes specific IPv6 addresses or ranges
• include:_spf.google.com - Includes another domain's SPF policy
• a - Authorizes the domain's A record IP address
• mx - Authorizes the domain's MX record servers

Qualifiers - Define what action to take:

• + (Pass) - Default, explicitly authorize
• ~ (SoftFail) - Should not be authorized, but in transition
• - (Fail) - Not authorized, reject the email
• ? (Neutral) - No policy statement

all - The catch-all mechanism (always last):

• ~all (recommended) - SoftFail for everything else
• -all (strict) - Hard fail for everything else
• +all (not recommended) - Allows anyone to send email

Step-by-Step SPF Record Creation

Step 1: Identify All Email Sending Sources

Create a complete list of every service that sends emails from your domain. Common sources include:

• Email service providers (Google Workspace, Microsoft 365, Zoho Mail)
• Marketing platforms (Mailchimp, Constant Contact, SendGrid)
• Transactional email services (Postmark, Amazon SES, Mandrill)
• Web applications (WordPress, CRM systems, notification services)
• Internal mail servers

Missing even one sending source will cause those emails to fail SPF checks.

Step 2: Build Your SPF Record

Start with the version identifier and add mechanisms for each sending source:

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

This example authorizes:

• Google Workspace servers (include:_spf.google.com)
• Mailchimp servers (include:servers.mcsv.net)
• A dedicated IP address (ip4:203.0.113.10)
• SoftFails everything else (~all)

Step 3: Stay Within the DNS Lookup Limit

SPF has a critical limitation: a maximum of 10 DNS lookups. Each include mechanism counts as one lookup, and nested includes within those also count.

To check your lookup count:

• Count each include: mechanism
• Count a, mx, ptr, and exists mechanisms
• Remember that included records can have their own includes

If you exceed 10 lookups, your SPF record will fail validation. Solutions include:

Use IP addresses instead of includes when possible:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all

Flatten your SPF record by replacing includes with the actual IP ranges they reference (requires maintenance)

Use SPF macros for advanced scenarios (complex, use with caution)

Step 4: Add the SPF Record to Your DNS

Log in to your DNS management panel and create a new TXT record:

• Host/Name: @ (or leave blank for root domain) or subdomain
• Type: TXT
• Value: Your complete SPF record
• TTL: 3600 (1 hour) or your preference

For subdomains that send email, create separate SPF records:

newsletter.example.com TXT "v=spf1 include:sendgrid.net ~all"

Step 5: Verify Your SPF Record

After adding the record, wait for DNS propagation (usually 5-30 minutes, but can take up to 48 hours). Then verify using these methods:

Use online SPF checkers like the SPF Record Checker at EmailSecurityTools.com to validate syntax and lookup count

Use command-line tools:

nslookup -type=txt example.com

or

dig txt example.com

Send a test email to a test account and check the headers for SPF results

Common SPF Mistakes to Avoid

Multiple SPF records - Only one SPF record per domain is allowed. Multiple records will cause all of them to fail.

Exceeding 10 DNS lookups - This is the most common reason for SPF failures. Monitor your lookup count carefully.

Using +all - This allows anyone to send email from your domain, defeating the purpose of SPF.

Forgetting the version tag - Always start with v=spf1

Missing email sources - Failing to include all legitimate sending sources causes authentication failures.

Not testing before switching to -all - Start with ~all and monitor for several weeks before moving to a strict -all policy.

Including too many IP ranges - SPF records have a character limit (typically 255 characters per string, 512 total). Keep records concise.

Advanced SPF Configurations

For Multiple Subdomains

If you have many subdomains, consider creating a default SPF policy for subdomains that don't send email:

*.example.com TXT "v=spf1 -all"

This prevents subdomain spoofing while allowing you to override specific subdomains as needed.

For Transition Periods

When migrating mail servers, use SoftFail for the old servers while you transition:

v=spf1 include:newmailserver.com ip4:203.0.113.10 ~all

Monitor for a few weeks, then remove the old IP address once migration is complete.

For Third-Party Senders

If you allow customers or partners to send on your behalf, document which systems they should use and provide specific SPF guidance for those systems only.

Monitoring and Maintenance

SPF records require ongoing maintenance:

Review quarterly - Check that all included services are still in use and authorized

Monitor DMARC reports - DMARC reports will show you SPF authentication results and help identify unauthorized sending sources

Update when adding services - Whenever you add a new email service, update your SPF record immediately

Test after changes - Always verify changes using SPF validation tools

Document your record - Keep a list of what each mechanism represents for future reference

SPF and Other Email Authentication

Remember that SPF is just one part of email authentication. For comprehensive protection and deliverability:

Implement DKIM to verify email content hasn't been tampered with during transit

Set up DMARC to specify how receivers should handle emails that fail SPF or DKIM checks

Configure ARC if you use forwarding services or mailing lists

Monitor your IP reputation to ensure your sending IPs aren't blacklisted

Together, these protocols create a robust email authentication framework that protects your domain and ensures legitimate emails reach the inbox.

Conclusion

Setting up SPF records correctly is essential for email security and deliverability. By following this step-by-step guide, you can create an effective SPF policy that authorizes legitimate senders while protecting your domain from spoofing.

Remember to start conservatively with ~all, monitor your email authentication results through DMARC reports, and maintain your SPF record as your email infrastructure evolves. Regular testing and validation using tools like EmailSecurityTools.com ensures your SPF configuration continues to work effectively.

Taking the time to set up SPF correctly today will save you from deliverability headaches and security incidents tomorrow.