ToolNimba

๐Ÿ“ง SPF Checker

Shihab Mia By Shihab Mia ยท Updated 2026-06-29

Enter a domain such as , or . Lookups run in your browser over secure DNS, nothing is sent to our servers.

Enter a domain and click Check SPF to look up its SPF record.

This SPF checker looks up the SPF record of any domain straight from public DNS and explains it line by line. Type a domain such as google.com, click Check SPF, and the tool fetches the domain's TXT records, finds the one that begins with v=spf1, shows the raw record, and breaks down every part: include, ip4, ip6, a, mx, and the all qualifier. The whole lookup runs in your browser over secure DNS, with no sign-up, no API key, and no cost.

What is the SPF Record Checker?

An SPF checker is a tool that reads a domain's Sender Policy Framework record and tells you, in plain language, which mail servers are allowed to send email on that domain's behalf. SPF is one of the three core email authentication standards, alongside DKIM and DMARC, and it works by publishing a list of authorised senders as a special DNS TXT record. When a receiving server gets a message claiming to be from your domain, it looks up that SPF record and checks whether the sending server is on the list. If it is, the message passes SPF; if it is not, the record's "all" rule decides what happens. An SPF checker simply performs that same lookup for you and decodes the result.

Understanding why SPF matters starts with how easy email spoofing is. The "From" address on an email is just text and can be forged by anyone. Without SPF, a spammer can send mail that appears to come from your domain, damaging your reputation and tricking your customers. SPF closes part of that gap by letting receiving servers verify the sending source against your published list. A correct SPF record, combined with DKIM and a DMARC policy, dramatically reduces spoofing and improves the chance that your legitimate mail lands in the inbox rather than the spam folder. This is exactly why running a domain through an SPF checker is a routine step in any email deliverability audit.

The anatomy of an SPF record is straightforward once you have seen a few. Every record is a single string that starts with v=spf1 and is built from mechanisms separated by spaces. The most common mechanism is include, which trusts another domain's SPF policy; for example, include:_spf.google.com authorises all of Google's sending servers, which is what you add when you send through Google Workspace. The ip4 and ip6 mechanisms list specific addresses or ranges, the a and mx mechanisms authorise the servers named in your A and MX records, and the record finishes with an all mechanism that decides the fate of everything not matched. Our SPF checker labels each of these so you never have to memorise the syntax.

The "all" mechanism at the end is the single most important part to get right, and it is where this SPF checker focuses your attention. A trailing -all (hard fail) tells receivers to reject any mail from a server you have not listed, which is the strongest, recommended setting once your record is complete and tested. A ~all (soft fail) tells receivers to accept such mail but treat it as suspicious, which is a sensible choice while you are still adding senders. A ?all is neutral and gives almost no protection, and a +all allows literally any server to send as your domain, which defeats the entire purpose of SPF and should never appear in a real record. The SPF checker reads your qualifier and tells you in plain words what it means.

A subtle but critical detail that catches many people out, and that this SPF checker explicitly counts, is the 10 DNS-lookup limit. The SPF specification says a record may trigger at most 10 DNS lookups when it is evaluated. Mechanisms like include, a, mx and redirect each cost a lookup, and a single include can chain into several more. If your record exceeds 10 lookups, receiving servers return a permerror and may treat your mail as if SPF were not configured at all, silently hurting deliverability. Because the limit is invisible in the raw record, the SPF checker calculates it for you and warns you when you are close to or over the cap, which is a problem that grows quietly as you add more email providers over time.

Finally, it helps to know what an SPF checker cannot do on its own. SPF only validates the envelope sender (the Return-Path) and does not stop a spoofer from forging the visible "From" address unless DMARC is also in place. That is why modern email security treats SPF, DKIM and DMARC as a set: SPF authorises sending servers, DKIM cryptographically signs the message, and DMARC ties them together and tells receivers what to do on failure. Use this SPF checker to confirm your SPF record exists, is syntactically correct, ends with a sensible all policy and stays under the 10-lookup limit, then pair it with DKIM and DMARC for full coverage.

When to use it

  • Setting up a new domain for email: run the domain through the SPF checker after publishing your record to confirm it parses correctly and authorises the right providers before you send your first campaign.
  • Diagnosing emails landing in spam: a missing, broken or too-permissive SPF record is a common cause of poor deliverability, so an SPF record lookup is one of the first checks to run.
  • Adding a new email provider: when you start using a new marketing platform or CRM, use the SPF checker to verify the new include was added and that you are still under the 10 DNS-lookup limit.
  • Auditing a client or acquired domain: quickly see whether SPF exists, what its all policy is, and which third-party senders are authorised, all in one SPF record check.
  • Confirming a DNS change propagated: after editing the TXT record, re-run the SPF checker until the new value appears, which confirms the change has gone live in public DNS.
  • Hardening against spoofing: review the all qualifier with the SPF checker and tighten a weak ~all or ?all toward -all once you are confident every legitimate sender is listed.

