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
Scan.now queries the TXT records of the registrable domain (for www.example.com it checks example.com) and selects those beginning with v=spf1. The check fails when there is none, and it also fails when there is more than one, because RFC 7208 section 3.2 says receivers must treat multiple records as a permanent error, which in practice means no SPF at all. A record found is parsed: unknown mechanisms are flagged, the deprecated ptr mechanism is noted, and the number of DNS-querying terms (include, a, mx, ptr, exists, redirect) is counted, since RFC 7208 section 4.6.4 limits them to ten and exceeding it is another permanent error. The strength of the final all qualifier is a separate check, spf-too-permissive. Obsolete type-99 SPF resource records are ignored, as RFC 7208 instructs. Scan.now performs DNS lookups only; no mail is sent.
Why it matters
Email has no built-in sender authentication: anyone can put your domain in the envelope sender and most of the internet will accept the message. SPF is the receiver's way to check that the connecting server is one you have authorised. Without it, phishing that impersonates your domain is easier to deliver to your customers, partners and staff, and your own legitimate mail is scored more suspiciously by providers that expect authentication. SPF also underpins DMARC, which needs either SPF or DKIM to pass with an aligned domain before it can act. Note what SPF does not do: it checks the envelope sender, not the From: header users see, and it breaks on forwarding, which is why DKIM and DMARC complete the picture. Even a domain that sends no mail at all should publish a record saying so. Our SPF, DKIM and DMARC guide walks through all three.
How to fix it
Publish exactly one TXT record at the apex that lists every service that sends mail for the domain, ending with -all. A typical record for a domain using Google Workspace and a transactional provider:
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"
Microsoft 365 uses include:spf.protection.outlook.com; a server you run yourself is listed by address: ip4:203.0.113.10. A domain that never sends mail:
example.com. IN TXT "v=spf1 -all"
In the Cloudflare DNS dashboard: Type TXT, Name @, Content v=spf1 include:_spf.google.com -all. If you already have several TXT records that start with v=spf1, merge them into one. If the merged record needs more than ten lookups, replace nested includes with the provider's IP ranges (SPF flattening), or drop senders you no longer use. Verify from a shell:
dig +short TXT example.com | grep spf1
Then check the record with the email security checker, which counts lookups and reports syntax errors.
Where this fits
SPF record is check 3 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.
Fix this one first
Above it in the same category sits DMARC record (medium), where no DMARC record is published at _dmarc.<domain>, or the record is malformed. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
SPF record closes one route in. Immediately below it: 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; DMARC policy is p=none (monitoring only), where the DMARC record exists but uses p=none, so receivers are asked to deliver spoofed mail normally; DNSSEC signing, where the domain's DNS zone is not signed with DNSSEC, so a resolver cannot verify that the answers it receives for your domain are genuine, or the zone is signed but validation is failing.
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 (medium severity)
Scanner check id: spf-record
The 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.