How to Set Up an SPF Record: A Practical Guide for 2026

Setting up an SPF record is one of the three required authentication steps for any sending domain in 2026 (along with DKIM and DMARC). It looks deceptively simple — one TXT record in DNS — but the failure modes are specific and most teams who set up SPF wrong don’t discover the problem until placement rates have already collapsed. This article walks through SPF setup step by step, with the syntax that matters, the common mistakes to avoid, and the verification steps that catch problems before they cost campaigns. It pairs with the email deliverability guide and the SPF/DKIM/DMARC setup overview.

SPF (Sender Policy Framework) is a DNS-based authentication mechanism that tells receiving mail servers which IP addresses are authorized to send email on behalf of your domain. A correctly-configured SPF record reduces the chance of your emails being marked as spam or rejected. An incorrectly-configured one — too many DNS lookups, wrong syntax, missing senders — actively damages deliverability.

What an SPF record actually does

When an email arrives at a receiving mail server, the server checks the email’s “from” domain and looks up that domain’s SPF record in DNS. The SPF record contains a list of authorized senders (IP addresses, hostnames, or third-party services). If the email’s sending IP matches one of the authorized senders, SPF passes. If it doesn’t match, SPF fails — and most receiving systems treat SPF failures as a strong spam signal.

The SPF record itself is a plain text DNS record (a TXT record) at the root of your sending domain. Example:

v=spf1 include:_spf.google.com include:spf.smartlead.ai ~all

This translates to: “Mail from this domain is authorized to come from Google Workspace’s sending infrastructure or from Smartlead’s sending infrastructure. Anything else should be soft-failed.”

The pieces that matter:

• v=spf1 — version identifier; always at the start
• include:domain.com — delegate authorization to another domain’s SPF record (the most common mechanism)
• a / mx — authorize the A record or MX record of the domain itself
• ip4:1.2.3.4 — authorize a specific IPv4 address
• ~all / -all — the default fall-through: ~all is soft-fail (recommended for most cases), -all is hard-fail (strict)

Step-by-step setup

The basic workflow for setting up an SPF record:

Step 1: Identify all your sending services. Before writing the record, list every service that sends email “from” your domain. Common ones: Google Workspace or Microsoft 365 (your day-to-day email), the cold email tool you use (Smartlead, Lemlist, Instantly, Apollo), any transactional email provider (SendGrid, Mailgun, Postmark), any CRM that sends emails, any marketing email tool. Missing one means emails from that service will SPF-fail.

Step 2: Get the include: value for each service. Each sending service publishes their SPF include value in their documentation. Examples (verify against current docs):

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• Smartlead: include:spf.smartlead.ai (or similar — check current docs)
• SendGrid: include:sendgrid.net
• Mailgun: include:mailgun.org

Step 3: Build the SPF record string. Combine the includes with the version and the fall-through:

v=spf1 include:_spf.google.com include:spf.smartlead.ai ~all

Order doesn’t strictly matter, but keep it readable.

Step 4: Add the TXT record in DNS. Log into your DNS provider (Cloudflare, AWS Route53, GoDaddy, Namecheap, whatever you use), navigate to DNS records for your sending domain, add a new TXT record:

• Host/Name: @ (or leave blank, depending on the provider — represents the root domain)
• Type: TXT
• Value: the SPF string from step 3
• TTL: default (usually 3600 seconds / 1 hour)

Step 5: Wait for DNS propagation. Typically 5–60 minutes depending on your DNS provider and TTL settings. Some providers propagate within seconds; others take longer.

Step 6: Verify the record. Multiple verification tools exist. The simplest: dig +short TXT yourdomain.com from a terminal. You should see your SPF string. Online tools (MXToolbox, DMARC Analyzer’s SPF checker) do the same plus syntax validation.

The DNS lookup limit

The single most common SPF failure mode in 2026: exceeding the 10-DNS-lookup limit. Each include: mechanism counts as one DNS lookup, and includes can have nested includes that also count. SPF records that exceed 10 lookups fail “permerror” — which most receiving systems treat as SPF failure.

Common scenarios that exceed the limit:

• Multiple sending services with deep include chains (Salesforce’s SPF nests through several layers; HubSpot’s does too)
• Adding every transactional service “just in case” without checking lookup count
• Inheriting an old SPF record that included services no longer used

The fix: count your lookups. Tools like Kitterman SPF Test or MXToolbox SPF Surveyor show the lookup count. If you’re over 10, you need to flatten or consolidate.

Flattening means replacing include: mechanisms with the underlying IP addresses they would have authorized. Tools like SPFlat or PowerDMARC’s flattening service can do this automatically. The trade-off: flattened records don’t auto-update when the upstream service changes IPs, so they need periodic re-flattening.

Consolidation means removing services you don’t actually use. Audit your sending stack quarterly and remove SPF includes for services you’ve stopped using.

Common SPF setup mistakes

Adding +all or ?all instead of ~all or -all. +all means “anyone can send from this domain” — completely defeats the purpose of SPF. ?all means “we have no opinion” — almost as bad. Always use ~all (soft-fail) or -all (hard-fail).

Hard-failing (-all) without testing. -all tells receiving servers to reject email that doesn’t match the SPF record. If your SPF record is incomplete or wrong, -all causes legitimate email to be rejected. Production teams use ~all until SPF is verified working across all sending services, then optionally tighten to -all.

Multiple SPF records at the same domain. Some teams add a second SPF record when adding a new service, instead of editing the existing one. SPF specifies only one record per domain — multiple records cause “permerror.” Always edit the existing record; never add a second.

Including services that include each other. Some sending services’ SPF includes already include other common services. Adding both produces redundant lookups that count toward the 10-lookup limit without adding coverage.

Setting up SPF on the wrong domain level. If you send from mail.company.com, the SPF record needs to be on mail.company.com, not on company.com. Subdomains have their own SPF requirements when used as sending domains.

Forgetting to add SPF when starting cold email. Teams that start a cold email campaign without setting up SPF on the sending domain see immediate placement collapse — most receiving systems penalize unauthenticated mail heavily in 2026.

Not testing after changes. Every SPF change should be verified within an hour of propagation. Online testers like MXToolbox or PowerDMARC’s checker confirm the record is syntactically valid and within lookup limits.

What to do after SPF is set up

SPF alone isn’t enough. Three things should follow:

1. Set up DKIM for the same domain — covered in detail in how to set up DKIM. DKIM adds cryptographic signing on top of SPF’s IP authorization.
2. Set up DMARC once SPF and DKIM are both working — covered in DMARC policy: quarantine vs reject. DMARC ties SPF and DKIM together with an alignment check and a policy statement.
3. Monitor SPF results via DMARC reports. Once DMARC is set up, receiving systems will send aggregate reports showing which IPs sent mail claiming to be from your domain and whether SPF passed for each. This is the feedback loop for catching SPF problems.

SPF setup in 2026 is a 30-minute task when done correctly and a multi-week deliverability disaster when done wrong. The most useful discipline is to take the 30 minutes, set it up carefully, verify with multiple tools, and re-verify whenever the sending stack changes. The SPF/DKIM/DMARC setup overview covers how all three pieces work together.