SPF Record Setup: Complete Guide for Every DNS Provider

SPF (Sender Policy Framework) is a DNS record that tells receiving mail servers which IP addresses and servers are authorized to send email on behalf of your domain. Without it, anyone can send emails pretending to be from your domain, and mailbox providers will have no way to verify the sender's legitimacy.

Setting up SPF correctly is one of the first steps in email authentication, and getting it wrong is one of the most common causes of deliverability problems. Here is the complete guide to SPF setup, including the specific steps for major DNS providers and the common mistakes that trip people up.

How SPF Works

When you send an email, the receiving server looks up your domain's SPF record in DNS. The record contains a list of authorized sending sources (IP addresses, include statements for third-party services, etc.). The server checks whether the sending IP matches any of the authorized sources.

If the sending IP matches: SPF passes. The server knows this email came from an authorized sender.

If the sending IP does not match: SPF fails. The server treats the email with suspicion. Depending on your DMARC policy, the email might be delivered, quarantined, or rejected.

If no SPF record exists: SPF returns a neutral result. This is not as bad as a fail, but it means you are missing a foundational authentication layer that modern mailbox providers expect.

SPF Record Syntax

An SPF record is a DNS TXT record that follows a specific syntax. Here is a breakdown of the components.

v=spf1 - This is required at the beginning of every SPF record. It identifies the TXT record as an SPF record.

include: - References another domain's SPF record. Used for third-party services that send email on your behalf. For example, include:_spf.google.com authorizes Google's email servers.

ip4: - Authorizes a specific IPv4 address. For example, ip4:203.0.113.42 authorizes that specific IP.

ip6: - Authorizes a specific IPv6 address.

a - Authorizes the IP address(es) in the domain's A record.

mx - Authorizes the IP addresses of the domain's MX record servers.

~all - Soft fail for anything not matching. Emails from unauthorized sources are accepted but flagged. This is the recommended setting during initial setup.

-all - Hard fail for anything not matching. Emails from unauthorized sources are rejected. Use this once you are confident all legitimate sending sources are included.

Building Your SPF Record

Start by listing every service that sends email from your domain. Common services include:

Google Workspace: include:_spf.google.com

Microsoft 365: include:spf.protection.outlook.com

Amazon SES: include:amazonses.com

SendGrid: include:sendgrid.net

Mailgun: include:mailgun.org

Mailchimp: include:servers.mcsv.net

Postmark: include:spf.mtasv.net

Combine all your authorized services into a single SPF record. For example, if you use Google Workspace and SendGrid:

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

This record tells receiving servers: email from my domain is authorized if it comes from Google's servers or SendGrid's servers. Anything else should be treated as suspicious (soft fail).

The 10 DNS Lookup Limit

This is the most common SPF problem and the one most likely to cause deliverability issues without you realizing it.

The SPF specification limits the number of DNS lookups a receiving server will perform when evaluating your record to 10. Each "include" statement counts as one lookup. Some include statements reference other includes, which count as additional lookups. If your total exceeds 10, the entire SPF record fails, and every email you send fails SPF authentication.

You might be closer to the limit than you think. Google Workspace's include:_spf.google.com, for example, requires 3-4 nested lookups on its own. Add Microsoft 365 and a couple of email marketing tools, and you are at or over the limit.

To check your lookup count, use an SPF record checker tool like MXToolbox, EasyDMARC, or dmarcian. These tools show the total number of lookups your record requires.

If you are over the limit, you have several options. Remove services you no longer use. Replace include statements with direct IP addresses (ip4: entries do not count as lookups). Use an SPF flattening service that resolves includes into IP addresses and publishes a flattened record.

Setup by DNS Provider

Cloudflare: Go to DNS settings for your domain. Add a TXT record. Name: @ (or leave blank, depending on the interface). Value: your SPF record. TTL: Auto. Save.

GoDaddy: Go to DNS Management. Click Add Record. Type: TXT. Name: @. Value: your SPF record. TTL: 1 hour. Save.

Namecheap: Go to Advanced DNS. Click Add New Record. Type: TXT Record. Host: @. Value: your SPF record. TTL: Automatic. Save.

Google Domains/Squarespace: Go to DNS settings. Custom records section. Add record. Type: TXT. Host name: (leave blank). Data: your SPF record. Save.

Route 53 (AWS): Go to Hosted Zones. Select your domain. Create Record. Record type: TXT. Value: your SPF record (wrapped in quotes). TTL: 300. Save.

Regardless of provider, the process is the same: add a TXT record at the root of your domain (@) with your SPF string as the value.

Common SPF Mistakes

Multiple SPF records. You can only have one SPF record per domain. If you have two TXT records starting with v=spf1, SPF evaluation fails completely. Consolidate all authorized sources into a single record.

Forgetting a sending service. If you add a new email tool (cold email platform, marketing automation, CRM that sends emails) and forget to add it to your SPF record, emails from that service will fail SPF. When you add any new sending service, update your SPF record immediately.

Using +all instead of ~all or -all. The +all qualifier authorizes everyone to send as your domain, which defeats the entire purpose of SPF. Never use +all. Use ~all during initial setup and -all once you are confident.

Not testing after changes. After modifying your SPF record, wait for DNS propagation (typically 15 minutes to 4 hours) and then test. Send an email and check the headers for spf=pass. Use an online tool to validate the record syntax and lookup count.

SPF and Cold Email Domains

If you operate multiple cold email domains, each one needs its own SPF record. This is additional DNS management work, but it is non-negotiable. A cold email domain without SPF will have worse deliverability from day one.

Use a template for your cold email domains. If all your cold email domains use Google Workspace and the same cold email platform, the SPF record is identical across all domains. Create a standard record and apply it to each new domain as part of your setup checklist.

For cold email specifically, the sending services in your SPF record should typically be limited to your email hosting provider and your cold email platform. Fewer services means fewer DNS lookups and a cleaner authentication profile. If your cold email domain's SPF record includes Mailchimp, Salesforce, and three other marketing tools, something is wrong with your domain architecture.

SPF setup takes 10 minutes per domain when you know what you are doing. It is one of the simplest and most impactful changes you can make for email deliverability. Get it right, verify it is working, and move on to DKIM and DMARC to complete your authentication stack.