Weak SPF Policy (+all or No all): What It Means and How to Fix It

What a weak SPF policy actually means

SPF (Sender Policy Framework) is a small DNS record that lists which mail servers are allowed to send email using your domain. When a receiving server gets a message claiming to be from you, it checks your SPF record to decide whether the sending server is on the approved list. For a plain-language primer, see Cloudflare, What is an SPF record?.

A well-formed record ends in an all mechanism that tells receivers what to do with senders not on the list. BadgerScan flagged one of two problems. The first is a record ending in +all, which means pass everyone. That authorizes any server on the internet to send as your domain, and it is strictly worse than having no SPF at all. The second is a record with no all mechanism, which leaves receivers with no default instruction, so enforcement falls back to a neutral result and nothing is really blocked.

In both cases the outside view is the same. Your domain publishes an SPF record, so it looks configured, but that record does not actually reject anyone. The fix is to list your real senders and change the ending to -all, the hard fail that tells receivers to reject anything unlisted. This behavior is defined in RFC 7208, Sender Policy Framework (SPF).

Why it is worth fixing

An SPF record that passes everyone gives your domain no protection against someone sending mail in your name. That can mean invoices, password resets, or messages to your customers that appear to come from you but do not. A tightened record makes those forged messages far more likely to be rejected or filtered.

There is also a deliverability benefit. Mailbox providers weigh SPF, along with DKIM and DMARC, when deciding whether your legitimate email reaches the inbox. A record that clearly names your senders and ends in -all is a stronger, cleaner signal than one that waves everyone through.

How to fix it, step by step

The goal is one SPF record that lists every service that sends mail for you and ends in -all. Work carefully, because a record that is too strict too soon can block your own mail. Take it in order.

• List your real senders first. Write down every service that sends email as your domain: your mailbox provider (for example Google Workspace or Microsoft 365), plus any newsletter, CRM, invoicing, or helpdesk tools.
• Build the record from those senders using the right mechanisms: include: for a provider's published SPF (for example include:_spf.google.com), ip4: for a specific server address, and a or mx if your domain's own host or mail servers send mail.
• Assemble a single record starting with v=spf1, then your mechanisms, ending in -all. A common Google Workspace example is v=spf1 include:_spf.google.com -all.
• Publish it as one TXT record at your domain root. Keep only one SPF record per domain, and never use +all as the ending.
• If you are not sure which services send your mail, set up DMARC aggregate reporting first, gather a couple of weeks of reports to see every sending source, then tighten the record to -all.

The one thing not to do

Do not paste -all onto a record before you have confirmed every legitimate sender is included. If a real service is missing, the hard fail will start bouncing your own mail, for example a newsletter or an invoicing tool that you forgot to list. If you cannot yet account for all your senders, gather DMARC aggregate reports first, confirm the full list, and only then commit to -all. And whatever you do, never leave the record on +all.