SPF Checker

How to use this SPF checker

Enter the root domain that appears after the at sign in your email address. The scanner reads public DNS TXT records and looks for a single v=spf1 record. It then reviews the record for syntax risk, lookup count, final all mechanism, include chains, redirect terms, void lookups, and high risk mechanisms. This is record health analysis. It does not claim that a real email passes SPF because a real SPF decision also needs the sending IP address and envelope sender.

The most common SPF failure is publishing more than one SPF record. DNS providers allow several TXT records, but SPF allows only one record that starts with v=spf1. When two SPF records exist, receivers can return PermError and ignore the intended policy. The fix is not to delete providers randomly. The correct fix is to merge only the sending sources that are still used by your mail platform, CRM, ticketing system, newsletter system, billing system, and any other authorized sender.

The second common failure is the 10 lookup limit. The limit applies to DNS-querying mechanisms and modifiers such as include, a, mx, ptr, exists, and redirect. The first TXT lookup that retrieves the SPF record does not count. Nested includes do count. A clean looking record can still fail if one provider includes several other providers behind the scenes. This scanner follows include and redirect chains with safety caps and marks macro based records as best-effort because macro expansion depends on the sender and message context.

A good SPF record is usually short, specific, and ends with -all after every legitimate sender is listed. SoftFail using ~all is often acceptable during transition, but it should not be treated as a final protection state. Neutral using ?all and Pass All using +all are weak choices. +all is especially dangerous because it authorizes any host on the internet to send as the domain. For business domains, use DMARC reports to confirm all legitimate senders before moving to a strict SPF ending.

Common SPF mistakes this tool finds

• Multiple v=spf1 records at the same domain.
• SPF records that exceed 10 DNS-querying lookups.
• Open SPF policies such as +all.
• Soft policies that never move beyond ~all or ?all.
• Include loops and redirect loops.
• Deprecated ptr usage.
• Records that rely on macros and require manual review.

SPF remediation workflow

Start by making an inventory of every platform that sends email for the domain. This usually includes Microsoft 365 or Google Workspace, the website contact form, CRM, marketing automation, helpdesk, invoicing, payroll, and cloud applications. Each sender must be represented once in SPF, normally by a provider include or a controlled IP range. Remove providers that no longer send mail. This reduces lookup count and lowers the chance of an attacker abusing forgotten services.

When the record is close to the 10 lookup limit, do not immediately flatten every include into IP addresses. Flattening can break later when SaaS providers change their sending ranges. A safer approach is to remove unused senders, consolidate overlapping services, ask vendors for a more specific include, or use a managed SPF service when the business truly has many senders. After changes, monitor DMARC aggregate reports to confirm legitimate mail still aligns.

SPF alone does not stop domain spoofing. It authenticates the envelope sender, not always the visible From address users see in the inbox. DMARC is needed to connect SPF or DKIM authentication with the visible From domain. Treat SPF as one control in a wider email authentication program, not the final control.