SPF Record Checker

Server assisted New DNS & Domains

Read the SPF TXT record of a domain and evaluate it the way a receiving mail server does: every include, redirect, a and mx term is resolved and counted against the RFC 7208 limit of ten DNS lookups, void lookups and loops are flagged, and the "all" term that decides unlisted senders is explained. A record you paste is parsed in your browser, so you can check it before you publish it.

Privacy: The name you look up is sent from the Mutqan server to the public DNS resolvers named in the results. Nothing is stored.

What is an SPF record?

An SPF record is a TXT record starting with v=spf1 that lists the servers allowed to send mail using a domain in the SMTP envelope (the Return-Path address). A receiving server compares the connecting address with the record's terms and gets pass, fail, softfail or neutral; to bound that work, RFC 7208 allows at most ten DNS lookups per evaluation, and exceeding them is a permerror.

How to use SPF Record Checker

  1. Type the domain of the sender address, such as example.com; a whole address like billing@example.com works too.
  2. Press Check SPF. The Mutqan server reads the domain's TXT records and follows every include and redirect.
  3. Read the summary: the result, the DNS lookups used out of 10, the void lookups and what happens to unlisted senders.
  4. Go through the lookup table, the errors and the warnings, fix the record at your DNS host and run the check again.
  5. To try a change before publishing it, paste the new record into the second field; it is parsed in your browser and nothing is sent.

SPF Record Checker features

  • A full RFC 7208 evaluation: include and redirect chains are followed, a and mx terms are resolved, ptr and exists are counted
  • The 10-lookup limit counted across the whole chain, with every lookup past the tenth listed but never queried
  • Void lookups (names that return no record — at most two are allowed), loops and include targets without SPF reported as permerror
  • Every term of the record with the result it gives when it matches (Pass, Fail, SoftFail, Neutral), whether it costs a DNS lookup and what it resolved to
  • The "all" that finally decides, after any redirect=, explained as what happens to mail from servers you did not list
  • A draft record pasted into the second field is checked in your browser before you publish it
  • Errors, warnings and next steps in plain language, each with the record or name it is about

Inputs and outputs

Inputs

  • Domain name — the domain of the envelope sender, typed as a name, an e-mail address or a URL; internationalised names are accepted.
  • Pasted SPF record (optional) — one record starting with v=spf1, plain or in quotes as copied from a zone file. When it is filled in, it is checked in your browser and no lookup is made.

Outputs

  • Summary — the result, DNS lookups used out of 10, void lookups out of 2, what happens to unlisted senders and, when there are several, the number of SPF records published.
  • Record — the SPF record found, the name checked, the redirect= target when the policy is delegated, and the number of DNS queries the check made.
  • Terms of the record — each term with its type, the result it gives when it matches, whether it costs a lookup and what it resolved to.
  • DNS lookups in order — every lookup of the whole chain with its depth and outcome, including the ones past the limit that were not queried.
  • Errors, Warnings and What to do next — each finding in plain language, with the name or term it concerns.

SPF Record Checker example

A domain whose SPF policy is one include (google.com, October 2026)

Input:

google.com

Output:

Result: Works, with warnings · DNS lookups: 1 / 10 · Void lookups: 0 / 2 · Unlisted senders: ~all (softfail: mail from unlisted servers is marked, not refused)
Record: v=spf1 include:_spf.google.com ~all
DNS lookups in order: 1 · include:_spf.google.com · _spf.google.com · depth 0 · SPF record found
Warnings: "~all" (softfail) asks receivers to accept but mark mail from unlisted servers; "-all" is the strict form. With DMARC enforced the difference is small.

How to read the SPF Record Checker results

No problems found: the record ends in -all, even a sender that matches no term before the end stays within 10 lookups and two void lookups, and there is nothing to warn about.

Syntax looks valid: shown instead for a pasted record that ends in -all with nothing to warn about. Its includes were not followed, so the full lookup count appears only when the published domain is checked.

Works, with warnings: receivers can evaluate the record, but something weakens it — usually ~all or ?all, a missing "all", a deprecated ptr term, or a DNS lookup that failed temporarily during the check.

Has errors: a receiver would stop with permerror (more than 10 lookups, two SPF records, a syntax error, an include without SPF, a loop), or "+all" lets every server pass. Many receivers then treat the domain as if it had no SPF.

DNS lookups: the count includes everything reached through include, so a three-term record can still use eight or nine lookups through one provider. A count of 8 or more leaves little room for the next service you add.

No SPF record: no TXT record starting with v=spf1 exists at the name. Receivers get the result "none", and DMARC can then pass only through DKIM.

When to use SPF Record Checker

  • Adding a new sending service — a CRM, a newsletter platform, a help desk — and checking that its include does not push the domain past 10 lookups.
  • Finding out why mail from one service fails SPF, or fails DMARC alignment, at Gmail or Outlook.
  • Reviewing a draft record before a change window, without publishing it.
  • Auditing parked and unused domains to confirm that they publish "v=spf1 -all".

