No SPF record published

HighConfirmedQuick winemail.spf.no-record

What this check looks for

Your domain does not tell receiving mail servers which computers are allowed to send email for it. Anyone can send mail claiming to be from your domain and nothing marks it as suspicious.

Why it matters

SPF is one of the two ways a message can pass DMARC. Without it, your legitimate mail is more likely to be filtered and forged mail is more likely to be delivered.

When the check passes, your report says: “SPF names the servers allowed to send mail for the domain”.

What it costs your score

When this check fails it removes 25 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: high
Default confidence: confirmed
Status when triggered: fail
Deduction: 25 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

Publish an SPF record listing every service that sends mail as your domain.

Until it exists, receivers have no authorised-sender list to check and DMARC cannot pass via SPF.

List every system that sends mail as ‹domain›: your mailbox provider, transactional sender, CRM, helpdesk, invoicing and monitoring tools.
Build the record with the generator; it counts DNS lookups as you add senders so you stay under the limit of 10.
Publish a single TXT record at the apex of ‹domain›.
Start with ~all (softfail) and move to -all once DMARC reports show no legitimate sender failing.

How to confirm it worked

dig +short TXT ‹domain› — expect exactly one string starting v=spf1
Use "Test again" on this finding once your DNS host has published the record.

The configuration to publish

{{domain}}. 3600 IN TXT "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"

Cloudflare

DNS → Records → Add record → Type: TXT, Name: @, Content: v=spf1 include:‹provider› ~all, TTL: Auto

Microsoft 365

‹domain›. 3600 IN TXT "v=spf1 include:spf.protection.outlook.com ~all"

Google Workspace

‹domain›. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"

~all (softfail) is deliberate for a first record: an unlisted sender is marked, not rejected, so a system you forgot does not start bouncing on the day you publish. Tighten to -all once DMARC aggregate reports show no legitimate source failing. Publish exactly one SPF record at the apex — a second one makes both of them fail.
Microsoft 365 publishes all of its own sending ranges under this one include, but it does not cover anything else that sends as ‹domain› — a CRM, helpdesk, invoicing tool, marketing platform or on-premise appliance each needs its own mechanism. Microsoft's own documentation ends this record in -all; that is only safe once you have confirmed the full list, because -all asks receivers to reject mail from anything missing. Start at ~all, add the other senders, then tighten.
Covers Google Workspace sending only. Add a mechanism for every other service that sends as ‹domain› before tightening ~all to -all.

Technical detail

No v=spf1 TXT record was found at ‹domain›. Per RFC 7208 §4.3 a receiver that finds no SPF record returns none, which cannot produce a DMARC pass through the SPF path. Every legitimate sending service — your mail host, your marketing platform, your invoicing app — has to be listed before the policy can be tightened.