No SPF Record: What It Means and How to Fix It

What an SPF record is

SPF stands for Sender Policy Framework. It is a single DNS record that lists every server allowed to send email using your domain name. When another mail server receives a message claiming to be from you, it looks up your SPF record and checks whether the sending server is on your approved list. If your domain has no SPF record at all, receiving servers have nothing to check against, which is the gap BadgerScan flagged in the outside view of your domain.

The record itself is a TXT record published at the root of your domain. It always starts with v=spf1 and then lists your senders, for example v=spf1 include:_spf.google.com ip4:203.0.113.5 -all. Each entry names a mail source: an include: for a service like your mail host or newsletter tool, or an ip4: or ip6: for a specific server address. For a plain-language overview, see Cloudflare, What is an SPF record?.

The record must be published as a DNS TXT record, and you should publish only one SPF record for the domain. The full specification is set out in RFC 7208, Sender Policy Framework (SPF).

Why it is worth fixing

Without an SPF record, nothing stops someone from sending email that appears to come from your domain. Receiving servers cannot tell a real message from a forged one, so spoofed invoices, fake staff emails, and phishing sent in your name are more likely to reach inboxes instead of being rejected.

Publishing an SPF record also helps your own legitimate email. Many providers treat a domain with a clean, well-formed SPF record as more trustworthy, so your real messages are more likely to be delivered rather than sorted into spam. It is a small, one-time DNS change that quietly improves both your security and your deliverability.

How to fix it, step by step

You fix this by publishing one TXT record at your domain root that lists every service that sends mail as you. Take a few minutes first to write down each sender: your mail host, any newsletter or marketing tool, your CRM, and any invoicing or support system that emails on your behalf. Then build and publish a single record.

• Make a list of every service that sends email as your domain, for example Google Workspace or Microsoft 365, your newsletter platform, your CRM, and your invoicing tool.
• Turn each one into an SPF entry: use the include: value your provider documents (for example include:_spf.google.com), or an ip4: or ip6: entry for a server you control such as ip4:203.0.113.5.
• Assemble them into a single record that starts with v=spf1, for example v=spf1 include:_spf.google.com ip4:203.0.113.5 -all.
• End the record with ~all (soft fail) as a safe interim while you confirm you have listed every sender, then switch it to -all (hard fail) once you are confident, so receivers reject unlisted senders.
• In your DNS provider, add one TXT record at the domain root (host @) with that value, keep it under the 10 DNS-lookup limit, and make sure you publish only one SPF record.

The one thing to remember: SPF is not the whole job

SPF on its own is not enough to stop spoofing. It only says which servers may send for you. It does not sign your messages or tell receivers what to do when a check fails. Pair it with DKIM, which cryptographically signs your mail, and DMARC, which tells receiving servers how to handle messages that fail these checks and sends you reports.

One practical caution: do not jump straight to -all before you are sure every sender is in the record. If you miss a service, a hard fail can cause your own legitimate email to be rejected. Start at ~all, watch your mail flow, then tighten to -all. You can confirm your record with the SPF and DMARC checker or by running the free scan again.