How to Set Up an SPF Record: Complete DNS Guide (2026)

If your emails are landing in spam or being rejected outright, a missing or broken SPF record is one of the first things to check. SPF is a DNS-based protocol that tells every inbox provider — Gmail, Outlook, Yahoo — which servers are authorised to send email on behalf of your domain. Without it, receiving servers have no way to verify your identity, and your messages are treated as suspicious by default.

Setting up an SPF record takes under 30 minutes. Getting it wrong — duplicate records, too many DNS lookups, missing sending sources — is one of the most common technical deliverability mistakes US businesses make. This guide walks through every step of creating, publishing, and verifying your SPF record correctly, including the errors that most setup guides skip over.

What Is an SPF Record?

SPF stands for Sender Policy Framework. It is a DNS TXT record published at your domain that lists every IP address and mail server authorised to send email using your domain name. When Gmail or Outlook receives an email from hello@yourdomain.com, it performs a DNS lookup on your domain and checks whether the server that sent the email is on your approved list.

• SPF passes → the sending server is authorised → email is treated as legitimate
• SPF fails → the sending server is not on your list → email is more likely to be filtered or rejected

SPF is one of three authentication protocols every domain that sends email should have. The other two are DKIM (a cryptographic signature on each email) and DMARC (the enforcement policy layer that uses SPF and DKIM results to decide what to do with failing mail). If you have not yet set up all three together, our complete SPF, DKIM, and DMARC guide covers the full authentication stack end to end.

Before You Start: What You Need

Before creating your SPF record, compile a list of every service that sends email using your domain. This includes:

Every service you miss from this list will produce SPF failures when it sends email using your domain — which means those emails may be filtered or rejected, even if everything else is configured perfectly.

Step 1: Understand SPF Record Syntax

An SPF record is a DNS TXT record that begins with v=spf1 and ends with an all mechanism. Here is a typical example:

v=spf1 include:spf.migomail.com include:_spf.google.com ip4:203.0.113.45 ~all

Mechanism Reference

The all Qualifier — Choose Carefully

The all mechanism at the end of your record defines what happens to emails sent from servers not on your authorised list:

Start with ~all (softfail). Only move to -all (hardfail) after you have confirmed every legitimate sending source is included in your record. Moving to -all too early will hard-reject emails from sources you forgot to authorise.

Step 2: Build Your SPF Record

Using the sources you compiled before starting, construct your record by chaining the appropriate mechanisms.

Common SPF Includes by Provider

Example Records by Setup Type

Basic setup — Migomail + Google Workspace:

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

Migomail + Google Workspace + HubSpot CRM + custom mail server IP:

v=spf1 include:spf.migomail.com include:_spf.google.com include:_spf.hubspot.com ip4:203.0.113.45 ~all

Migomail only (dedicated sending, no other platforms):

v=spf1 include:spf.migomail.com -all

Step 3: Publish the SPF Record in Your DNS

Log in to your domain's DNS management panel and add a new TXT record with these values:

Provider-Specific Notes

Cloudflare — Enter @ as the Name. Cloudflare appends your domain automatically. Set proxy status to DNS Only (grey cloud) — TXT records must not be proxied.

GoDaddy — Enter @ as the Host. The Value field should contain your SPF string without surrounding quotes — GoDaddy adds them automatically.

Amazon Route 53 — Use your full domain name as the record name (e.g. yourdomain.com.). Wrap the SPF string in double quotes in the value field.

Namecheap — Enter @ as the Host, select TXT as the type, and paste the full SPF string into the Value field.

cPanel — Navigate to Zone Editor → Manage → Add Record. Select TXT, enter @ as the name, paste the SPF value.

DNS propagation typically completes in 10–30 minutes but can take up to 48 hours globally. During this window, some servers will see the record while others will not — this is normal.

Step 4: The 10-Lookup Limit — The Most Important SPF Rule

SPF allows a maximum of 10 DNS lookups to fully resolve your record. Every include:, a:, mx:, and redirect= mechanism counts as one lookup. If the total exceeds 10, receiving servers return a permerror — which is treated the same as an SPF failure.

What Counts Toward the Limit

How to Check Your Lookup Count

Paste your current SPF record into MXToolbox SPF Lookup. The tool shows the total lookup count and flags a permerror if you exceed 10.

What to Do If You Exceed 10 Lookups

