Email security
SPF checker
Look up a domain's SPF record, the list of servers allowed to send mail as it, and count the DNS lookups a receiver needs to evaluate it. A record that is missing, duplicated, malformed, open to every sender or over the lookup limit gives little or no protection against mail forged in your name.
What this checks
- The TXT records at the domain, and which of them are SPF records (those starting
v=spf1). A domain with MX records but no SPF record is a finding; a domain with neither is left to the non-sending domain check. - Whether there is exactly one SPF record, as RFC 7208 requires.
- Whether the record parses:
v=spf1first, then valid mechanisms (ip4:,ip6:,a,mx,include:,exists:,ptr,all) and modifiers (redirect=,exp=). - How the record ends:
-alland~allpass;?all, or neither anallnor aredirect=, is a Medium finding;+allor a bareallis High. - The DNS lookups the record needs, following
include:andredirect=into the records they name, counted against the limit of 10. The result shows the count and the trail of records read.
What the result means
SPF (RFC 7208) lets a domain list the servers allowed to send mail for it. A receiving server compares the address that connected with the record for the domain in the envelope sender (the Return-Path), not the From address people see. DMARC is what ties an SPF pass to the visible From.
The end of the record decides what happens to every server not listed. -all asks receivers to fail them and ~all to soft-fail them; both pass this check. ?all, or a record with no all, gives unlisted servers a neutral result, which protects nothing. +all authorises every server on the internet, so forged mail passes SPF.
Each include:, a, mx, ptr, exists: and redirect= costs a DNS lookup, including those inside included records, and past 10 receivers return a permanent error (permerror) instead of a result. A passing result means one valid record, ending in -all or ~all, within the limit. A count close to 10 is worth trimming before the next sending service is added.
How to fix common issues
No SPF record
Publish a TXT record starting v=spf1 that lists the services that send your mail and ends in -all or ~all, for example v=spf1 include:_spf.google.com -all.
More than one SPF record
Merge the records into a single v=spf1 TXT record.
SPF does not reject unlisted senders
End the record with -all (or ~all while testing) after listing your real sending services.
SPF needs too many DNS lookups
Remove unused includes, replace a/mx/ptr mechanisms with IP ranges where stable, or use your provider's flattened include.
SPF record has errors
Correct the record. Each term must be a valid mechanism (ip4:, ip6:, include:, a, mx, exists:) or modifier (redirect=, exp=).
Cyber Essentials and ISO 27001
Neither Cyber Essentials nor ISO 27001 names SPF. A correct SPF record is technical evidence for the broader controls they do require: secure configuration of internet-facing services, and protecting information sent by email (ISO/IEC 27001:2022 Annex A 5.14, information transfer, and 8.9, configuration management).
The organisation still has to establish who owns the record, how a new service that sends as the domain is approved and added, and how services that no longer send are removed. A record shows the setting at one moment, not the process that keeps it right.
Scope and limitations
- The check reads public DNS through public resolvers. It cannot tell whether the servers the record lists are really yours, or whether every service that sends as you is listed; DMARC aggregate reports show that.
- It does not send or receive email and does not test how a particular receiver evaluates the record.
- It counts lookups but does not resolve the addresses behind
aandmxterms or check the separate limit on lookups that return no answer (void lookups). It stops counting once past 10, so a count over the limit is a minimum. - It checks the domain entered only. SPF is not inherited, so each subdomain that sends mail needs its own record and its own check.
Related guides
Questions
- What is the SPF 10 DNS lookup limit?
- Evaluating an SPF record may take at most 10 DNS lookups, counting include, a, mx, ptr, exists and redirect terms, including those inside included records. Past 10, receivers return a permanent error and the record gives no protection. Terms such as ip4, ip6 and all cost nothing.
- Should an SPF record end in -all or ~all?
- Either marks unlisted servers as not authorised. -all asks receivers to treat their mail as a fail; ~all asks for a soft fail, which receivers should not reject on alone but may treat with suspicion. Both pass this check; ?all and +all do not.
- Can a domain have two SPF records?
- No. RFC 7208 treats more than one v=spf1 record as a permanent error, so receivers ignore SPF for the domain. Merge them into one record.
- Does an SPF record cover subdomains?
- No. SPF is checked for the exact domain in the envelope sender, so each subdomain that sends mail needs its own record. DMARC is different: a subdomain without a DMARC record is covered by its organisational domain's record.
Related security tools
- DMARC checker - Look up a domain's DMARC record, read its policy and reporting, and see what to change.
- DKIM checker - Look up a DKIM key at your selector or at common ones, with its key type and size.
- Email security checker - Check MX, SPF, DMARC and DKIM together, and the protection of a domain that sends no mail.
- DNS checker - Look up a domain's A, AAAA, CNAME, MX, TXT, NS, SOA, CAA and DS records through public resolvers.