What does the qualifier before a mechanism (like the - in -all) mean?

It's the result a receiving server applies when that mechanism matches: + (the default if omitted) means Pass, - means Fail (reject), ~ means SoftFail (accept but mark as suspicious), and ? means Neutral (treated as no opinion). On the terminal all mechanism, -all and ~all are the common choices for a domain that wants unauthorized senders rejected or flagged.

Why does SPF have a 10 DNS-lookup limit, and what happens if I go over it?

RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS lookups (each include, a, mx, exists, and redirect mechanism costs one) specifically to bound how much work a receiving server does per message and prevent abuse via deeply nested chains. A record that exceeds the limit fails evaluation with a PermError, which many receivers treat the same as a hard SPF failure.

Why is the lookup count here called a 'static count' rather than exact?

Each include: mechanism points to another domain's own SPF record, which can itself contain more include: chains, and counting those recursively would require following every nested lookup live. This tool counts only the lookup-causing mechanisms in the one record it fetched, so a record with includes could cost more real lookups once those are followed, or fewer if some point to short records.

What does 'no terminal all mechanism' mean, and why does it matter?

SPF evaluation stops at the first matching mechanism in a record, and all is written to match everything, so it's meant to go last and catch senders not covered by any earlier ip4/ip6/a/mx/include mechanism. Without one, evaluation reaches the end of the record with no match, which most receivers treat as Neutral, giving essentially no protection against unauthorized senders.

SPF Record Checker - Validate a Domain's SPF Record

Overview

Introduction

SPF answers one specific question: which mail servers are allowed to send email claiming to be from this domain, but a record that's misformatted or that quietly exceeds SPF's DNS-lookup budget fails silently for everyone relying on it.

This tool looks up a domain's SPF record, breaks its mechanisms apart with their qualifiers, and flags the issues that most commonly break SPF in practice.

What Is SPF Record Checker?

An SPF DNS record lookup and validator that queries a domain's TXT records for one starting with v=spf1 and parses its ip4/ip6/a/mx/include/all mechanisms individually.

It's part of this site's DNS & Domain Tools collection, alongside the DKIM and DMARC checkers that cover the other two legs of email authentication; the DNS lookup is a real, live query to a public resolver.

How SPF Record Checker Works

The domain itself (not a subdomain) is queried for its TXT records, and any records starting with v=spf1 are collected; more than one is flagged since only one is valid per RFC 7208.

The record's space-separated terms are split into a qualifier (+, -, ~, or ?) and mechanism, and the lookup-causing mechanisms (include, a, mx, exists, redirect) are counted against RFC 7208's limit of 10, alongside a check for a terminal all mechanism.

When To Use SPF Record Checker

Use it right after configuring or changing SPF with an email provider, to confirm the record actually published correctly and doesn't quietly exceed the lookup limit.

It's also useful when adding a new sending service (like a marketing or transactional email platform) via an include:, to check the combined lookup count before it breaks SPF for everyone.

Often used alongside DKIM Record Checker and DMARC Record Checker.

Features

Advantages

Breaks mechanisms into qualifier, type, and value instead of leaving you to parse one long space-separated string by eye.
Surfaces a DNS-lookup count against the RFC 7208 limit up front, a failure mode that's invisible just by reading the raw record text.

Limitations

The lookup count is a static count of this one record's mechanisms, not a true recursive resolution of nested include: chains, so it can under- or over-estimate the real total.
Only checks the DNS-published record, not whether an actual sending server's IP is currently covered by it.

Examples

A domain with a straightforward, valid SPF record

Input

domain: example.com

Output

Record found
No issues found
0/10 DNS lookups
-all

The record uses only ip4/ip6 mechanisms (no DNS-lookup cost) and ends with a hard-fail all, so no issues are flagged.

A record missing a terminal all mechanism

Input

domain: incomplete.example

Output

Record found
1 issue
No terminal 'all' mechanism found; ... provides no real protection here.

Without all, unauthorized senders that don't match any listed mechanism fall through to an implicit neutral result instead of being rejected or flagged.

Best Practices & Notes

Best Practices

Prefer ip4:/ip6: mechanisms over include: where possible, since only include (and a/mx/exists/redirect) cost a DNS lookup toward the limit of 10, while raw IP mechanisms are free.
End the record with -all (hard fail) once you're confident every legitimate sending source is listed; ~all (soft fail) is a reasonable interim step while still testing.

Developer Notes

Mechanism parsing strips a leading qualifier character only if it's one of +/-/~/?, then splits the remainder on the first ':' (or '=' for modifiers like redirect=), matching how the record reads left to right rather than assuming a fixed mechanism list, so unrecognized future mechanism types still parse into a name and value instead of being dropped.

SPF Record Checker Use Cases

Verifying an SPF record was published correctly right after configuring it with an email provider
Checking a combined lookup count before adding another include: for a new sending service
Debugging an SPF authentication failure by checking whether the domain's record even has a terminal all mechanism

Common Mistakes

Publishing a second SPF TXT record instead of merging mechanisms into the existing one, which most receivers treat as a PermError rather than combining both.
Chaining includes from multiple email platforms without checking the combined lookup count, quietly pushing the domain over SPF's 10-lookup limit.

Tips

Check DKIM and DMARC for the same domain alongside SPF, since all three are usually configured together and a DMARC policy's effectiveness depends on SPF (or DKIM) actually passing and aligning.

SPF Record Checker