Network & DNS › Network & DNS Tools

SPF Record Checker

spf-checker

Validate your SPF record — parse mechanisms, check policy, and count DNS lookups.

Enter a target and run the tool.

About SPF Record Checker

An SPF (Sender Policy Framework) record is a DNS TXT entry that lists which mail servers are authorized to send email on behalf of your domain. Without an SPF record, any server on the internet can send a message with your domain in the From address and most receiving systems have no mechanism to reject it. With SPF in place, receiving mail servers can check the connecting server's IP against your published list of authorized senders and act on the result. The AT USE SPF Checker fetches your domain's TXT records via a live DNS-over-HTTPS resolver, identifies the v=spf1 record, parses every mechanism and qualifier, and returns a structured breakdown of what each part means — alongside the total DNS lookup count and a plain-English interpretation of your policy.

How SPF authentication works

When a message arrives at a receiving mail server, the server extracts the domain from the envelope-from address (the SMTP MAIL FROM command, which may differ from the visible From header). It queries the DNS TXT records for that domain looking for a record starting with v=spf1. It then checks whether the connecting server's IP matches any mechanism in the record: ip4: and ip6: specify explicit IP ranges; include: delegates to another domain's SPF policy (used by email service providers like Google Workspace, Outlook 365, Mailchimp, and SendGrid); a uses the domain's A records; mx uses the domain's mail exchanger records. The first matching mechanism determines the result. The qualifier on that mechanism sets the outcome: + is pass (default, usually omitted), - is fail, ~ is softfail, ? is neutral.

The all mechanism and policy strictness

The all mechanism at the end of an SPF record sets the default result for any IP that does not match earlier mechanisms. Its qualifier determines how strict the policy is. -all (hard fail) instructs receivers to reject messages from non-listed IPs. ~all (softfail) marks non-listed messages as suspicious but does not instruct rejection — most large mail providers treat softfail as a spam signal rather than a hard reject. +all (pass all) is effectively no protection and should never appear in a production record. ?all is neutral and provides no guidance. Most well-configured domains use -all once they are confident the record is complete; ~all is appropriate when still auditing which services send on the domain's behalf.

The 10 DNS lookup limit

RFC 7208 limits SPF evaluation to 10 DNS lookups per check. Mechanisms that each consume one lookup: include:, a, mx, exists:, and redirect=. ip4: and ip6: mechanisms do not consume lookups. The void lookup limit (lookups that return empty results) is set at 2. Exceeding 10 lookups causes receivers to return a permerror result, which most mail systems treat as an authentication failure — the same outcome as a missing SPF record. This limit is easy to exceed on domains that use multiple email service providers, each contributing an include: directive. The SPF checker counts your current lookup total so you can identify whether you are near or over the limit before deliverability problems appear.

Common SPF problems this tool detects

Duplicate SPF records: a domain must have exactly one TXT record starting with v=spf1. Two SPF records cause receiving servers to return a permerror. Stale include: directives: former email providers left in the record still consume lookup budget and may authorize IP ranges you no longer control. Missing record entirely: domains that receive mail but do not send it still benefit from v=spf1 -all to prevent their domain being used in spoofing attacks. Overly permissive +all or ~all on a domain that is ready for full enforcement.

Common use cases

  • Diagnosing email landing in spam or being rejected — A developer set up a transactional email service for an application and notices delivery rates are low. The SPF Checker shows the domain's SPF record is missing the include: mechanism for the sending service's IP range. The developer adds the missing include: directive, republishes the TXT record, and uses the checker to confirm it is visible and parses correctly before re-testing delivery.
  • Auditing SPF before migrating to a new email provider — A company switching from one mail provider to another needs to update their SPF record to add the new provider and remove the old one. Before making changes, an IT admin runs the SPF Checker to document the current record — all mechanisms, qualifiers, lookup count — so the migration has a baseline to compare against. After the change, they re-check to confirm the new record is live and the lookup count is within the RFC limit.
  • Checking DNS lookup count before it causes permerror — A marketing team uses three email service providers (one for newsletters, one for transactional email, one for cold outreach). Each provider requires an include: directive. The SPF Checker shows the current lookup count is 8 of 10, with two more being considered. The team knows they need to consolidate include: directives or switch to ip4: ranges before adding more services, to stay under the RFC 7208 limit.
  • Verifying a newly published SPF record is live — After publishing a new SPF record at a domain registrar, a sysadmin runs the SPF Checker against the domain using the live DNS-over-HTTPS resolver. Because it bypasses local DNS caches, the checker shows whether the new record has propagated to the public resolver. If the old record still appears, the TTL has not expired yet — the checker's result shows what the live resolver currently sees.

How to use this tool

  1. Enter the domain whose SPF record you want to check in the input field — for example, example.com. Do not include the protocol (https://) or a path.
  2. Click "Check SPF" to fetch and parse the SPF TXT record live from the DNS-over-HTTPS resolver.
  3. Review the raw record string and the parsed mechanism table, which lists each mechanism with its qualifier and what it authorizes.
  4. Check the DNS lookup count — if it is at or above 9, you are at risk of hitting the RFC 7208 permerror limit as DNS records change.
  5. Read the policy interpretation section for a plain-English summary of what your all mechanism means and any warnings flagged by the checker.

Frequently asked questions

What happens if a domain has no SPF record?

Receiving servers have no published list of authorized senders to check against. Most servers will accept the message but may apply spam scoring penalties for the missing authentication. Some stricter enterprise gateways reject or heavily penalize mail from domains with no SPF. Google and Microsoft's mail servers increasingly treat missing authentication records as a spam signal.

What is the difference between -all and ~all?

-all (hard fail) is an explicit instruction to receiving servers to reject messages from IPs not listed in the record. ~all (softfail) marks them as suspicious but does not mandate rejection. In practice, Gmail and Microsoft 365 treat both -all and ~all failures as spam signals — the real-world delivery difference is small for messages that fail. The semantic difference is what you are telling third-party receivers: -all is a confident assertion that only listed servers send for this domain.

Why is there a 10 DNS lookup limit?

RFC 7208 limits SPF to 10 DNS lookups per evaluation to prevent amplification attacks where a single SPF check causes a receiver to make dozens of recursive lookups. The limit applies to mechanisms that require a DNS query at check time: include:, a, mx, exists:, and redirect=. ip4: and ip6: are inline and do not consume lookups.

Can I have more than one SPF record on a domain?

No. RFC 7208 requires exactly one TXT record starting with v=spf1 per domain. If two SPF records exist, receiving servers must return a permerror result. Use a single record and combine all mechanisms into it, separated by spaces.

What does the SPF check result mean for DMARC?

SPF is one of two authentication mechanisms DMARC can evaluate (DKIM is the other). For an SPF result to satisfy DMARC, the envelope-from domain must match the From header domain (or its organizational domain) — this is called SPF alignment. A message can pass SPF but still fail DMARC if the envelope-from and From domains do not align. Use the DMARC Checker alongside this tool to see the full authentication picture.