SPF -all or ~all: what's the difference, and which to choose

What receivers do with it

Theory only matters through its practical effect. Faced with a message whose IP isn't authorized:

• with -all, the receiver has a clear signal to reject or filter hard;
• with ~all, it has a soft signal: most servers don't reject on softfail alone, they use it as one clue among others (often to push toward spam, not to block);
• with ?all, it has no usable signal;
• with +all, it has a signal… that validates the impersonator. Catastrophic.

The essential: -all is the only qualifier that firmly says "what isn't on my list isn't me."

-all vs ~all: the real debate

Why do so many domains stay at ~all when -all is the goal? Out of fear, exactly like the DMARC policy ramp. As long as a team isn't certain it has listed all its legitimate sending sources, switching to -all makes it fear blocking its own mail (a forgotten platform, a new tool). ~all is then a compromise: it signals strictness without risking outright rejection.

That compromise is acceptable in transition, during the inventory and alignment of sources. But it shouldn't become a permanent state: a domain stuck forever at ~all resembles a domain stuck at p=none — it documents good intentions without going all the way to protection. The target stays -all.

The fatal mistake: +all

A firm word on +all, because it turns up more often than it should — usually by accident, an unfortunate copy-paste or a misunderstanding. +all means "any IP is authorized to send for my domain." An SPF meant to restrict becomes a universal authorization. Any spammer or impersonator then passes it. It's strictly worse than having no SPF at all, because it gives false assurance. A +all spotted in a record calls for an immediate fix — it's a wide-open door.

The interaction with DMARC changes things

Here's the nuance many articles miss. When DMARC is in place and enforced, it's the DMARC policy (p=quarantine, p=reject) that decides the fate of unauthenticated mail — not the SPF qualifier directly. DMARC relies on alignment (SPF or DKIM aligned with the From:), and the published policy disposes.

Consequence: for a domain at p=reject with clean alignment, the -all vs ~all debate becomes less critical, because DMARC decides anyway. But that doesn't mean the qualifier no longer matters:

• not all receivers apply DMARC — an SPF at -all also protects with those;
• a strict SPF is a reputation signal consistent with the DMARC policy;
• keeping ~all "because DMARC does the work" is a needless loosening: when the sources are known, they might as well be asserted.

Good hygiene therefore means aiming for -all and p=reject: the two layers reinforce each other, they don't replace each other. The path to that double strictness is described in how to get to p=reject without breaking email.

A worked example

Two domains, identical on the source side, but one at ~all and the other at -all. An attacker spoofs their From: from some random server.

• At the ~all domain: a receiver without DMARC sees a softfail and, depending on its anti-spam policy, may still deliver the message (inbox or spam). The spoof has a chance of passing.
• At the -all domain: the same receiver has a clear SPF failure signal, and rejection is far more likely.

With DMARC at p=reject on both sides, the spoof is refused in both cases — but the -all domain stays better protected with receivers that don't apply DMARC. -all is never a handicap; it only has a downside when the source inventory is incomplete.

How to move from ~all to -all safely

The method is the same as tightening DMARC, and it rests on data:

1. Inventorying every sending source from the aggregate reports — they reveal every IP sending in the domain's name.
2. Checking they're all in the SPF (or aligned in DKIM), without exceeding the ten-lookup limit.
3. Switching to -all once nothing legitimate falls outside the list.
4. Monitoring for a few days: no legitimate source should suddenly fail.

As long as step 1 isn't done with confidence, ~all holds — but with the clear goal of switching.

The case of domains that don't send

One case deserves a separate mention: domains that send no mail at all — parked domains, defensive brand domains, old domains kept in reserve. For them, the terminal qualifier isn't a compromise, it's obvious: v=spf1 -all, with no mechanism before it. The record declares that no server is authorized to send in their name — which is exactly true, since nothing sends. Paired with a DMARC p=reject (and, with DMARCbis, np=reject for non-existent subdomains), it's the strictest and simplest configuration to maintain, because it needs no upkeep: there's no source to track.

This matters all the more because dormant domains are favorite spoofing targets, precisely because nobody watches them. An attacker loves a brand domain that's owned but forgotten. The v=spf1 -all is the first line of defense, free and permanent. No owned domain should go without this line — it's one of the best effort-to-benefit security moves there is, and it takes a minute to set.

Verifying the qualifier in place

A quick glance is enough to place a domain. Our free analyzer reads the record, names the terminal qualifier, and flags dangerous configurations like +all. For the full set of checks, see how to check an SPF record. And when an SPF returns an error rather than a plain result, see what a permanent error means.

Frequently asked questions

Can -all block legitimate mail? Only if a legitimate source isn't listed in the SPF (and not aligned in DKIM). That's why the switch to -all comes after inventorying and listing every source, not before.

With DMARC at p=reject, does the qualifier still matter? Less, but yes. DMARC decides for receivers that apply it; -all additionally protects with those that don't, and remains a consistent strictness signal.

Is ~all "safer" than -all? Safer for the sender in the short term (less risk of blocking its own mail on an incomplete inventory), but less protective against spoofing. It's a transition compromise, not a target.

Why does my provider recommend ~all? Often out of caution, to avoid breaking the mail of customers whose source inventory is uncertain. It's defensible at the start, but it's no reason to give up on -all once the estate is under control.

And when a record shows ?all? It's almost equivalent to no useful SPF, and calls for a replacement by ~all (transition) then -all. ?all asserts nothing and provides no protection.

Does -all affect my SPF lookup count? No. all (with any qualifier) requires no DNS resolution, so it never counts toward the ten-lookup limit. Switching between ~all and -all changes strictness, not the resolution budget — the two issues are independent.

Should every sending domain end in -all? Ideally yes, once its sources are fully inventoried. Until then, ~all is an acceptable waypoint — a waypoint, not a destination. A domain that ends in ~all for years is quietly leaving the door ajar for impersonators that non-DMARC receivers would otherwise turn away.

Thomas secures the terminal qualifier

Knowing whether a domain can switch to -all without breaking its mail means knowing all its sources. Thomas, the virtual CISO, names them from the reports, checks they're all covered by SPF or DKIM, and indicates the precise moment to switch to -all safely — and flags a dangerous +all or ?all lurking in the record.

Analyze a domain for free or create an account to move to -all with confidence.