Troubleshooting

  • "More than 10 DNS lookups": open the lookup table to see which include costs the most, remove services you no longer use, or replace the include of a provider that publishes fixed ranges with those ip4 and ip6 ranges.
  • "The domain publishes more than one SPF record": two TXT records start with v=spf1, often an old one left behind by a previous provider. Merge them into one record.
  • "An include or redirect target publishes no SPF record": the include points at a name without an SPF record — a typo, or a provider that changed its include host. Compare it with the provider's current setup guide.
  • A temperror in the results: one of the domains in the chain did not answer in time. Run the check again; a failure that persists points at that domain's nameservers.
  • The request-limit message: each SPF check is charged as up to 21 DNS queries against your share of the DNS tools' budget, so a few checks in a row can use it up. Wait the number of seconds shown and try again.

Frequently asked questions about SPF Record Checker

What is the SPF limit of 10 DNS lookups?

RFC 7208 §4.6.4 lets a receiver make at most ten DNS lookups while evaluating SPF. Every include, a, mx, ptr and exists term and the redirect modifier costs one, including those inside included records; ip4, ip6 and all cost nothing. An eleventh lookup is a permerror, and many receivers then treat the domain as having no usable SPF. The checker counts the lookups across the whole chain and lists every one past the tenth without querying it.

What is the difference between -all, ~all and ?all?

The "all" term at the end decides what happens to a sender the record does not list. -all asks for a fail, ~all for a softfail (accept but mark as suspicious), ?all for neutral (no opinion) and +all passes every server on the internet. With DMARC at p=quarantine or p=reject the difference between -all and ~all is small, because DMARC decides; +all is never safe.

Can a domain have two SPF records?

No. RFC 7208 §4.5 says a receiver that finds more than one v=spf1 TXT record at a name returns permerror. Merge the mechanisms of both into one record — for example one record with both include: terms — and remove the other.

Why does my mail still arrive when the checker reports a permerror?

Receivers handle a broken SPF record differently: many treat it as if there were no SPF at all, some ignore SPF and rely on DKIM, and a few reject. Mail that is also DKIM-signed can still pass DMARC. The permerror is still worth fixing, because the SPF part of your authentication currently does nothing.

Is a record I paste sent anywhere?

No. A pasted record is parsed in your browser and no lookup is made, so its include and redirect targets are not followed and only the lookup terms written in the record itself are counted. Check the published domain to see the full chain.

Technical notes

SPF (RFC 7208) is a TXT record at the domain a message uses in the SMTP envelope — the MAIL FROM address that receivers record as Return-Path — or in the HELO name. A receiver evaluates the terms from left to right: ip4 and ip6 compare the connecting address with a range, a and mx compare it with the domain's addresses or mail servers, include asks whether another domain's SPF passes, and the first match decides with its qualifier. redirect= hands the decision to another record when nothing matched and the record has no "all".

To bound a receiver's work, §4.6.4 allows at most 10 terms that cause DNS queries — include, a, mx, ptr, exists and redirect — over the whole evaluation, and at most two void lookups; exceeding either is a permerror. The checker follows every term of the published records: it counts lookups in the order a receiver would meet them, resolves include and redirect targets and the addresses of a and mx terms, and lists lookups past the tenth without querying them. A receiver stops at the first term that matches (§4.6.2), so the count is the most lookups any sender can cause; mail from a server listed early costs fewer. ptr and exists depend on the connecting address or on macros, so they are counted but not resolved.

The result is derived from that walk: Has errors when a permerror occurs or "+all" lets every server pass, also through an include; Works, with warnings for temporary failures, ~all, ?all, a missing "all" or any other warning; No problems found only for a record ending in -all with nothing to report.

Limitations and methodology

Records are read through Cloudflare's public resolver by the Mutqan server at the Cloudflare edge. A change made minutes ago may not be visible until the cached answers expire.

The checker evaluates the published policy, not a particular message: it cannot say whether a given sending address passes, because ptr, exists and macros need that address and are counted but not resolved.

The lookup count is the most any sender can cause. A receiver stops at the first term that matches, so mail from a server listed early costs fewer lookups, and a record over the limit gives permerror only to senders that reach the eleventh lookup.

For a pasted record only the record itself is parsed. Include and redirect targets are not followed, so the total lookup count and the problems of included records appear only in a live check.

Receivers differ in how strictly they apply the limits and how they treat permerror; the result describes RFC 7208, not each receiver's local policy.

Security and privacy

For a live check, the domain you enter goes to the Mutqan server, which asks Cloudflare's public DNS over HTTPS for it and for the names its record refers to; the resolver sees the queries come from Mutqan, not from you. A pasted record never leaves your browser. Nothing is stored.

References