dotvitals

SPF authorises the whole internet through an address range

CriticalConfirmedQuick winemail.spf.catch-all-range

What this check looks for

Your SPF record authorises an address range so wide that it covers the internet itself. Any computer anywhere passes your SPF check, so the record gives a receiver no way to tell your mail from a forgery.

Why it matters

This is +all written a different way. Phishing and fake invoices sent in your name will pass SPF, can pass DMARC, and arrive carrying your domain's reputation.

When the check passes, your report says: “Authorised ranges name your senders, not the whole internet”.

What it costs your score

When this check fails it removes 35 points from your Email authentication score, before the status, confidence and repeat multipliers are applied. Email authentication carries a weight of 15 in the overall score.

It shares the email-auth.spf family ceiling of 35 points: however many findings that family produces, together they cannot remove more than that from Email authentication. One underlying problem showing up in several places is still one problem.

Severity
critical
Default confidence
confirmed
Status when triggered
fail
Deduction
35 points
Family cap
email-auth.spf · 35
Category
Email authentication
Module
Email spf
Fix owned by
dns host
In the ruleset since
2026.09

How the whole score is calculated

How to fix it

Delete ‹mechanism› and list only the addresses that actually send your mail.

As written, every host on the internet is an authorised sender for your domain, so SPF is authorising the forgeries as well as your own mail.

  1. Remove ‹mechanism› from the record. Nothing legitimate depends on it that is not also covered by the specific senders you list next.

  2. Establish which addresses genuinely send mail for you — your mail host's include:, your transactional sender's include:, and the specific /32 or /128 addresses of any server you run yourself. DMARC aggregate reports list the sources that are sending today.

  3. Republish the record with those terms and a closing ~all, and move to -all once the reports show no legitimate sender failing.

How to confirm it worked

  • dig +short TXT ‹domain› — the record must not contain ‹mechanism›

  • Re-test this finding; it must report a pass before the record is protecting anything.

The configuration to publish
v=spf1 include:{{provider}} ~all

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

Generic DNS
‹domain›. 3600 IN TXT "v=spf1 include:‹provider› ~all"

  • Replace ‹provider› with your mail host's include and add one term per sending service. Keep a copy of the old record first: if a service you had forgotten was relying on the wide range, its mail starts being marked as soon as the change propagates, and pasting the old value back is the rollback.

Technical detail

‹domain› authorises ‹mechanism›, a /‹prefix› prefix covering ‹address count› addresses — ‹coverage› of the ‹family› address space. RFC 7208 §5.6 places no lower bound on the prefix length of ip4 and ip6, so a zero-length or near-zero-length prefix is syntactically legal and evaluates to pass for every sender that reaches it, exactly as §5.1's all mechanism does. ip4:0.0.0.0/0 and ip6:::/0 are therefore +all under another name, and a prefix of /1 to /7 differs only in covering between an eighth and a half of the address space instead of all of it. No sending arrangement requires this: the usual causes are a placeholder left in a template, a /0 typed where a /24 was meant, and a firewall rule pasted into a DNS record.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the email spf checkerBuild the fix

Other email spf checks