Email Security

What Is an SPF Record? Email Security Explained

Unified DNS Team · 2026-01-10 · 9 min read

Table of Contents

What Is an SPF Record?

An SPF record (Sender Policy Framework record) is a DNS TXT record that specifies which mail servers are authorized to send email on behalf of your domain. It’s one of the three pillars of email authentication, alongside DKIM and DMARC.

The Basics

  • SPF stands for “Sender Policy Framework”
  • Published as a TXT record in DNS
  • Lists IP addresses and servers authorized to send email for a domain
  • Receiving mail servers check SPF to validate the sender
  • Helps prevent email spoofing and phishing attacks

Why SPF Matters

Without SPF, anyone can send email claiming to be from your domain. SPF provides:

  • Sender verification — Proves email came from an authorized server
  • Spoofing prevention — Blocks unauthorized senders from impersonating your domain
  • Improved deliverability — Legitimate email is less likely to be marked as spam
  • Brand protection — Prevents attackers from damaging your reputation

Example SPF Record

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:198.51.100.25 -all"

How SPF Works

The Verification Process

When someone sends an email, here’s what happens:

  1. Email sent — Mail server at IP 198.51.100.25 sends email claiming to be from user@example.com
  2. Receiving server queries DNS — Looks up TXT records for example.com
  3. SPF record found — Contains list of authorized senders
  4. IP checked against SPF — Is 198.51.100.25 in the authorized list?
  5. Result returned — Pass, Fail, SoftFail, or Neutral

SPF Check Flow

StepAction
Incoming emailFrom: user@example.com, Sent from IP: 198.51.100.25
DNS QueryTXT records for example.com
SPF Record found“v=spf1 ip4:198.51.100.25 -all”
CheckIs 198.51.100.25 authorized?
ResultPASS

What Receiving Servers Do with Results

ResultMeaningTypical Action
PassIP is authorizedAccept email
FailIP is not authorizedReject or mark as spam
SoftFailIP is probably not authorizedAccept but flag
NeutralNo statement about IPAccept normally
NoneNo SPF record existsAccept (no policy)

SPF Syntax Explained

Basic Structure

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

"v=spf1 [mechanisms] [qualifier]all"

Mechanisms

Mechanisms define who is authorized to send email:

MechanismExampleDescription
ip4ip4:198.51.100.25Single IPv4 address
ip4ip4:198.51.100.0/24IPv4 range (CIDR notation)
ip6ip6:2001:db8::/32IPv6 address or range
includeinclude:_spf.google.comInclude another domain’s SPF
aaDomain’s A record IPs are authorized
mxmxDomain’s MX record IPs are authorized
existsexists:%{i}.spf.example.comAdvanced macro-based check

Qualifiers

Qualifiers determine what happens when a mechanism matches:

QualifierMeaningExample
+ (default)Pass+ip4:198.51.100.25
-Fail (hard)-all
~SoftFail~all
?Neutral?all

The all Mechanism

The all mechanism at the end defines the default policy for IPs that don’t match:

; Strict - reject unauthorized senders
"v=spf1 include:_spf.google.com -all"

; Lenient - flag but don't reject
"v=spf1 include:_spf.google.com ~all"

; Testing - no action
"v=spf1 include:_spf.google.com ?all"

Recommendation: Use -all for production after thorough testing.

Common SPF Configurations

Microsoft 365 Only

example.com.    TXT    "v=spf1 include:spf.protection.outlook.com -all"

Google Workspace Only

example.com.    TXT    "v=spf1 include:_spf.google.com ~all"

Microsoft 365 + Marketing Platform

; Microsoft 365 + HubSpot
example.com.    TXT    "v=spf1 include:spf.protection.outlook.com include:spf.hubspot.com -all"

; Microsoft 365 + Mailchimp
example.com.    TXT    "v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all"

; Microsoft 365 + SendGrid
example.com.    TXT    "v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all"

Multiple Services

; Microsoft 365 + SendGrid + Custom server
example.com.    TXT    "v=spf1 include:spf.protection.outlook.com include:sendgrid.net ip4:198.51.100.25 -all"

Self-Hosted Mail Server

; Single server
example.com.    TXT    "v=spf1 ip4:198.51.100.25 -all"

; Multiple servers
example.com.    TXT    "v=spf1 ip4:198.51.100.25 ip4:198.51.100.26 mx -all"

Common Include Values

ServiceInclude Value
Microsoft 365include:spf.protection.outlook.com
Google Workspaceinclude:_spf.google.com
SendGridinclude:sendgrid.net
Mailchimpinclude:servers.mcsv.net
HubSpotinclude:spf.hubspot.com
Salesforceinclude:_spf.salesforce.com
Zendeskinclude:mail.zendesk.com
Freshdeskinclude:email.freshdesk.com

SPF Limitations

The 10 DNS Lookup Limit

SPF records are limited to 10 DNS lookups. Each include:, a, mx, and exists mechanism counts as a lookup.

