SPF Checker

How SPF works in email delivery

The Sender Policy Framework (SPF) is an email authentication protocol defined in RFC 7208 that helps prevent sender address forgery. When an email is sent, the receiving mail server can check the domain in the envelope sender address (the Return-Path) against the SPF record published in DNS for that domain. If the sending server's IP address is not listed in the SPF record, the email may be rejected or marked as suspicious, depending on the domain's policy.

The SPF record is a specially formatted TXT record that begins with v=spf1. It contains a list of mechanisms that define which servers are authorised to send mail. Each mechanism can optionally include a qualifier that tells the receiving server what action to take if the mechanism matches. The most common mechanisms are ip4: and ip6: which specify authorised IP ranges, include: which references another domain's SPF record, a which matches the domain's A records, and mx which matches the domain's MX records.

The mechanism qualifiers use a single-character prefix. Plus (+) signals Pass — the server is authorised and the email should be accepted. Minus (-) signals Fail — the server is not authorised and the email should be rejected. Tilde (~) signals SoftFail — the server is probably not authorised but the email should be accepted anyway for testing purposes. Question mark (?) signals Neutral — no assertion about authorisation is made. The default qualifier, when none is written explicitly, is Plus (Pass). Most SPF records end with -all (reject all other senders) or ~all (softfail all other senders) as a catch-all mechanism.

Email authentication with SPF has a critical limitation: SPF checks only the envelope sender domain, not the domain shown in the From header that the recipient sees. An attacker can send email from an unauthorised server using a forged envelope sender from a domain that publishes a permissive SPF record, while displaying any domain they want in the From header. This is why SPF is typically combined with DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting and Conformance) to provide comprehensive email authentication. DMARC aligns the From header domain with the SPF-authenticated domain, closing the gap that SPF alone cannot address.

RFC 7208 mandates that SPF evaluation must not exceed 10 DNS lookups. This limit includes each include: mechanism, each a mechanism (including a: with a domain), and each mx mechanism (including mx: with a domain). Mechanisms like ip4:, ip6:, and exists: do not count toward the limit. The 10-lookup limit exists to prevent denial-of-service attacks using deeply nested SPF records. When the limit is exceeded, the receiving server should return a PermError result, effectively treating the SPF check as failed.

SPF mechanisms in detail

Common SPF mistakes

One of the most frequent errors is exceeding the RFC 7208 limit of 10 DNS lookups. Large organisations that use multiple email service providers often accumulate many include: statements. When the limit is exceeded, receiving servers return a PermError, which may cause legitimate email to be rejected. Another common mistake is publishing an SPF record with +all (pass all) instead of -all or ~all. A +all record essentially says "any server is authorised to send email from this domain," completely defeating the purpose of SPF.

Syntax errors are also common — missing spaces between mechanisms, using a semicolon instead of a space as a separator, or forgetting the v=spf1 prefix. SPF records are also often placed on the wrong subdomain or are split across multiple TXT records when only one TXT record should contain the SPF declaration. If a domain has multiple TXT records starting with v=spf1, the receiving server should return a PermError because the SPF record set is ambiguous.

SPF best practices

Always end your SPF record with -all (hard fail) once you are confident that all authorised senders are listed. During migration or testing, ~all (soft fail) is acceptable. Use ip4: and ip6: mechanisms instead of a or mx whenever possible to reduce DNS lookup count. Monitor your lookup count with this tool and keep it well below 10. Consolidate multiple include: statements if your email senders share a common SPF include. Regularly audit your SPF record to remove stale entries for services you no longer use. Remember that SPF alone is not sufficient for robust email authentication — deploy DKIM signing and a DMARC policy alongside SPF for comprehensive protection against email spoofing and phishing attacks.

Frequently asked questions