Skip to main content
New SPF lookups must resolve in milliseconds — why a DMARC tool's add-on isn't enough Learn Why → →
Foundational 15 min read

SPF Record Setup Guide: How to Configure SPF on Every Major Platform

Brad Slavin
Brad Slavin General Manager

Quick Answer

Setting up an SPF record requires adding a DNS TXT record to your domain that lists every server and service authorized to send email on your behalf. The exact steps vary by hosting provider and DNS platform, but the core process is the same: identify your sending sources, build the SPF string with the correct include mechanisms and IP addresses, publish it as a single TXT record, and verify it with an SPF checker. This guide links to platform-specific walkthroughs for Office 365, Google Workspace, GoDaddy, Cloudflare, Namecheap, Bluehost, and dozens more.

Share

Every domain that sends email needs an SPF record. Without one, receiving mail servers have no way to verify that a message actually came from an authorized source - and that means your emails are far more likely to land in spam folders or get rejected outright.

Per RFC 7208, SPF evaluation is capped at 10 DNS mechanism lookups and 2 void lookups per check. Exceeding either limit produces a PermError that fails authentication for every message from the domain.

The challenge is that every DNS provider, hosting platform, and email service has its own interface for managing DNS records. The steps to add an SPF record in GoDaddy look nothing like the steps in Cloudflare, and neither looks like the process in AWS Route 53. This guide serves as your central reference point - linking to detailed, platform-specific setup instructions while covering the universal principles that apply everywhere.

What is an SPF Record?

SPF stands for Sender Policy Framework. It is a DNS-based email authentication protocol that allows domain owners to declare which IP addresses and mail servers are permitted to send email on behalf of their domain. When a receiving server gets a message claiming to be from your domain, it queries DNS for your SPF TXT record and checks whether the sending server’s IP appears in the authorized list.

If the check passes, the message moves forward. If it fails, the receiving server may reject the message, route it to spam, or flag it for further scrutiny - depending on your DMARC policy.

For a deep dive into the protocol itself, start with What is SPF? A Detailed Guide on Sender Policy Framework.

Before You Start: The Universal Checklist

Regardless of which platform or hosting provider you use, the preparation steps are the same. Complete this checklist before touching any DNS settings.

1. Inventory Every Sending Source

List every service that sends email from your domain. This includes:

  • Your primary mail server - Microsoft 365, Google Workspace, on-premises Exchange, or any other mail platform
  • Marketing platforms - Mailchimp, HubSpot, Brevo (formerly Sendinblue), Mailerlite, ActiveCampaign
  • Transactional email services - SendGrid, Amazon SES, Postmark, SparkPost, Mandrill, Mailgun
  • CRM systems - Salesforce, HubSpot CRM, Freshdesk
  • Other services - Help desk tools, billing platforms, project management tools, or any application that sends email “as” your domain

Missing even one sending source is the most common reason SPF checks fail for legitimate mail. If you are unsure which services send on your behalf, check your DMARC aggregate reports for a complete picture.

2. Confirm You Have DNS Access

You need the ability to create or edit TXT records in your domain’s DNS zone. If your domain is registered with one provider but your DNS is managed elsewhere (for example, a domain registered at GoDaddy but using Cloudflare nameservers), you need to make changes at the DNS host, not the registrar.

3. Check for Existing SPF Records

A domain must have exactly one SPF record. Publishing two or more SPF TXT records causes a PermError, which fails authentication for all mail. Before adding a new record, check whether one already exists using our SPF Checker or by running dig TXT yourdomain.com from the command line.

If a record already exists, you need to merge the new sending sources into the existing record rather than creating a second one. See How to Merge SPF Records to Fix the Multiple SPF Records Error for detailed instructions.

4. Understand the 10-Lookup Limit

SPF evaluation is limited to 10 DNS mechanism lookups per check. Each include, a, mx, and redirect mechanism counts toward this limit. Exceeding it triggers a PermError. If your domain uses multiple third-party services, you may need SPF flattening or macros to stay within the limit.

Use our SPF Validator to check your current lookup count.