SPF flattening replaces include: statements with the actual IP addresses they resolve to, eliminating those lookups. Instead of include:spf.migomail.com (1 lookup that resolves to a list of IPs), you list the IPs directly with ip4: (0 lookups). Use an automated SPF flattening tool to do this — manual flattening is error-prone and requires updating every time the provider changes their sending IPs.

Remove unused includes. If you migrated away from a sending platform months ago, its include: is still consuming a lookup. Audit your record against your current sending tools and remove any sources you no longer use.

Step 5: Verify Your SPF Record Is Correct

Never assume the record published correctly — verify it before moving on.

Method 1 — Command Line

# macOS / Linux
dig TXT yourdomain.com +short

# Windows (Command Prompt)
nslookup -type=TXT yourdomain.com

Look for a result starting with "v=spf1". The full record should match what you entered.

Method 2 — MXToolbox

Visit mxtoolbox.com/spf.aspx, enter your domain, and run the SPF lookup. MXToolbox:

• Confirms the record is published and reachable
• Validates syntax
• Counts your DNS lookups
• Flags any permerror, temperror, or misconfiguration

All checks should return green before proceeding.

Method 3 — Send a Test Email and Check Headers

Send an email from your domain to a Gmail address. Open the message, click the three-dot menu → Show original. In the Authentication-Results header, look for:

spf=pass (google.com: domain of hello@yourdomain.com designates 203.0.113.45 as permitted sender)

spf=pass confirms the record is live, the sending server is authorised, and SPF is working correctly for that sending source.

Step 6: Handle Subdomains

Your SPF record at yourdomain.com does not automatically cover subdomains. If newsletter.yourdomain.com or mail.yourdomain.com sends email, each needs its own SPF record.

For a sending subdomain:

# DNS record at newsletter.yourdomain.com
v=spf1 include:spf.migomail.com ~all

For a non-sending subdomain (parking it):

# Prevents the subdomain from being spoofed
v=spf1 -all

Any subdomain that could theoretically send email — even ones you do not actively use — should have an SPF record. Without one, an attacker can potentially use that subdomain for spoofing without triggering your root domain's SPF protection.

Step 7: Keep Your SPF Record Updated

SPF is not a one-time setup. Every time you add or remove a sending tool, you need to update your record. Common situations that require an update:

• Adding a new CRM or marketing automation platform
• Migrating from one ESP to another
• Adding a new transactional email service
• Decommissioning a tool you no longer use
• Your ESP changes their SPF include hostname (rare but happens)

Set a calendar reminder to audit your SPF record every 6 months. Compare your current include: statements against the tools actively sending email for your domain. Remove anything that is no longer in use — every unnecessary include is a wasted lookup from your limit of 10.

Common SPF Mistakes and How to Avoid Them

Two SPF records for the same domain You can only have one SPF TXT record per domain. If you publish two, receiving servers do not know which to use and return a permerror — SPF fails for every email you send. Before adding a new SPF record, always check whether one already exists. If it does, edit the existing record to add the new mechanism — do not create a second one.

Using +all by accident +all tells receiving servers that every server in the world is authorised to send email as your domain. This completely defeats the purpose of SPF. Always end your record with ~all (softfail) or -all (hardfail).

Including a service you no longer use Unused include: statements consume your 10-lookup budget and add no protection value. If you migrated from Mailchimp to Migomail six months ago, include:spf.mandrillapp.com should be removed from your record immediately.

Not covering subdomains A root-domain SPF record does not protect mail.yourdomain.com, newsletter.yourdomain.com, or any other subdomain. Any subdomain that sends email — or that could be used for spoofing — needs its own SPF record.

Exceeding 10 DNS lookups The most common SPF failure mode for growing businesses with multiple SaaS tools. Each new platform added to your stack adds lookups. Use MXToolbox to check your count after every change and flatten the record if you approach the limit.

SPF, DKIM, and DMARC: The Full Picture

SPF on its own provides meaningful protection but leaves two important gaps:

Gap 1 — Display-name spoofing. SPF checks the envelope sender (the technical Return-Path address) but not the From: header that recipients actually see. An attacker can pass SPF using their own domain while displaying yours in the visible From address. DMARC closes this by requiring alignment between the From: header and the SPF-authenticated domain.

Gap 2 — Forwarded email. When email is forwarded through a third-party server, SPF breaks — the forwarding server is not on your authorised list. DKIM survives forwarding because it is based on a cryptographic signature attached to the email itself, not the sending server's IP address.

