Domain & DNS Tools

SPF Record Checker

Verify that a domain's SPF record is valid and does what you intend. The checker fetches the live record, explains each term, follows every include and counts the DNS lookups that receivers will have to make.

  • Encrypted connection
  • No sign-up
  • Free to use

How to use SPF Record Checker

  1. Enter the domain you send email from.
  2. Select Check SPF.
  3. Read the verdict and the list of checks to see errors and warnings.
  4. Use the term table and the included records to find what to fix, such as an include that pushes the record over the lookup limit.

SPF Record Checker features

Lookup counter

Counts include, a, mx, exists, ptr and redirect terms across all nested records against the limit of 10.

Include tree

Shows each included domain, its own record and how many lookups it adds.

Plain-language terms

Every mechanism and qualifier is translated into what it allows or rejects.

Policy assessment

Explains whether the record ends in -all, ~all, ?all or the dangerous +all.

Error detection

Finds duplicate SPF records, invalid terms, loops, missing includes and the deprecated ptr mechanism.

Live data

Reads the record straight from DNS at the moment you check.

When to use SPF Record Checker

  • Checking a record after adding a newsletter service, CRM or help desk that sends mail for your domain.
  • Finding out why messages fail SPF with a “permerror” or “too many DNS lookups” result.
  • Reviewing a client's email setup before a deliverability project.
  • Confirming that a parked domain publishes “v=spf1 -all” so nobody can send mail as it.

SPF Record Checker FAQ

What is an SPF record?

SPF, the Sender Policy Framework, is a TXT record in which a domain lists the servers allowed to send mail using its name. A receiving server compares the address of the connecting server with that list and records whether the check passed, failed or was inconclusive.

What is the 10 DNS lookup limit?

To protect receivers from expensive records, the SPF standard allows at most ten DNS-querying terms per evaluation: include, a, mx, exists, ptr and redirect, including those found inside included records. An eleventh lookup makes the whole check end in a permanent error, which DMARC treats as a failure. ip4 and ip6 terms cost nothing.

How do I reduce the number of lookups?

Remove includes for services you no longer use, replace a and mx with the actual ip4 or ip6 addresses if they rarely change, and send bulk mail from a subdomain with its own SPF record. Avoid “flattening” services unless they update the addresses automatically, because providers change their ranges.

Should I use ~all or -all?

Both tell receivers that unlisted servers are not authorised. -all asks for rejection, ~all for acceptance with suspicion. If you publish DMARC with a quarantine or reject policy, the difference is small, and ~all avoids rejections in rare forwarding cases. Never use +all, which authorises everyone.

Can a domain have two SPF records?

No. Exactly one TXT record may start with v=spf1. If there are two, receivers return a permanent error. Combine the mechanisms of both into a single record.

Why does SPF fail for forwarded email?

A forwarding server passes the message on from its own address, which is not in the original sender's SPF record. This is a known limitation of SPF and the reason DKIM, which survives forwarding, matters for DMARC.

Understanding and maintaining SPF

An SPF record is read from left to right. After the version tag v=spf1 comes a series of mechanisms, each optionally preceded by a qualifier: a plus sign (the default) for pass, a minus for fail, a tilde for soft fail and a question mark for neutral. The receiver tests the sending server against each mechanism in turn and stops at the first match. The final all mechanism matches everything, so its qualifier decides what happens to servers that were not listed.

Most records are built from includes. Writing include:_spf.google.com does not copy Google's addresses into your record; it tells the receiver to evaluate Google's record as well, and that evaluation can contain further includes. Each one consumes part of the ten-lookup budget, which is why a domain that uses a mailbox provider, a marketing platform, a support desk and a billing system can exceed the limit without any single entry looking excessive. The include tree on this page shows where the budget goes.

It helps to remember what SPF actually verifies: the envelope sender, also called the return path, which is not the From address a person sees. A message can pass SPF for a bounce domain belonging to a mailing service while displaying your domain in the From line. DMARC closes this gap by requiring that the domain which passed SPF or DKIM matches the visible From domain.

Treat the record as something to maintain. Review it whenever you add or remove a sending service, keep the lookup count comfortably below ten, and publish an explicit “v=spf1 -all” on domains and subdomains that send no mail at all.

Other useful tools