SPF Records Test

What is it?

Sender Policy Framework is a DNS-based standard that lists the mail servers authorized to send email on behalf of a domain. Receiving mail servers use the SPF record to verify that incoming messages claiming to come from the domain are legitimate, which significantly reduces the chance of valid email being marked as spam and makes domain spoofing much harder for phishing campaigns. This test checks your domain's DNS for an SPF record and reports its contents so you can confirm the policy is correct and complete.

Why SPF still matters

Email deliverability has become an SEO-adjacent concern because many sites depend on transactional email for password resets, order confirmations, account verification, and customer communication. When your messages land in spam, conversions drop and trust in the brand erodes. SPF is one of the three core email authentication standards (alongside DKIM and DMARC) that mail providers use to decide whether to deliver, defer, or block messages from your domain.

SPF is also part of protecting your brand from spoofing. Without an SPF record, anyone can send email claiming to come from your domain, and receiving mail servers have no way to verify the claim. That makes your domain a tempting target for phishing campaigns that impersonate your brand to defraud your customers. A strict SPF policy makes spoofing much harder.

Common SPF issues

No SPF record at all, which leaves authentication unverified.
Multiple SPF records, which is invalid; SPF allows only one TXT record per domain.
Policy too permissive, ending in +all which authorizes anyone to send as your domain.
Missing legitimate senders, where transactional and marketing services are not in the include list.
Too many DNS lookups: SPF caps include lookups at ten, requiring consolidation when exceeded.

This test verifies your domain's SPF record. The fix guide below covers writing a correct SPF record, configuring it at the major DNS providers, integrating with email service providers, and pairing SPF with DKIM and DMARC for complete email authentication coverage.

Pass rate:

Top 100 websites: 94%
This value indicates the percent of top 100 most visited websites in the US that pass this test (in the past 12 months).
All websites: 68%
This value indicates the percent of all websites analyzed in SEO Site Checkup (500,000+) in the past 12 months.

Pass rates of Top 100 US websites
2021	94%
2022	97%
2023	95%
2024	94%

100

How do I fix it?

The Sender Policy Framework (SPF) DNS record lists the mail servers authorized to send email on behalf of your domain. Receiving servers use it to verify that messages claiming to come from your domain are legitimate, which significantly reduces the chance of email being marked as spam. Fixing this issue means publishing an SPF record in your DNS that includes every legitimate sender and ends with a strict policy.

Example

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

Where to make the change

DNS provider: add a TXT record at the domain root with the SPF policy. Cloudflare, Route 53, Namecheap, GoDaddy, and similar all expose a TXT record editor.
Email providers: Google Workspace, Microsoft 365, and most transactional email services publish their required SPF include directives in their setup documentation.

Common causes and how to resolve them

No SPF record at all: add one. Even a minimal record (v=spf1 include:_spf.google.com ~all) is better than nothing.
Multiple SPF records: SPF only allows one TXT record per domain. Merge multiple records into a single one with all required include: directives.
Policy too permissive: ending with +all authorizes anyone to send as your domain. Use ~all (soft fail) or -all (hard fail) instead.
Missing legitimate senders: add an include: for every transactional email service (SendGrid, Mailgun, Postmark) and every marketing platform you use.
Too many DNS lookups: SPF caps include lookups at ten. Flatten or consolidate include: chains if you exceed it.

Best practices

Pair SPF with DKIM and DMARC: SPF alone is not enough. DKIM signs messages cryptographically; DMARC tells receivers what to do when SPF or DKIM fails.
Start with ~all, move to -all: soft fail lets you observe before strict enforcement. Move to hard fail once you are confident no legitimate sender is missing.
Test deliverability: tools such as MXToolbox SPF check or Google Postmaster Tools surface SPF problems before users complain.
Audit annually: as you add or remove email vendors, the SPF record needs to keep up.