Is -all safer than ~all?

Only once you know every system that sends as your domain. RFC 7208 says a fail result is an explicit statement that the sender is not authorized, which gives receivers clean cover to reject, while a softfail should not cause rejection on its own. Until your inventory is complete, -all mostly increases the chance that your own invoices and alerts get refused.

Does moving from ~all to -all improve DMARC?

No. DMARC only counts an SPF pass on an aligned identifier. Softfail, fail and neutral all fail to contribute in exactly the same way, so the qualifier change does not alter any DMARC outcome. It matters only for receivers that evaluate SPF outside DMARC.

Why does Google recommend ~all when Microsoft recommends -all?

They assume different stages. Google Workspace documentation recommends ~all and points out that a hard fail makes failing messages more likely to be rejected and unusable for troubleshooting. Microsoft recommends -all for Microsoft 365 domains because it also recommends DKIM and DMARC, so DMARC can act on mail that fails SPF and lacks a DKIM signature. Both are consistent with finishing the inventory first and tightening last.

SPF ~all vs -all: Which One Should You Use?

The pattern is familiar enough that we can usually guess the last change before the client finishes the sentence. Mail was fine. Someone read a hardening checklist, changed the end of the SPF record from ~all to -all, and a day or two later the invoices, the password resets and the monthly campaign stopped landing. Nothing else moved. One character did.

Say a 14-person distributor runs staff mail on Google Workspace, sends invoices from an accounting app, and pushes a monthly campaign through a marketing platform. The SPF record covers Google. It never covered the other two, because nobody ever wrote them down. Under ~all that accounting mail was arriving anyway, a little bruised. Under -all it is now explicitly unauthorized, and a receiver that takes the record at its word can refuse it outright.

So the honest answer to "should I use ~all or -all" is: both, in that order, with a stretch of reading reports in between. Here is what the two qualifiers actually say, what receivers do with them, and the sequence we follow on a client domain.

What the qualifiers mean in RFC 7208

An SPF record is a list of mechanisms evaluated from left to right. Each one either matches the connecting server or it does not. When a mechanism matches, evaluation stops and that mechanism's qualifier becomes the result. The qualifiers defined in RFC 7208 section 4.6.2 are + for pass, - for fail, ~ for softfail and ? for neutral, and the qualifier is optional, defaulting to +.

The all mechanism at the end matches everything, so it is the catch-all verdict for any server you did not list. That makes these two records identical in who they authorize and different only in what you say about everyone else:

v=spf1 include:_spf.google.com ~all
v=spf1 include:_spf.google.com -all

Read them out loud. The first says: these are my senders, anything else is probably not me, but I am not certain enough to tell you to throw it away. The second says: these are my senders, anything else is not me, do what you like with it. Both are true statements about a domain at different stages of knowing itself.

What receivers actually do with a softfail

RFC 7208 is unusually direct here. For a fail result, section 8.4 describes an explicit statement that the client is not authorized to use the domain in the given identity. For a softfail, section 8.5 says the result ought to be treated as somewhere between fail and neutral, that the domain owner believes the host is not authorized but is not willing to make a strong policy statement, and that receiving software should not reject the message based solely on this result, but may subject it to closer scrutiny than normal.

In practice that difference is the difference between a spam folder and a bounce. A softfail is a negative signal that gets weighed with everything else a filter knows about the sender. A fail is the result that gives a receiver clean cover to reject at the SMTP conversation, which is exactly what you want once your senders are known, and exactly what you do not want while they are not.

The asymmetry matters because the two mistakes cost different amounts. Publishing ~all too long means some spoofed mail gets filtered rather than refused. Publishing -all too early means your own invoices bounce, and nobody tells you, because a rejection lands in a log or a postmaster mailbox that a small company rarely reads.

Why -all before you know your senders causes outages

Almost every domain sends from more places than its owner remembers. When we inventory a client domain, the list that comes back regularly includes some of these:

The accounting or ERP system that mails invoices and statements.
The e-commerce platform, and separately its transactional mail provider.
The CRM or helpdesk that replies from a shared address.
The contact form on the website, which often still sends through the hosting server.
The office copier configured for scan-to-email years ago.
Monitoring, backup and payroll tools that mail alerts to staff.
The electronic invoicing provider, which in several Latin American countries mails documents on the company's behalf.
An old mailbox on the hosting account that somebody still uses.

