Free DNS & email authentication diagnostics — and the fix.

SPF Record Checker

Verify your domain's SPF record and the servers authorized to send mail.

Looks up your domain's SPF (TXT) record and explains it in plain English.

Generate an SPF record

Build a valid SPF record for your domain. Pick your mail provider and any additional services that send on your behalf.

The service that hosts your primary email inbox.
Check any tools you use for marketing, transactional, or newsletter mail.
~all marks unauthorized mail as suspicious. -all tells receivers to reject it outright — only use once you're sure all your senders are listed.

What is SPF?

SPF (Sender Policy Framework) is a DNS record that tells receiving mail servers which IP addresses and servers are authorized to send email on behalf of your domain.

When a message arrives claiming to be from [email protected], the receiving server checks your domain's SPF record. If the sending server's IP appears in your authorized list, the message passes SPF. If not, it may be rejected or marked as spam depending on the policy you've set.

What this checker tests

  • Whether your domain has an SPF record at all
  • Whether the record is properly formatted
  • How many DNS lookups it uses (RFC limit is 10)
  • What policy is enforced (hard fail, soft fail, neutral, or permissive)
  • Whether multiple SPF records exist (a common misconfiguration)
  • Which sending services (Google, Microsoft 365, SendGrid, etc.) are authorized

Common SPF errors and what they mean

Multiple SPF records

RFC 7208 requires exactly one SPF record per domain. If your domain has two or more v=spf1 records, receiving servers will return a PermError and mail may be rejected. The fix is to merge them into a single record with all your include: statements combined.

Too many DNS lookups

SPF allows a maximum of 10 DNS-lookup mechanisms (include:, a, mx, exists, redirect). Exceeding this causes a PermError. If you're over the limit, consider flattening some include: statements to ip4:/ip6: entries directly, or removing services you no longer use.

Soft fail vs. hard fail

The all mechanism at the end of an SPF record sets the default policy. ~all means "soft fail" — messages from unauthorized servers should be accepted but marked as suspicious (usually spam). -all means "hard fail" — reject unauthorized senders outright. +all means "accept everything" and is almost always a misconfiguration.

No SPF record

If your domain doesn't have an SPF record, receiving mail servers can't verify whether messages claiming to come from your domain are legitimate. This significantly reduces deliverability — many providers will mark unsigned mail as spam or reject it. Gmail and Yahoo now require SPF for bulk senders.

Frequently Asked Questions

Where do I publish my SPF record?

SPF is published as a TXT record at your domain's root (example.com). Most DNS providers — Cloudflare, GoDaddy, Google Domains, Namecheap, Hover — let you add or edit TXT records from their DNS management panel.

How long does it take for SPF changes to take effect?

DNS changes propagate based on the TTL (time-to-live) of your existing TXT record. This is usually 5 minutes to 1 hour but can be up to 24 hours. After publishing, you can re-run this check to verify.

Do I need SPF if I already have DMARC?

Yes. DMARC builds on top of SPF and DKIM — it requires at least one of them to pass. SPF and DKIM are the underlying authentication methods; DMARC is the policy layer that tells receivers what to do when authentication fails.

What is the difference between ~all and -all?

~all (soft fail) tells receivers to accept the message but treat it with suspicion — typically routed to spam. -all (hard fail) tells receivers to reject the message outright. Hard fail is stricter and reduces spoofing risk, but can cause legitimate forwarded mail to be lost when intermediate servers rewrite the sender.

Can I have more than one SPF record for the same domain?

No. RFC 7208 explicitly allows only one SPF record per domain. Multiple v=spf1 records cause a PermError at evaluation time, and most receivers will reject mail. To authorize multiple services, combine them into a single record using one include: per service.

Why does my SPF record have so many DNS lookups?

Each include: statement requires the receiver to fetch another SPF record, and that nested record's own lookups count too. Microsoft 365's spf.protection.outlook.com, for instance, counts as one direct lookup but chains internally. If you're over the 10-lookup limit, flatten unused services to ip4: ranges or drop services you no longer send from.

Want the full picture? Run a complete Domain Check →