SPF Record Checker

This SPF record checker queries your domain's DNS TXT records for the SPF entry, the one starting with v=spf1, as specified in RFC 7208, and parses every mechanism: ip4, ip6, include, mx, a, ptr, redirect, and all. It counts DNS-resolving mechanisms against the 10-lookup limit, flags dangerous qualifiers like +all, warns on the deprecated ptr mechanism, and highlights a missing all terminator. Each mechanism is decoded individually with its qualifier, pass, fail, softfail, or neutral, so you can see exactly which servers are authorised and at what enforcement level.

SPF is the first layer of the email authentication stack. Without it, receiving servers have no way to verify whether the server sending email in your name is actually authorised by you. A missing or broken SPF record means your domain can be used in phishing and spam campaigns with no technical barrier. A misconfigured record, particularly one that exceeds the 10-lookup limit, causes legitimate email from your own sending sources to be rejected or spam-filtered by major providers including Gmail, Outlook, and Yahoo. This tool surfaces both classes of problem in seconds.

The lookup counter is the most actionable output for most users. Green means your record is within the safe range. Amber means you're approaching the 10-lookup limit and should consider SPF flattening before adding new sending services. Red means your record already exceeds the limit and is causing PermErrors at receiving servers. Email may be failing silently.

SPF records are not set-and-forget infrastructure. Every time you add a new email sending service, a marketing platform, a transactional email tool, a CRM, a helpdesk system, or an HR platform, that service needs to be authorised in your SPF record. If it is not, email from that service will fail SPF, which can trigger spam filtering or DMARC quarantine depending on your policy. Running a regular SPF check confirms your record is still current and accurate.

The 10-lookup limit is the most common silent failure mode. Most domain owners do not realise their SPF record is causing PermErrors until they start receiving deliverability complaints or notice email going to spam. Because PermErrors are handled inconsistently, some providers treat them as a neutral result, others treat them as a failure, the impact can be hard to detect without active monitoring. This checker makes the lookup count immediately visible so you can act before it becomes a problem.

For domains targeting the Google and Yahoo 2024 bulk sender requirements, a valid SPF record is mandatory for senders delivering more than 5,000 messages per day to Gmail. Even below that threshold, having a clean, correctly configured SPF record is one of the strongest signals that a domain is a legitimate sender. Combined with DKIM signing and a DMARC enforcement policy, it forms the authentication baseline that modern inbox providers use to make spam vs. inbox decisions.

Security teams and IT administrators also use SPF audits to confirm that no unauthorised include: mechanisms have been added to DNS. A vector that could allow a compromised or malicious third-party domain to pass SPF on behalf of your organisation. A clean SPF record with no unexpected entries is a meaningful security control, not just a deliverability optimisation.

Most SPF failures trace back to a small number of root causes. Here is what each common issue means and what to do about it.

SPF is the foundation of email authentication, but it is designed to work alongside two other standards. Understanding all three, and where SPF's limitations lie, is essential for anyone troubleshooting deliverability or configuring authentication from scratch.

SPF (Sender Policy Framework, RFC 7208) answers the question: is this IP address authorised to send email for this domain? It validates the SMTP envelope sender, the MAIL FROM address used during the SMTP handshake, not the From: header visible to recipients. This means SPF alone does not prevent From: header spoofing. It also does not survive email forwarding, because the forwarding server's IP is not in the original domain's SPF record.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing messages. The signature covers specific message headers and the body, and survives forwarding. Critically, the DKIM d= signing domain is the domain you control. So even when an ESP uses its own Return-Path, DKIM alignment to your From: domain is achievable. This makes DKIM the more reliable alignment mechanism for third-party sending platforms. Check your DKIM configuration to confirm signing is active.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) sits on top of both and adds two things SPF and DKIM lack individually: alignment enforcement (the From: header domain must match the authenticated domain) and a reporting mechanism (daily XML reports showing pass/fail rates from all sending sources). DMARC's p=reject policy is what actually prevents spoofed email from reaching inboxes. SPF and DKIM are inputs to that decision. Check your DMARC record to see your current policy and enforcement level, or use the DMARC Analyzer for a full tag-by-tag breakdown.

For domains where SPF lookup inflation is a problem, the SPF Flattening Tool resolves all include: chains to their underlying IP ranges and generates an optimised record that stays under the 10-lookup limit regardless of how many sending services you use.