Each of those needs to be in the record before the record starts refusing things. Forwarding adds a second category you cannot fully fix: when a recipient forwards your mail through an alias, the message reaches the next hop from the forwarder's server, an address your domain never authorized, so SPF evaluates against the wrong sender. Under ~all that is a scrutiny signal. Under -all it is an invitation to reject, and the person who loses mail is a customer who set up a forward you cannot see.

The failure -all cannot protect you from

There is one case where the qualifier at the end of the record never gets read at all. RFC 7208 section 4.6.4 limits a single SPF evaluation to 10 mechanisms that require DNS lookups, counting include, a, mx, ptr, exists and the redirect modifier, while ip4 and ip6 cost nothing. Exceed it and the evaluation returns permerror, and the receiver never reaches your all mechanism. Google's own admin documentation notes that records including several third-party services can cross that limit.

This is worth internalizing before you tighten anything: a domain over the lookup budget does not become safer by switching to -all, because the strict verdict is unreachable. Count the lookups first. We wrote up how to do that in the guide to getting under the 10-lookup limit.

The rollout order that does not break mail

This is the sequence we run on client domains, and the reason we push back when someone wants to skip to step five.

Inventory every sender. Ask finance, marketing, operations and whoever manages the website separately, because no single person knows the whole list. Then check the published record against what you found rather than against what you assumed.
Publish ~all covering everything you found. Google's Workspace documentation recommends v=spf1 include:_spf.google.com ~all for domains that send only through Google Workspace, and notes that a hard fail makes failing messages more likely to be rejected and unusable for troubleshooting your record.
Turn on DMARC at p=none with an aggregate report address, and leave it there long enough to see a full billing cycle and a full campaign cycle. Two to four weeks is usually the minimum that tells you anything.
Read the reports and fix what they show. Aggregate reports are how the senders nobody remembered announce themselves. Our walkthrough of that is here.
Move DMARC toward enforcement before you touch SPF again. The staged rollout from p=none to p=reject is the part that actually stops spoofing.
Then switch to -all, and watch for a week. By this point the change should be uneventful, which is the whole point of doing it last.

How DMARC changes the calculus

Once DMARC is in place, the qualifier matters less than most hardening advice implies. DMARC only counts an SPF pass on an identifier that aligns with the domain in the From header. Softfail, fail and neutral are equally worthless to it: none of them contribute to a DMARC pass, and none of them are treated differently from each other. So moving from ~all to -all does not change a single DMARC outcome.

Where it still earns its place is with receivers evaluating raw SPF outside DMARC, and as a clear statement of intent for a domain that has finished its inventory. That is close to the reasoning Microsoft publishes: its Microsoft 365 documentation recommends -all precisely because it also recommends DKIM and DMARC, so that DMARC can act on messages that fail SPF and also lack a DKIM signature. Google's recommendation of ~all assumes a domain still discovering its senders. Both are sound advice aimed at different days in the same project.

The sender requirements are worth checking against too. Gmail's guidelines require senders of more than 5,000 messages a day to Gmail accounts to set up SPF and DKIM, and DMARC for the sending domain, with only one of SPF or DKIM needing to align and a DMARC policy of p=none being sufficient to meet the requirement. Nothing in there asks for a hard fail. The requirement is authentication that works, not a strict qualifier.

Verify, then leave it alone

Check the live record rather than the one in your notes, since DNS providers quietly mangle long TXT values and Google's documentation warns that changes can take 24 to 48 hours to take effect globally:

dig +short TXT example.com
dig +short TXT _dmarc.example.com

Confirm there is exactly one v=spf1 record, that the total is under the lookup limit, and that a real test message comes back with spf=pass in its headers rather than softfail, fail, neutral or permerror. A passing message is the only proof that matters; a record that merely parses is not the same thing. You can run a live message through our free email troubleshooter to see what receivers are recording.

How Guanacos Tech helps

Most of the -all emergencies we are called into are not SPF problems. They are inventory problems that a strict qualifier turned into an outage. We map every sender on the domain, get the lookup count under control, stage DMARC from reporting to enforcement, and only then tighten the qualifier, so the last step is boring. If your mail broke after a DNS change, or you want to reach -all without finding out the hard way who else sends as you, book a call and we will walk the record with you.

SPF ~all vs -all: which qualifier to use, and why "just use -all" is bad advice on day one