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

At the end of almost every SPF record sits a small mechanism that changes everything: -all, ~all, sometimes ?all or — disaster — +all. It's the terminal qualifier: it tells the receiving server what to do with a message whose IP appears in none of your record's mechanisms. The choice between -all and ~all comes up endlessly, and it's surrounded by confusion. This guide explains exactly what each qualifier means, what receivers do with it, how they interact with DMARC, and which one you should publish.

The four qualifiers, explained

In front of all (which "catches" everything that didn't match earlier), you place a symbol that defines its meaning:

• -all (hardfail). "Any unlisted server is NOT authorized to send for this domain." It's the strong assertion, that of a domain that knows and controls all its sources.
• ~all (softfail). "An unlisted server is probably illegitimate, but don't reject it outright — just mark it as suspect." It's a cautious, in-between stance.
• ?all (neutral). "I take no position on unlisted servers." Which is to say your SPF asserts almost nothing. To avoid in production.
• +all (pass). "ANY server is authorized to send for my domain." This is a serious error (see below): you're declaring yourself that the whole world may impersonate you.

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.

Keep 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, while you inventory and align your 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 you meet it more often than you should — usually by accident, an unfortunate copy-paste or a misunderstanding. +all means "any IP is authorized to send for my domain." You turn your SPF, meant to restrict, into a universal authorization. Any spammer or impersonator then passes your SPF. It's strictly worse than having no SPF at all, because it gives false assurance. If you see +all in a record, fix it immediately — 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 your From:), and your 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 your DMARC policy;
• keeping ~all "because DMARC does the work" is a needless loosening: if you know your sources, you might as well assert it.

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

Imagine 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.

Add DMARC at p=reject on both sides, and 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 if your sources are incomplete.

How to move from ~all to -all safely

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

1. Inventory all your sending sources from your aggregate reports — they reveal every IP sending in your name.
2. Make sure they're all in your SPF (or aligned in DKIM), without exceeding the ten-lookup limit.
3. Switch to -all once you're sure nothing legitimate falls outside the list.
4. Monitor for a few days: no legitimate source should suddenly fail.

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

The case of domains that don't send

One case deserves a separate mention: domains you send no mail from — parked domains, defensive brand domains, old domains you keep. For them, the terminal qualifier isn't a compromise, it's obvious: publish v=spf1 -all, with no mechanism before it. You declare that no server is authorized to send in their name — which is exactly true, since you don't send. 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 you own but forgot to protect. The v=spf1 -all is your first line of defense, free and permanent. Don't leave any domain you own without this line — it's one of the best effort-to-benefit security moves there is, and it takes a minute to set.

Verify your qualifier

A quick glance is enough to know where you stand. Our free analyzer reads your record, tells you your terminal qualifier, and flags dangerous configurations like +all. For the full set of checks, see how to check your SPF record. And if your SPF returns an error rather than a plain result, see PermError, what it means.

Frequently asked questions

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

If I have 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 you in the short term (less risk of blocking your own mail if your inventory is incomplete), 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 doesn't stop you from aiming for -all once your estate is under control.

What should I do if I find ?all? Treat it as almost equivalent to no useful SPF, and replace it with ~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 your 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 — but treat it as 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.

Let Thomas secure your qualifier

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

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