SPF Checker

About the SPF Checker

This SPF checker resolves a domain's TXT records, isolates the one starting with v=spf1, and parses it mechanism by mechanism: include, a, mx, ip4, ip6, ptr, exists and redirect. It counts the mechanisms that trigger their own DNS lookup against the RFC 7208 ceiling of 10, since a record that goes over that limit does not just look messy, it fails outright with a permerror the moment a receiving mail server evaluates it. It also reads the all qualifier at the end of the record so you can see at a glance whether unauthorized senders are soft-failed, hard-failed, or waved through.

Use it whenever you add a new sending provider and need to check the record still fits under the lookup budget, when a message is bouncing or landing in spam and you suspect SPF is the cause, or as a first pass before setting up DMARC, since DMARC's SPF alignment only means anything once the underlying record is correct. Sender Policy Framework exists to tell receiving servers exactly which machines are allowed to send mail as your domain, and a broken record either blocks legitimate mail or leaves the door open to spoofing.

The lookup runs on our server against public resolvers and reads only the TXT record your domain already publishes, which is public DNS data by definition. Nothing about the domain you enter is stored or logged beyond serving that one result, and no email is sent or read. That is also why this is a good first stop before the DMARC checker and the composite mail-deliverability tool: SPF is usually the record that changes most often as you add or drop sending providers, and it's the easiest one to quietly break.

How to use it

1. Enter the domain you send mail from and submit.
2. The tool resolves the domain's TXT records and pulls out the one that starts with v=spf1.
3. Read the parsed mechanism list to see every include, a, mx, ip4/ip6, exists and redirect entry in order.
4. Check the DNS-lookup count against the limit of 10; going over means the record will hit a permerror in production.
5. Confirm the all qualifier at the end matches your intended policy, typically ~all while testing and -all once confirmed clean.
6. Fix any warning, such as a second SPF record or a missing all mechanism, then re-run to confirm a clean result.
7. Move on to the DMARC and DKIM checkers so the full authentication stack is verified, not just SPF on its own.

Examples

• v=spf1 include:_spf.google.com ~all -> Google Workspace as the sole sender, one DNS lookup, soft-fail default.
• v=spf1 include:sendgrid.net include:_spf.google.com include:spf.protection.outlook.com include:mailgun.org ~all -> four providers stacked, four lookups counted at the top level, still under 10 but each include's own record adds more downstream.
• v=spf1 +all -> flagged immediately: this authorizes any server on the internet to send as the domain.
• Two separate TXT records that both start with v=spf1 on one domain -> flagged as invalid, RFC 7208 permits exactly one.
• v=spf1 a mx include:_spf.google.com -all -> three lookup-triggering mechanisms (a, mx, include) with a hard-fail policy.
• A domain with no v=spf1 TXT record at all -> flagged so mail can be forged as that domain with no SPF check to catch it.

Which mechanisms count toward the 10-lookup limit

RFC 7208 caps SPF evaluation at 10 mechanisms that require their own DNS lookup, specifically to stop a single mail delivery from turning into an unbounded chain of queries against the receiving server. Not every mechanism costs a lookup though, and mixing the two up is the single most common reason a record looks short but still fails.

• include: counts, it fetches and evaluates another domain's SPF record, usually the biggest contributor
• a and a:domain count, each resolves the domain's A/AAAA records
• mx and mx:domain count, and can cost more than one lookup if the domain has several MX hosts
• ptr and ptr:domain count, and RFC 7208 itself discourages this mechanism as slow and unreliable
• exists: counts, typically used with macros for existence checks against a constructed hostname
• redirect= counts, it hands off evaluation to another domain's record entirely
• ip4: and ip6: do not count, a literal address needs no lookup to evaluate
• all does not count, it is the final catch-all qualifier, not a lookup mechanism

Why the lookup count here is a floor, not a ceiling

This checker counts the mechanisms written directly in your domain's own record. It does not recursively open every include's record and add up what that record itself spends, because that would mean resolving an unbounded chain of third-party domains on every check. RFC 7208's real 10-lookup limit is evaluated recursively across the whole chain a receiving server actually walks, so three includes that look cheap in this tool's count can easily push you over the limit once each provider's own SPF record, which often nests further includes for its own infrastructure, is added in. If a domain sends through several providers and the total looks close to 10, check each included provider's own record depth as well, not just what shows up here.

Qualifier reference

The character in front of all sets what a receiver should do with mail that fails every other mechanism.

• -all: hard fail. Tells receivers to reject unauthorized senders outright. The target state for a mature, fully mapped record.
• ~all: soft fail. Marks unauthorized mail as suspicious but most receivers still accept it. The common default while a new sender is being verified.
• ?all: neutral. Explicitly states no policy either way. Rare, and provides no real protection.
• +all: pass. Authorizes literally any server to send as the domain. Effectively disables SPF and should never appear in production.

Mistakes this checker flags

• Two SPF records on one domain: invalid per RFC 7208, receivers may reject the mail or pick unpredictably between them.
• Adding a new provider's include without removing an old one, quietly pushing the record past 10 lookups.
• Leaving ~all in place indefinitely instead of moving to -all once every legitimate sending path is confirmed.
• Copying +all from an old tutorial or forum post, which disables the protection SPF exists to provide.
• Assuming a subdomain inherits the parent's SPF record. It does not. Mail.example.com needs its own v=spf1 record if it sends mail.

Frequently asked questions