; This might exceed the limit
"v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:sendgrid.net include:spf.hubspot.com include:mail.zendesk.com include:servers.mcsv.net -all"

Each include can contain nested includes that also count!

Solutions:

  • Use ip4: instead of include: where possible
  • Consolidate email services
  • Use SPF flattening services
  • Remove unused services from SPF

SPF Doesn’t Check the “From” Header

SPF validates the envelope sender (MAIL FROM), not the visible “From” header in email clients. This is why DMARC is needed to fully prevent spoofing.

SPF Breaks with Email Forwarding

When email is forwarded, the sending IP changes but the sender domain stays the same, causing SPF failures. This is why many domains use ~all (SoftFail) instead of -all.

Best Practices for MSPs

1. Audit Before Configuring

Before setting up SPF:

  1. Identify ALL services that send email for the domain
  2. Document their SPF requirements
  3. Check current DNS lookup count
  4. Plan the complete SPF record

2. Start with SoftFail

During initial deployment:

; Start with ~all for monitoring
example.com.    TXT    "v=spf1 include:spf.protection.outlook.com ~all"

; Move to -all after confirming all senders are included
example.com.    TXT    "v=spf1 include:spf.protection.outlook.com -all"

3. Monitor SPF Results

Use DMARC reports to monitor SPF pass/fail rates before enforcing strict policies.

4. Only One SPF Record Per Domain

Multiple SPF records cause authentication failures:

; WRONG - Two SPF records
example.com.    TXT    "v=spf1 include:_spf.google.com -all"
example.com.    TXT    "v=spf1 include:sendgrid.net -all"

; CORRECT - Combined into one
example.com.    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net -all"

5. Watch the DNS Lookup Limit

Track lookups for each client:

# Check SPF record
dig TXT example.com | grep spf

# Use online tools to count lookups
# - mxtoolbox.com/spf.aspx
# - dmarcanalyzer.com/spf/checker

6. Document Everything

For each client domain, track:

  • All email-sending services
  • Complete SPF record
  • DNS lookup count
  • Last verification date

7. Use Unified DNS for Visibility

Managing SPF across dozens of client domains is challenging. Unified DNS lets you:

  • View all SPF records across all clients in one dashboard
  • Detect SPF misconfigurations automatically
  • Monitor for unauthorized changes
  • Maintain documentation synced to Hudu

Troubleshooting SPF

SPF Failing for Legitimate Email

Check if sender IP is authorized:

# Find the sending IP from email headers
# Look for "Received: from" lines

# Verify SPF includes that IP
dig TXT example.com | grep spf

Common causes:

  • New email service not added to SPF
  • IP address changed
  • Marketing platform sends from different IPs

Too Many DNS Lookups

Symptoms:

  • SPF returns PermError
  • Email marked as spam despite “correct” SPF

Solutions:

  1. Replace include: with ip4: for static IPs
  2. Remove unused services
  3. Use SPF flattening (convert includes to IP lists)

Multiple SPF Records

Check for duplicates:

dig TXT example.com | grep -c "v=spf1"
# Should return 1

Fix: Combine all SPF statements into a single record.

Testing SPF

# Query SPF record
dig TXT example.com

# Check SPF with specific IP
# Use online tools like:
# - mxtoolbox.com/spf.aspx
# - kitterman.com/spf/validate.html

Frequently Asked Questions

What’s the difference between SPF, DKIM, and DMARC?

  • SPF — Verifies the sending server is authorized
  • DKIM — Verifies the email hasn’t been modified (digital signature)
  • DMARC — Policy that combines SPF and DKIM, plus reporting

All three work together for complete email authentication.

Should I use -all or ~all?

  • -all (hard fail) — Recommended for production. Unauthorized email is rejected.
  • ~all (soft fail) — Use during testing or if forwarding breaks with -all.

What happens if I don’t have an SPF record?

Without SPF, receiving servers have no policy to check. Your domain is more vulnerable to spoofing, and your legitimate email may be treated with suspicion.

Can SPF alone prevent email spoofing?

No. SPF only checks the envelope sender, not the visible “From” header. Attackers can still spoof the “From” header while passing SPF. You need DMARC for complete protection.

How do I know if my SPF record is working?

  1. Send a test email to Gmail
  2. View original message (three dots menu → “Show original”)
  3. Look for “SPF: PASS” in the authentication results

What is SPF flattening?

SPF flattening converts include: mechanisms to their underlying IP addresses, reducing DNS lookups. Services like Auto SPF or SPF Surveyor automate this process.


Get Started with Unified DNS

SPF records are critical for email security, but managing them across dozens of client domains is complex. Unified DNS lets you view, modify, audit, and backup SPF records across all your clients — with automated monitoring for misconfigurations, DNS lookup limit tracking, and Hudu documentation syncing built in.

Unified DNS is live — try it free for a month with code FREETRIAL2026 at billing setup. No commitment. Or request a demo for a walkthrough.