Can an SPF checker test a specific email?

No. A domain-only SPF checker reads public DNS policy. To verify a specific message, inspect the trusted receiver-added Authentication-Results header for the evaluated smtp.mailfrom identity, connecting IP, and SPF result.

Should I check the root domain or a subdomain?

Check the exact MAIL FROM or HELO identity used by the sending path. A custom return-path subdomain can publish a different SPF policy from the organizational domain, so the root domain is not always the correct lookup target.

Does a valid SPF record mean DMARC passes?

No. DMARC requires the SPF-authenticated domain to align with the visible From domain, or an aligned DKIM signature must pass. A valid public SPF record alone cannot prove message-level SPF or DMARC alignment.

Is SPF flattening always the right fix for too many lookups?

No. Remove retired senders and simplify ownership first. Flattening copies provider IP ranges into your record and can become stale when those ranges change, so it requires reliable monitoring and a named update owner.

Which SPF terms count toward the ten lookup limit?

The include, a, mx, ptr, and exists mechanisms and the redirect modifier consume DNS lookups. Nested counted terms use the same budget. The ip4, ip6, and all mechanisms and the exp modifier do not count toward the ten-term limit.

Free SPF Record Checker & Lookup

Enter a domain to find its SPF record, validate the syntax, trace nested includes, and count DNS lookups, free, no signup.

What is SPF?

SPF, or Sender Policy Framework, is a DNS-based email authentication method that lists which systems may use a domain in the SMTP envelope sender. A public record check shows the policy a receiver can discover. It does not prove that a particular message passed SPF or that the authenticated domain aligned for DMARC.

How to read your SPF result

Result	What it means	What to do
Valid record	The checker found one interpretable SPF policy for the submitted domain.	Confirm every mechanism belongs to an active sender and verify a real message separately.
No SPF record	No v=spf1 policy was found at the exact domain entered.	Confirm the MAIL FROM domain, then publish the record supplied by the systems that actually send mail.
Multiple SPF records	More than one v=spf1 policy exists at the same owner name, producing a permanent error.	Inventory every authorized sender and consolidate the mechanisms into one policy.
9 or 10 DNS lookups	The record is at or near the RFC 7208 ceiling and has little room for a provider-side change.	Remove retired senders and inspect the nested include chain before it becomes a permerror.
PermError or over 10	The policy cannot be evaluated reliably because of syntax, duplicate records, broken dependencies, or excess DNS work.	Fix the reported cause and retest; repeated delivery attempts will not repair a permanent policy error.
~all or -all	Softfail and fail express different authorization statements, but the receiving system chooses final handling.	Map every legitimate sender before tightening the qualifier, then validate production mail and DMARC alignment.

How to check SPF correctly

1. Identify the domain SPF actually used. Open the full headers of a delivered message and find the receiver-added smtp.mailfrom identity beside the SPF result. A provider-controlled return path or custom subdomain may be different from the visible From domain.
2. Submit that exact domain. Enter only the domain, without a mailbox, protocol, or path. If no message exists yet, use the domain in the sending provider's current setup instructions and treat the result as configuration evidence rather than a production-message test.
3. Read mechanisms and modifiers in order. Review ip4, ip6, a, mx, include, exists, all, and any redirect. An include runs another policy; it does not simply name a sender.
4. Inspect recursive DNS work. RFC 7208 allows at most ten lookup-causing terms across the complete evaluation. Nested terms spend from the same budget, so counting only the visible includes is not enough.

What this checker can prove

The checker proves what public DNS returns for the submitted name, whether one SPF policy can be parsed, and how its visible and nested mechanisms use the DNS lookup budget. Its interpretation follows RFC 7208. It cannot see a private sending inventory, know which identity a receiver evaluated unless you supply it, or guarantee inbox placement.

For Google Workspace, use the custom-domain MAIL FROM identity shown in the trusted message header. Google's SPF troubleshooting guidance likewise separates the public-DNS check from the actual message result.

Fix the result, then retest the message

Start with an inventory of corporate mail, marketing platforms, transactional systems, ticketing, billing, and devices. Remove retired senders before adding mechanisms or flattening includes. For an over-limit record, follow the SPF PermError repair sequence and keep a named owner for every dependency.

After authoritative DNS serves the change, run this lookup again. Then send a new message through each changed production path and verify the evaluated identity, connecting IP, SPF result, and visible From domain in a trusted Authentication-Results header. Check DMARC separately because an SPF pass for an unaligned return path does not produce an aligned DMARC pass.

Related SPF checks and repairs

What is SPF?SPF generator Fix too many DNS lookups SPF syntax DMARC checker Email security score