AUTHENTICATION / SKY FREE TOOLS

SPF Checker

Inspect your published SPF record, included policies and DNS-lookup limits.

01 / INPUT

Does the SPF record describe the right sources?

STEP 01

Your DNS query is sent to Sky’s server and its fixed public resolver to complete the lookup. It is not added to tool history. Ordinary hosting access logs may still exist.

NEXT / INTERPRET THE EVIDENCE

Use this result with the sending path, receiver response and authorized provider signals—not as a stand-alone placement verdict.

Explore the Signal Lab

GUIDE / UNDERSTAND YOUR RESULT

How to read your SPF Checker result

SPF lists sending sources a domain authorizes. This checker reads the published record and available DNS dependencies; it does not test a particular email or sending IP.

Reading the result, step by step

Start with Record status
Valid record means no issue was reported in the structure and available dependencies. Review needed means a warning was found. Invalid record means a record issue was found, such as invalid syntax or multiple SPF records. Not found means no SPF TXT record was returned. Unavailable means DNS could not be fully checked. Invalid input means the entry was not a domain; enter a domain, not a URL or email address.
Read the summary and findings
The success summary says, “SPF record structure and available DNS dependencies were inspected. No sending-IP authorization was evaluated.” A warning says DNS-dependent checks need review. Open each finding for details. “Multiple SPF records found” explains that SPF requires one selected record at a domain.
Treat the term count as an inventory
The returned text shows what DNS publishes. The DNS-dependent terms count is an inventory across inspected records, not a precise lookup total for a real message. A count above 10 is flagged for review, but does not itself prove a message-level permerror. SPF evaluation depends on the sending IP, envelope identity, and evaluated path.
Note what was not tested
“Message-level SPF result not computed” is expected. The tool has no connecting IP or MAIL FROM or HELO identity, so it cannot say whether a sender is authorized or SPF aligns with a message’s From domain. A clean record is not proof that a message passes SPF or DMARC. Google recommends SPF, DKIM, and DMARC; Gmail requires SPF or DKIM for all senders and all three for bulk senders.

Common problems and how to fix them

SPF PermError: too many DNS lookups

Usual cause: RFC 7208 limits an SPF evaluation to 10 DNS-causing terms: include, a, mx, ptr, exists, and redirect. Exceeding the limit produces permerror. The checker counts observed dependencies conservatively, without a message identity or evaluated path. The RFC recommends limiting void lookups to two; exceeding an implemented limit produces permerror.

Fix: Review nested includes and unnecessary DNS-based mechanisms with your providers. Confirm a sender is unused before removing its dependency, then retest.

Two SPF records on one domain

Usual cause: A domain must publish exactly one SPF record; more than one selected record produces permerror. The checker reports “Multiple SPF records found” as an error.

Fix: Combine authorized sources into one SPF policy. Check the DNS answer after publishing and keep the previous value for rollback.

A referenced domain has no SPF record

Usual cause: An include or redirect points to a domain without an SPF record. The checker reports “Referenced domain has no SPF record.”

Fix: Confirm the target spelling and ask its owner or provider for the current setup. Remove or replace the reference only when legitimate mail no longer depends on it.

A DNS dependency is unavailable

Usual cause: A timeout or resolver error prevents a conclusion. It does not mean the record is valid or invalid.

Fix: Try again later and compare with authoritative DNS. If it persists, ask your DNS host to check the zone and resolver path.

SPF passes but DMARC does not

Usual cause: A passing SPF result counts for DMARC only when the SPF-authenticated MAIL FROM domain aligns with the message’s From domain. An aligned DKIM pass can also satisfy DMARC.

Fix: Inspect a real message’s SPF and DKIM results and compare authenticated domains with From. This record-only checker cannot test alignment.

Example: Reading an illustrative policy

v=spf1 ip4:192.0.2.10 include:_spf.example.net ~all

The ip4 term authorizes the documentation-only address shown. Include refers to another SPF policy and adds a DNS-dependent term. ~all means softfail for a sender that reaches it without an earlier match; -all means fail, ?all neutral, and +all pass. The qualifier defaults to + when omitted. The checker can inspect this text but cannot test the result for a real sender.

Frequently asked questions

How do I fix SPF PermError for too many DNS lookups?

Review DNS-causing terms across the evaluated include and redirect path. SPF permits up to 10 such terms in an evaluation. The checker’s count is an inventory, not an evaluation for your sending IP. Ask providers which references are needed before changing them.

Can I have two SPF records for one domain?

No. Publish one selected SPF record. Combine authorized senders in that policy; do not add a second v=spf1 record alongside it.

Should I use ~all or -all?

~all gives softfail for an unmatched sender; -all gives fail. Confirm every legitimate service before tightening a live policy. Receivers decide how to handle authentication results.

Does SPF need to align for DMARC?

Only if relying on SPF: it must pass and its MAIL FROM identifier must align with From. An aligned DKIM result can also pass DMARC. This checker cannot assess either path for a message.