The Core SPF Record Structure

Every SPF record follows the same basic pattern:

v=spf1 [mechanisms] [qualifier]all
  • v=spf1 - Required version declaration. This must be the first element.
  • Mechanisms - The rules that define authorized senders. Common mechanisms include ip4, ip6, include, a, and mx.
  • all - The catch-all mechanism that defines what happens when a sender does not match any mechanism. Use -all (hard fail) for strict enforcement or ~all (soft fail) during initial deployment.

For a complete breakdown of every mechanism and qualifier, see SPF Record Syntax: The Complete Guide.

Here is a typical SPF record for a domain that uses Google Workspace and SendGrid:

v=spf1 include:_spf.google.com include:sendgrid.net -all

You can generate a correctly formatted record for your specific configuration using our SPF Record Generator.

Platform-Specific Setup Guides

The following guides walk through the exact steps for adding or modifying SPF records on each platform. Each guide includes screenshots, common pitfalls specific to that provider, and verification steps.

Major Email Platforms

These are the most commonly used email platforms. If your organization sends email through one of these, start here.

Domain Registrars and Hosting Providers

Each hosting provider has a different DNS management interface. These guides walk through the specific steps for each one.

Email Marketing and Transactional Services

Third-party email services require their own include mechanisms in your SPF record. These guides cover the correct values for each service.

Email Security Gateways

If you route outbound mail through a security gateway, that gateway’s servers must be included in your SPF record.

CRM and Business Applications

Business applications that send email on your behalf also need to be authorized in your SPF record.

Common Mistakes During Setup

Even with a platform-specific guide in hand, certain mistakes come up repeatedly. Being aware of them before you start saves troubleshooting time later.

Creating a Second SPF Record Instead of Merging

This is the most common setup mistake. When adding a new sending service, many administrators create a new TXT record with v=spf1 instead of adding the new include mechanism to the existing record. Having two SPF records on the same domain causes a PermError, which fails authentication for all mail - not just mail from the new service.

Before adding anything, always check for an existing SPF record first. Use the SPF Checker or run dig TXT yourdomain.com | grep spf from the command line.

Forgetting the -all or ~all Terminator

Every SPF record must end with an all mechanism. Without it, the SPF evaluator has no instruction for handling senders that do not match any listed mechanism. The result is an implicit ?all (neutral), which effectively means “I’m not making any assertion about unlisted senders.” This defeats the purpose of publishing an SPF record.

Use ~all (softfail) during initial deployment and testing, then move to -all (hardfail) once you have confirmed all legitimate senders are listed.

Authorizing Too Many or Too Few Senders

Including every service you have ever used - including ones you deactivated years ago - wastes DNS lookups and increases your attack surface. Conversely, missing a single active sending source means legitimate email from that service will fail SPF.

Review your sender inventory at least quarterly. Cross-reference it against DMARC aggregate reports to catch services you may have overlooked.

Ignoring DNS Propagation Time

After publishing or modifying your SPF record, DNS changes take time to propagate. Depending on your DNS provider and TTL settings, this can range from a few minutes to several hours. Do not test immediately after making changes - wait at least 15-30 minutes, and ideally verify from multiple locations.

Using the Wrong DNS Provider

If your domain is registered at one provider (e.g., GoDaddy) but your nameservers point to another (e.g., Cloudflare), changes must be made at the DNS host (Cloudflare), not the registrar (GoDaddy). This is a surprisingly common source of confusion.

SPF for Different Business Types

The complexity of your SPF record depends on the size and structure of your organization. Here is a general guide:

Small Businesses (1-50 employees)

Most small businesses use a single email platform (Google Workspace or Microsoft 365) and one or two third-party services (e.g., Mailchimp for marketing). A typical SPF record has 2-4 include mechanisms and stays well within the 10-lookup limit.

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

Mid-Size Companies (50-500 employees)

Mid-size organizations typically use multiple sending services across departments - marketing, sales, support, billing, and HR may each have their own email tools. SPF records commonly have 5-8 include mechanisms and may approach the 10-lookup limit.