This is why all three protocols work as a system. SPF alone is a partial defence. SPF + DKIM + DMARC is the complete stack. Our email deliverability best practices guide covers how they interact, and our DMARC setup guide walks through adding the enforcement layer once SPF and DKIM are in place.

Migomail's authentication dashboard validates your SPF, DKIM, and DMARC configuration in one place and flags any issues that could be affecting your inbox placement — without needing to manually run DNS lookups across three separate tools.

SPF Record Setup Checklist

Before publishing

• All email sending sources identified and their SPF includes noted
• No existing SPF record at the root domain (check first — do not publish a second one)
• DNS lookup count confirmed at 10 or fewer

Publishing

• TXT record added at @ (root domain) with correct SPF string
• TTL set to 3600 or lower for initial deployment
• Record does not start with a qualifier other than v=spf1
• Record ends with ~all or -all (never +all)

Verification

• dig TXT yourdomain.com returns the correct SPF string
• MXToolbox SPF Lookup returns all-green with lookup count below 10
• Test email to Gmail shows spf=pass in Authentication-Results header

Subdomains

• SPF record published for every subdomain that sends email
• Non-sending subdomains covered with v=spf1 -all

Ongoing

• SPF record audited every 6 months against active sending tools
• Unused include: statements removed promptly when platforms are decommissioned

Frequently Asked Questions

What is an SPF record and why do I need one?

An SPF record is a DNS TXT record that lists every server authorised to send email on behalf of your domain. When a receiving mail server gets an email claiming to come from your domain, it checks your SPF record to verify the sending server is on your approved list. Without an SPF record, receiving servers have no way to distinguish email you sent from email someone else sent while spoofing your domain. As of 2025–2026, Google, Yahoo, and Microsoft all require SPF for bulk senders — domains without it face filtering and rejection at all three platforms.

How many DNS lookups does an SPF record allow?

SPF allows a maximum of 10 DNS lookups to fully resolve your record. Each include:, a:, mx:, and redirect= mechanism counts as one lookup. If your record requires more than 10 lookups to resolve, receiving servers return a permerror — which is treated as an SPF failure and can cause emails to be filtered or rejected. Check your lookup count using MXToolbox's SPF Lookup tool after any change to your record.

Can I have more than one SPF record for my domain?

No. You can only have one SPF TXT record per domain (or subdomain). Publishing two SPF records for the same domain causes a permerror — receiving servers do not know which record to use and treat SPF as failing. If you need to add a new sending source, edit your existing SPF record to include the new mechanism. If you already have two records, merge them into one immediately.

What is the difference between ~all and -all in an SPF record?

Both mechanisms define what happens to emails sent from servers not listed in your SPF record. ~all (softfail) tells receiving servers to treat unauthorised emails with suspicion — they are typically delivered to the spam folder rather than rejected. -all (hardfail) tells receiving servers to reject unauthorised emails outright. Start with ~all while you are confirming all legitimate sending sources are included in your record, then move to -all once you are confident nothing legitimate is being missed. Never use +all — it authorises every server in the world to send as your domain.

Does SPF protect my domain from email spoofing?

SPF provides partial protection against spoofing. It verifies that the sending server is on your authorised list, which stops many spoofing attempts. However, SPF alone does not prevent display-name spoofing — where an attacker passes SPF using their own domain while displaying your domain in the visible From header. Full spoofing protection requires DMARC with alignment enforcement, which uses SPF and DKIM results together to verify the From header domain. SPF is the foundation; DMARC is what turns it into complete protection.

Summary

SPF is the first line of email authentication — the list of servers you trust to send email as your domain. Getting it right means:

1. Identify every service sending email using your domain
2. Build your SPF string using include: for each service and ip4: for any fixed IPs
3. Publish as a single TXT record at @ with a TTL of 3600
4. Verify with MXToolbox and a Gmail header check
5. Stay under 10 DNS lookups — flatten if needed
6. Cover subdomains individually
7. Audit every 6 months and remove unused includes

Once SPF is in place and verified, the next step is DKIM — the cryptographic signature that survives email forwarding and pairs with SPF to enable full DMARC enforcement. Our DMARC setup guide picks up right where this article leaves off.

Start your free trial to access Migomail's authentication dashboard — it validates your SPF, DKIM, and DMARC records automatically and flags any misconfiguration that could be costing you inbox placement.