The fix, in one snippet
example.com. IN TXT "v=spf1 include:_spf.google.com -all"Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
When an SPF record exists, Scan.now inspects how it ends. +all (or a bare all, which defaults to +) explicitly authorises every host on the internet and is rated high. ?all declares no opinion and is treated by most receivers as if there were no record, also rated high. A record with no all mechanism and no redirect defaults to neutral and is rated medium. ~all (softfail) passes with a note that it is acceptable during rollout and that DMARC treats a softfail as a non-pass anyway; -all passes cleanly. The check also flags overly broad mechanisms: ip4:0.0.0.0/0, IPv4 prefixes shorter than /16, IPv6 prefixes shorter than /32, and the ptr mechanism, which RFC 7208 says should not be used. The existence and syntax of the record are covered by spf-record.
Why it matters
An SPF record is only as strong as the hosts it excludes. With +all, a phishing message sent from any server produces an SPF pass, and if the attacker also uses your domain in the From: header it passes DMARC alignment too, so the message arrives as fully authenticated mail from you, with none of the warnings that a spoofed message would normally trigger. ?all is nearly as bad in practice because receivers ignore a neutral result. Huge address ranges have the same effect for a smaller crowd: authorising a cloud provider's entire block means any of that provider's customers can send as your domain. These records usually appear when a deliverability problem was "fixed" by loosening the policy instead of adding the missing sender. The SPF, DKIM and DMARC guide explains how to find every legitimate sender before tightening.
How to fix it
Enumerate the services that really send mail for the domain, list them explicitly and end with -all:
example.com. IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.10 -all"If you are not confident the list is complete, publish a DMARC record with a reporting address first (see dmarc-record) and use ~all for a few weeks; the aggregate reports show every source that sent mail as your domain and whether it passed, which tells you what to add. Then switch to -all. Replace broad ranges with the provider's published include mechanism; providers maintain those precisely so you do not have to allow their whole network. In the Cloudflare DNS dashboard edit the existing TXT record in place rather than adding a second one. Check the result:
dig +short TXT example.com
"v=spf1 include:_spf.google.com ip4:203.0.113.10 -all"The email security checker re-evaluates the qualifier and the lookup count after you change the record.
Where this fits
SPF record is too permissive is check 1 of 8 that the website vulnerability scanner runs under dns and email authentication, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
What fixing this still leaves open
SPF record is too permissive closes one route in. Immediately below it: DMARC record, where no DMARC record is published at _dmarc.<domain>, or the record is malformed; SPF record, where the domain publishes no valid SPF record, or publishes more than one, so receiving mail servers cannot tell which hosts are allowed to send mail as your domain; CAA record, where no CAA record limits which certificate authorities may issue certificates for the domain, so any of the hundred-plus publicly trusted CAs could be induced to issue one.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: SPF record is too permissive (high severity)
Scanner check id: spf-too-permissiveThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
