SPF Record Setup Guide: How to Create and Check Your SPF Record

SPF (Sender Policy Framework) is one of the three core email authentication standards — alongside DKIM and DMARC — that protect your domain and improve deliverability. Setting it up correctly takes about 10 minutes and pays dividends for every email you send.

What is an SPF record?

An SPF record is a DNS TXT record published at your domain that lists all the servers and services authorized to send email on your behalf. When a receiving mail server gets a message from your domain, it looks up your SPF record to check whether the sending IP is on the approved list.

If the sending IP is authorized → SPF passes. If it’s not on the list → SPF fails, and the message may be flagged as spam or rejected.

SPF protects against email spoofing — where someone uses your domain in the From: address without your permission — and it’s a prerequisite for DMARC.

How to create an SPF record

Step 1: Identify all your sending sources

Before writing your SPF record, list every service that sends email using your domain:

• Your primary email provider (Google Workspace, Microsoft 365, etc.)
• Marketing email platforms (Mailchimp, HubSpot, ActiveCampaign, etc.)
• Transactional email services (SendGrid, Postmark, Mailgun, Amazon SES)
• CRM email sending (Salesforce, HubSpot)
• Any internal mail servers

Missing even one legitimate sending source means those emails will fail SPF.

Step 2: Build your SPF record

An SPF record starts with v=spf1 and ends with an all mechanism:

v=spf1 [mechanisms] [all]

Common mechanisms:

Mechanism	Meaning
include:domain.com	Authorize all IPs listed in domain.com’s SPF record
ip4:1.2.3.4	Authorize a specific IPv4 address
ip4:1.2.3.0/24	Authorize an IP range
a	Authorize the IP that your domain’s A record points to
mx	Authorize the IPs in your domain’s MX records

The all mechanism at the end defines what happens to senders not in your list:

Qualifier	Meaning
-all	Hard fail — reject messages from unauthorized senders (recommended)
~all	Soft fail — accept but flag as suspicious (safe default while testing)
?all	Neutral — no policy statement
+all	Pass all — don’t use this, it defeats the purpose of SPF

Step 3: Example SPF records

Google Workspace only:

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

Google Workspace + SendGrid:

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

Google Workspace + HubSpot + Mailchimp:

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

Each ESP documents their SPF include string in their authentication setup guide.

Step 4: Publish the record in DNS

1. Log into your domain registrar or DNS provider
2. Go to DNS management
3. Add a TXT record:
   • Name/Host: @ (or blank, meaning the root domain)
   • Type: TXT
   • Value: Your SPF record
   • TTL: 3600 (1 hour) is standard

Only one SPF record is allowed per domain. If you have an existing one, edit it — don’t add a second record.

Step 5: Check your SPF record

Once published, verify it’s working with an SPF lookup tool. Enter your domain and confirm the record resolves correctly and includes all your sending sources.

You can also check from the command line:

dig TXT yourdomain.com | grep spf

SPF record limits and common mistakes

The 10 DNS lookup limit

SPF has a hard limit of 10 DNS lookups during verification. Each include:, a, and mx mechanism counts toward this limit. Exceed it and your SPF record fails automatically — even if you haven’t made any other mistakes.

To stay under the limit:

• Use ip4: for static IPs instead of include: when possible
• Use SPF flattening tools to replace include: chains with direct IP lists
• Audit your record periodically as you add new services

Multiple SPF records

Publishing two TXT records that both start with v=spf1 causes SPF to fail. If you already have an SPF record, edit it to add new services rather than creating a new record.

Using +all

v=spf1 +all means “everyone is authorized” — it passes all mail, defeating the entire purpose of SPF. Never use +all.

Forgetting sending subdomains

SPF records apply only to the domain they’re published on. If you send from mail.yourdomain.com or newsletter.yourdomain.com, those subdomains need their own SPF records.

Not updating after adding new services

Every time you add a new email tool or ESP, check whether it needs to be in your SPF record. Forgetting to update is one of the most common causes of unexpected SPF failures.

SPF alone isn’t enough

SPF only checks the envelope MAIL FROM address, not the From: header that recipients see. That’s why DKIM and DMARC are also needed:

• DKIM signs the message content with a cryptographic key
• DMARC ties everything together and enforces a policy when authentication fails

All three work together. SPF is the first step — but configure DKIM and DMARC too for complete email authentication.

SPF and email deliverability

Properly configured SPF directly improves your inbox placement. Gmail, Yahoo, Outlook, and other major providers all use SPF as a deliverability signal. A domain without SPF — or with a broken SPF record — faces higher spam classification rates and is easier to spoof.

Clean authentication records + clean email lists = reliable deliverability. Verify your email list with Truelist to make sure your authenticated sends are reaching real inboxes.