At this stage, you should actively monitor your DNS lookup count and consider SPF flattening or subdomain delegation.

Enterprises (500+ employees)

Enterprise environments frequently exceed the 10-lookup limit without active management. Multiple business units, acquired companies, global offices, and dozens of SaaS applications all contribute include mechanisms. Dynamic SPF management with AutoSPF becomes essential at this scale.

See Difference Between SPF Setup for Small, Medium, and Large Businesses for a detailed comparison.

After Setup: Verification and Monitoring

Publishing an SPF record is not a set-and-forget operation. You need to verify that the record is correct and monitor it over time.

Verify Your Record Immediately

After publishing or modifying your SPF record, verify it using these tools:

DNS changes typically propagate within 15 minutes to 4 hours, depending on TTL values and DNS caching. Learn more about propagation timing in How Long Do SPF and DMARC Records Propagate Across the Internet?

Monitor for Breakage

SPF records break over time. Services change their IP ranges, you add new sending platforms and forget to update SPF, or a well-meaning colleague adds a second SPF record. Regular monitoring catches these issues before they affect deliverability.

Common post-setup issues include:

For a complete overview of SPF errors and their solutions, see SPF Errors and Troubleshooting Guide.

Managing Complex SPF Records

As organizations grow, SPF records tend to accumulate include mechanisms until they hit the 10-lookup limit. At that point, you have several options.

SPF Flattening

SPF flattening resolves include mechanisms to their underlying IP addresses, reducing the number of DNS lookups required during evaluation. This is effective but introduces a maintenance burden - if any provider changes their IPs, your flattened record becomes stale.

AutoSPF automates this process with dynamic SPF flattening, resolving includes in real time and keeping your record within the lookup limit without manual intervention.

For a comparison of SPF flattening approaches, see:

SPF Macros

SPF macros use variables like %{i} (sender IP) and %{d} (sender domain) to create dynamic SPF records that can authorize senders without consuming additional DNS lookups. See Automating SPF Macro Management for implementation details.

Subdomain Delegation

For organizations with many sending sources, delegating email sending to subdomains (e.g., marketing.yourdomain.com, billing.yourdomain.com) distributes the SPF lookup budget across multiple records.

Learn more in How to Set Up SPF Records for Subdomains.

SPF is One Part of the Equation

SPF alone does not provide complete email authentication. It verifies the sending server but does not protect message integrity or provide reporting. For full protection, you need all three protocols working together:

  • SPF verifies the sending server is authorized
  • DKIM adds a cryptographic signature to verify message integrity
  • DMARC ties SPF and DKIM together with alignment requirements and reporting

For guidance on combining all three, see How SPF, DKIM, and DMARC Work Together During Authentication.

Next Steps

  1. Audit your current setup - Use the SPF Checker to validate your existing record
  2. Follow your platform guide - Use the links above to configure SPF for your specific provider
  3. Verify after changes - Run your domain through the SPF Validator after publishing
  4. Set up DKIM - See the DKIM Lookup Tool to verify your DKIM configuration
  5. Deploy DMARC - Check your DMARC status with the DMARC Checker
  6. Monitor ongoing - Use DMARC reports to catch issues before they affect deliverability

If your SPF record has grown too complex to manage manually, AutoSPF can automate SPF flattening and monitoring, keeping your domain within the lookup limit without ongoing manual maintenance.

Topics

SPF SPF record email security email deliverability DNS email authentication
Brad Slavin
Brad Slavin

General Manager

Founder and General Manager of DuoCircle. Product strategy and commercial lead for AutoSPF's 2,000+ customer base.

LinkedIn Profile →

Ready to get started?

Try AutoSPF free — no credit card required.

Book a Demo

Related Articles

Foundational 14m

SPF Errors and Troubleshooting Guide: Fix Every SPF Failure

Foundational 15m

SPF Record Syntax Explained: The Complete Guide to Mechanisms, Qualifiers, and Limits

Foundational 14m

What is DKIM? The Complete Guide to DomainKeys Identified Mail

Foundational 15m

What is DMARC? The Complete Guide to Domain-Based Message Authentication