How to use the SPF Record Checker

  1. Type or paste the domain you want to inspect into the box, for example google.com. You can leave off the "https://" and "www." parts, the SPF checker cleans the input for you.
  2. Click the "Check SPF" button, or press Enter. The tool queries the domain's TXT records over DNS-over-HTTPS directly from your browser.
  3. Read the raw SPF record shown at the top of the result. This is the exact TXT value published in the domain's DNS, starting with v=spf1.
  4. Scan the summary tiles to see how many terms the record has, how many of the 10 allowed DNS lookups it uses, and what the final "all" policy is (hard fail, soft fail, neutral or pass).
  5. Read the breakdown table, where the SPF checker explains every mechanism in plain English, so you know exactly which servers each include, ip4, mx or a entry authorises.
  6. Use the "Copy record" button to grab the raw record for a ticket or email, then edit the box and check another domain to compare or to confirm a change has propagated.

Formula & method

An SPF record is a single DNS TXT record that begins with the tag v=spf1, followed by a list of mechanisms separated by spaces, and usually ending with an "all" mechanism. This SPF checker reads that record and evaluates it the way a receiving mail server would. The version tag v=spf1 must come first. After it, each mechanism authorises one or more sending sources: "ip4:198.51.100.0/24" allows an IPv4 address or range, "ip6:2001:db8::/32" allows an IPv6 range, "a" allows the IP addresses in the domain's A and AAAA records, "mx" allows the servers in its MX records, and "include:_spf.example.com" pulls in and trusts the entire SPF policy of another domain (this is how providers like Google Workspace or Microsoft 365 delegate sending). Each mechanism carries an implicit or explicit qualifier: "+" means pass (the default), "-" means hard fail, "~" means soft fail, and "?" means neutral. The final term is almost always "all", which catches every source not matched earlier: "-all" rejects them, "~all" marks them as soft fail (suspicious but accepted), "?all" is neutral, and "+all" would allow anything and must never be used. A critical rule the SPF checker also flags is the 10 DNS-lookup limit: the mechanisms include, a, mx, ptr, exists and redirect each cost a DNS lookup, and SPF allows at most 10 in total before a receiver returns a permerror, which can break email authentication entirely.
How an SPF checker reads a recordv=spf1 include:_spf.google.com ip4:198.51.100.0/24 mx ~allv=spf1version taginclude:_spf.google.comtrust Google sendersip4:198.51.100.0/24allow this IP rangemxallow MX hosts~allsoft fail othersReceiving server checks the sending IPListed = pass, not listed = soft fail (~all)

Worked examples

You manage a domain that sends all its mail through Google Workspace and want to confirm the SPF record is correct.

  1. Enter the domain (for example google.com) and click Check SPF.
  2. The SPF checker fetches the TXT records and finds the one starting with v=spf1.
  3. It shows the raw record, then explains each part: the include mechanisms that trust Google's sending infrastructure, and the trailing all qualifier.

Result: You see a valid SPF record such as "v=spf1 include:_spf.google.com ~all", with the include labelled as delegating to Google and ~all labelled as soft fail, confirming the setup is sound.

You suspect a domain has no SPF protection at all and email from it is being spoofed.

  1. Enter the domain and click Check SPF.
  2. The tool queries the TXT records but finds none that begin with v=spf1.
  3. The SPF checker reports that no SPF record was found.

Result: The tool clearly states no SPF record exists, warns that anyone can spoof email from the domain, and suggests adding a starter record like "v=spf1 include:_spf.google.com ~all".

A domain uses many email providers and mail has started failing authentication for no obvious reason.

  1. Enter the domain and click Check SPF.
  2. The record is found and displayed, but the DNS-lookups tile shows 12 / 10.
  3. The SPF checker flags that the record exceeds the 10-lookup limit.

Result: You get a red warning that the record triggers more than 10 DNS lookups, which causes a permerror at receiving servers, telling you to consolidate or flatten the record before adding anything more.

SPF mechanisms this SPF checker recognises and explains

MechanismExampleWhat it authorises
includeinclude:_spf.google.comTrusts the entire SPF policy of another domain (used to delegate to providers)
ip4ip4:198.51.100.0/24A specific IPv4 address or range
ip6ip6:2001:db8::/32A specific IPv6 address or range
aa or a:mail.example.comThe IP addresses in the domain's A and AAAA records
mxmxThe mail servers listed in the domain's MX records
all-all or ~allThe catch-all rule for every sender not matched above

What the "all" qualifier means in an SPF record

QualifierNameEffect on unlisted sendersRecommended?
-allHard failReject the mail outrightYes, once the record is complete
~allSoft failAccept but mark as suspiciousYes, while testing
?allNeutralNo opinion, almost no protectionNo
+allPassAllow any server to send as youNever use this

