Free tool

SPF Record Checker

Verify your SPF record syntax, count DNS lookups, and catch authorization gaps before your emails fail authentication.

What is an SPF record?

An SPF (Sender Policy Framework) record is a DNS TXT record that specifies which mail servers are authorized to send email on behalf of your domain. When a receiving server gets a message from your domain, it checks your SPF record to verify the sending server is legitimate.

Think of an SPF record as a guest list for your domain's email. It tells the rest of the internet: these specific servers are allowed to send mail as us, and anything else claiming to be from our domain is probably fake.

Without an SPF record, any server in the world can send email pretending to be from your domain. Phishing, spam, and spoofing all become trivially easy. With one in place, receiving servers can check incoming messages against your approved list and flag or reject anything that doesn't match.

Where SPF records live

SPF records are stored as TXT records in your domain's DNS settings. You manage them wherever you manage DNS: your registrar (GoDaddy, Namecheap, Cloudflare) or your hosting provider's DNS panel.

Every domain can have only one SPF record. It's a single line of text that starts with v=spf1 and lists your approved sending sources. Run your domain through the checker above to see exactly what yours looks like right now.

How SPF records work

SPF authentication happens behind the scenes every time someone sends email from your domain:

1
An email is sent from your domain
Someone or something sends a message with your domain in the From address - you from Gmail, your sequencer sending a campaign, your CRM firing a follow-up.
2
The receiving server extracts the sending IP
When the email arrives at Gmail, Outlook, or Yahoo, the server looks at the IP address of the server that actually transmitted it.
3
The receiving server queries your SPF record
It performs a DNS lookup on your domain and pulls the TXT record starting with v=spf1 - the exact lookup this tool does for you above.
4
It checks the sending IP against your record
The server compares the sending IP against every authorized source in your SPF record. Does it belong to Google's mail servers? One of SendGrid's IPs?
5
It returns a result
Based on the match, SPF produces a Pass (authorized), Fail (reject), SoftFail (accept with suspicion), or Neutral (no claim).

Example SPF records

SPF records look cryptic but follow a simple structure: a version tag, a list of authorized sources, and an enforcement level.

Google Workspace only
v=spf1 include:_spf.google.com ~all
Google Workspace + SendGrid
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Multiple providers with a dedicated IP
v=spf1 ip4:203.0.113.50 include:_spf.google.com include:sendgrid.net ~all

The 10 DNS lookup limit

RFC 7208 caps SPF at 10 DNS lookups per evaluation. This is the number one issue this checker flags. include:, a, mx, redirect= and exists: each cost a lookup (plus any nested lookups inside them); ip4:, ip6: and all cost nothing. Go over 10 and your entire SPF record becomes invalid (PermError).

Lookup countStatus
1 - 7Safe
8 - 9Close to the limit
10At the limit
11+Invalid (PermError)

How to fix too many DNS lookups

Remove unused includes - audit every include: and drop anything you no longer send through.

Replace includes with IP addresses. If a service sends from a small fixed set of IPs, use ip4: entries instead of an include: to eliminate the lookup.

Flatten your SPF record, which resolves all includes down to their underlying IPs. Consolidate providers where you can, and move different email types to subdomains - each subdomain gets its own SPF record with its own 10-lookup budget.

SPF syntax explained

An SPF record is a version tag, a list of authorized-sender mechanisms, and one enforcement rule at the end. Here is what each part means.

MechanismWhat it does
v=spf1Version tag. Mandatory and must come first. There is no SPF version 2.
ip4:203.0.113.10Authorizes a single IPv4 address. Use ip4:203.0.113.0/24 for a whole range.
ip6:2001:db8::1Authorizes a single IPv6 address.
include:_spf.google.comTrusts another domain's SPF record. Each include costs one DNS lookup (plus any nested ones).
a / mxAuthorizes the domain's own A record or its MX hosts. Each costs a lookup.
~allSoft fail (recommended): flag unlisted senders but still accept. -all rejects, ?all makes no claim, +all authorizes everyone and is a security hole.

How to read your SPF results

When a receiver evaluates your SPF record, it returns one of these results. The checker above tells you which one your record produces.

ResultWhat it means
PassThe sending IP is authorized. Mail authenticates cleanly.
Fail (-all)The IP is not authorized and your policy says reject. The message may be bounced.
SoftFail (~all)The IP is not authorized but you asked receivers to accept and flag. Often lands in spam.
Neutral (?all)You make no assertion. The failure is effectively ignored.
PermErrorThe record is broken: too many lookups, a syntax error, multiple SPF records, or a circular include. SPF does not work at all.
TempErrorA transient DNS problem. Usually resolves itself on retry.

Common problems and provider includes

Most SPF failures are one of a handful of issues. If a sending service is missing, add its include: mechanism from the list below - but watch the 10-lookup budget.

Provider or problemFix
No SPF record foundPublish one, e.g. v=spf1 include:_spf.google.com ~all
Record uses +allChange to ~all or -all immediately. There is no legitimate use for +all.
Multiple SPF recordsCauses PermError. Merge every authorized source into a single record.
Google Workspaceinclude:_spf.google.com
Microsoft 365include:spf.protection.outlook.com
SendGrid / Mailgun / Amazon SESinclude:sendgrid.net, include:mailgun.org, include:amazonses.com

SPF vs DKIM vs DMARC

SPF is one third of email authentication. You need all three working together for deliverability.

SPF - who can send

Verifies the sending server is authorized for your domain. Weakness: it breaks when mail is forwarded.

DKIM - message integrity

Adds a cryptographic signature proving the message wasn't tampered with. Survives forwarding.

DMARC - the policy layer

Ties SPF and DKIM together with alignment checks and tells receivers what to do when authentication fails.

Frequently asked questions

What is an SPF record?

An SPF record is a DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. It helps prevent spoofing by giving receiving servers a way to verify that incoming mail actually came from a server you approved.

What is SPF alignment?

SPF alignment means the domain SPF authenticates (the Return-Path / envelope-from domain) matches your visible From domain. DMARC requires alignment, which is why a message can pass SPF yet still fail DMARC if the two domains differ.

How do I check my SPF record?

Enter your domain in the checker at the top of this page. It pulls your SPF record from DNS, validates the syntax, counts your DNS lookups, and shows every authorized sending source. You can also check manually with dig or nslookup in a terminal.

What does SPF softfail mean?

A softfail (~all) means the sending server isn't listed in your SPF record, but your policy says to accept the email anyway while treating it with suspicion. In practice, softfailed mail often lands in spam. Most domains use ~all as a safe default.

How many DNS lookups can an SPF record have?

SPF is limited to 10 DNS lookups per RFC 7208, counting every include:, a, mx, redirect= and exists: mechanism plus any nested lookups. Exceeding 10 makes the whole record invalid (PermError).

Do I need an SPF record?

Yes. Email technically works without one, but your messages are far more likely to land in spam or be rejected. Google and Yahoo now require SPF authentication for bulk senders.

Can I have multiple SPF records?

No. The spec requires exactly one SPF TXT record per domain. Multiple records return a PermError and SPF fails entirely. Merge all your authorized sources into a single record.

How long do SPF changes take to propagate?

Usually 1 to 4 hours, but full global propagation can take up to 48 hours depending on your TTL and DNS caching. If the checker still shows the old record, wait a few hours and try again.

Next steps

Stop configuring DNS by hand

Cladiant provisions real Google Workspace, Microsoft 365, and Azure Entra mailboxes with SPF, DKIM, and DMARC written and verified on every domain before a single message sends. No DNS headaches, no authentication gaps, one invoice.