Common mistakes to avoid

  • Publishing more than one SPF record. A domain must have exactly one SPF record. Two or more TXT records starting with v=spf1 make SPF invalid (a permerror), so merge them into a single record. Run the SPF checker to confirm only one is returned.
  • Exceeding the 10 DNS-lookup limit. Every include, a, mx and redirect costs a DNS lookup, and the cap is 10. Go over it and receivers return a permerror, treating your mail as unauthenticated. This SPF checker counts the lookups so you can spot the problem.
  • Leaving the record on +all. A trailing +all allows any server on the internet to send as your domain, completely defeating SPF. Always end with -all (hard fail) or ~all (soft fail) instead.
  • Forgetting to list a legitimate sender. If you send through a tool that is not in the record, its mail will fail SPF. After adding any new provider, use the SPF checker to confirm the matching include or ip4 entry is present.
  • Putting the SPF record in the wrong place. SPF is a TXT record on the root domain (or relevant subdomain), not a separate "SPF" record type, which is deprecated. If the SPF checker finds nothing, confirm you added a TXT record, not a legacy SPF type.
  • Assuming SPF alone stops spoofing. SPF only checks the envelope sender, not the visible From address. Without DMARC, a spoofer can still forge the From line. Treat the SPF checker result as one layer alongside DKIM and DMARC.

Glossary

SPF checker
A tool that looks up a domain's SPF record from DNS and explains its mechanisms and policy, used to verify which servers may send email for the domain.
SPF (Sender Policy Framework)
An email authentication standard that publishes, as a DNS TXT record, the list of servers allowed to send mail for a domain.
SPF record
The single DNS TXT record, starting with v=spf1, that holds a domain's SPF policy as a list of mechanisms.
Mechanism
A term inside an SPF record (such as include, ip4, a, mx or all) that authorises a set of sending sources or sets the catch-all rule.
include
A mechanism that trusts the entire SPF policy of another domain, used to delegate sending to providers like Google or Microsoft.
all qualifier
The final mechanism in an SPF record (-all, ~all, ?all or +all) that decides what happens to senders not matched by earlier mechanisms.
DNS-lookup limit
The SPF rule that a record may trigger at most 10 DNS lookups; exceeding it causes a permerror and breaks authentication.
DMARC
A policy standard built on top of SPF and DKIM that tells receivers how to handle messages that fail authentication and where to send reports.

Frequently asked questions

What is an SPF checker?

An SPF checker is a free tool that looks up a domain's SPF record from DNS and shows it to you decoded. It finds the TXT record starting with v=spf1, displays the raw value, and explains every mechanism (include, ip4, mx, a) and the final all policy in plain English, so you can confirm which servers may send email for the domain.

How do I check my SPF record?

Enter your domain in the SPF checker above and click Check SPF. The tool performs an SPF record lookup directly in your browser, retrieves your TXT records, finds the SPF one, and breaks it down. No sign-up or API key is needed, and the lookup is free and instant.

What does a good SPF record look like?

A good SPF record starts with v=spf1, lists only the senders you actually use (via include, ip4, a or mx), stays under the 10 DNS-lookup limit, and ends with -all or ~all. A typical example is "v=spf1 include:_spf.google.com ~all". Run it through the SPF checker to confirm it parses cleanly.

What does the SPF checker do when no SPF record is found?

If the domain has no TXT record beginning with v=spf1, the SPF checker clearly states that no SPF record was found and warns that the domain is open to email spoofing. It suggests a starter record you can publish, such as "v=spf1 include:_spf.google.com ~all".

What is the difference between ~all and -all?

Both are the final "all" mechanism. The -all (hard fail) tells receiving servers to reject mail from any server not listed in your record, which is the strongest setting. The ~all (soft fail) tells them to accept it but mark it as suspicious, which is safer while you are still building the record. The SPF checker labels whichever one your record uses.

Why does the SPF checker count DNS lookups?

SPF allows a record to trigger at most 10 DNS lookups when evaluated, and mechanisms like include, a, mx and redirect each cost one. Exceeding 10 causes a permerror, which can make all your mail fail authentication. Because the limit is hidden in the raw record, the SPF checker calculates and displays it for you.

Can a domain have more than one SPF record?

No. A domain must publish exactly one SPF record. If two or more TXT records start with v=spf1, SPF becomes invalid and returns a permerror. If you need entries from several providers, merge them into a single record using multiple include mechanisms, then verify with the SPF checker.

Does this SPF checker store my domain or need an API key?

No. The SPF checker runs entirely in your browser using public DNS-over-HTTPS. There is no account, no API key and no cost, and the domain you type is not sent to our servers or stored anywhere.

Is SPF enough to stop email spoofing on its own?

No. SPF only validates the envelope sender, not the visible From address, so a spoofer can still forge the From line unless DMARC is in place. Use the SPF checker to get SPF right, then add DKIM signing and a DMARC policy for full protection against spoofing.

How long do SPF record changes take to show in the SPF checker?

It depends on the TTL of your DNS records and caching, but changes usually appear within minutes to a few hours. After editing your TXT record, re-run the SPF checker periodically until the new value shows, which confirms the change has propagated in public DNS.