What does 'all' mean in an SPF record?

The all at the end of an SPF record is a catch-all mechanism: it matches every sender that none of the earlier mechanisms already matched, and its qualifier tells receivers what to do with those unlisted senders. -all means reject them, ~all means treat them as suspicious, ?all means make no judgement, and +all means accept anyone — which defeats the point of publishing SPF at all. Because all matches everything, it is always the last mechanism in the record and it sets your default policy for mail that comes from anywhere you did not authorize.

At a glance

Quick takeaways

• all is a mechanism that always matches, so it defines what happens to every sender not covered by an earlier include, a, mx, or ip4.
• The character in front of all is a qualifier: - (fail), ~ (softfail), ? (neutral), or + (pass).
• -all is the goal — it tells receivers to reject unauthorized senders, and DMARC enforcement depends on it.
• ~all (softfail) is the safe setting while you are still confirming every legitimate source.
• +all is dangerous: it authorizes the entire internet to send as your domain. Never publish it.
• all must be the last mechanism in the record; anything you put after it is ignored.

What is the all mechanism in SPF?

An SPF record is a single DNS TXT record that lists the servers allowed to send mail for your domain, evaluated left to right. Most of the entries authorize specific sources — include:_spf.google.com pulls in Google's sending ranges, ip4:198.51.100.10 allows one address, mx allows whatever your MX hosts are. The all mechanism is different: it has no argument and it matches unconditionally. By the time a receiver reaches all, it has already checked every source you explicitly listed, so all is the rule for everyone left over.

That is why all sits at the very end. Per RFC 7208, SPF evaluation stops at the first mechanism that matches, and all always matches — so any mechanism placed after it can never be reached. A record like v=spf1 include:_spf.google.com -all reads as "allow Google's servers, fail everything else." For the full grammar of the other mechanisms, our SPF record syntax guide walks through each one; this article focuses on the closing all and the qualifier you attach to it.

What do the SPF qualifiers mean?

Every mechanism in an SPF record can carry a qualifier, but it matters most on all because that is where you set the default. There are four, and the qualifier is optional — if you omit it, SPF defaults to + (pass). The four results are defined in the standard:

• -all — Fail (hard fail). Unlisted senders are not authorized. Receivers are expected to reject or discard the message. This is the enforcing policy.
• ~all — SoftFail. Unlisted senders are treated as probably unauthorized but not rejected outright; the message is usually accepted and marked. This is the transitional policy.
• ?all — Neutral. The domain explicitly makes no statement about unlisted senders. Receivers treat it almost the same as having no SPF policy.
• +all — Pass. Every sender is authorized. This tells the world that any server may send as your domain.

The same four qualifiers can prefix any mechanism — -include:... is valid — but in practice you set them once, on all, to define the fall-through behavior. For a deeper comparison of the two you will actually choose between, see SPF hard fail vs softfail.

Which all qualifier should you use?

For a domain that has finished mapping its legitimate senders, the answer is -all. Everything short of that is a step on the way there.

• -all (Fail) is the destination. It is also what DMARC enforcement leans on: DMARC can only quarantine or reject spoofed mail with confidence when your authentication records draw a hard line, and -all is that line for SPF. Publish it once you are certain every service that sends on your behalf is listed.
• ~all (SoftFail) is the right starting point during rollout. It lets you publish SPF and watch DMARC aggregate reports for sources you forgot — a payroll platform, a helpdesk tool, a marketing ESP — without bouncing their mail while you find them. Move to -all when the reports are clean.
• ?all (Neutral) has almost no legitimate use. It publishes a record that asserts nothing, which gives you none of SPF's protection. If you find ?all on your domain, treat it as unfinished.
• +all (Pass) should never appear on a real domain. It is occasionally seen where someone misunderstood the syntax; the effect is to authorize the entire internet to spoof you.

The practical path is ~all first, confirm your senders in DMARC reports, then tighten to -all. You can check what your domain publishes today with the SPF record checker before you change anything.

What happens if you leave all off entirely?

Omitting all is not the same as publishing -all, and it is a common mistake. Without a final all, a receiver that reaches the end of your record without matching any mechanism gets a neutral result — effectively the same as ?all. So a record like v=spf1 include:_spf.google.com neither passes nor fails unlisted senders; it just shrugs. That is weaker than most people intend when they set SPF up. Always close the record with an explicit all so the default is deliberate rather than accidental.

Note that a bare all with no qualifier means +all (pass everyone), because + is the implied default. If you type all intending "fail," you have actually published the most permissive policy possible. Write the qualifier every time.

Common issues with the all mechanism

Mechanisms placed after all are silently ignored

Because all always matches and evaluation stops at the first match, anything to the right of it never runs. A record such as v=spf1 -all include:_spf.google.com fails all mail, including Google's, because the -all matches first. Keep all last, always. If you need to add a sender, insert its include or ip4 before the all.

The record has two all mechanisms

Merging two records by hand sometimes leaves two all tokens, like v=spf1 include:a ~all include:b -all. Only the first is ever reached, so the second and the include:b between them are dead. Consolidate to one all at the end. If you are wrestling with more than one SPF record entirely, see how many SPF records a domain can have — the answer is one.

-all starts bouncing legitimate mail

If tightening to -all causes a real sender's mail to fail, that source was never in your record. Do not roll back to ~all and forget it — find the missing sender in your DMARC aggregate reports, add its include or ip4, and keep -all. Rolling back permanently leaves the door open to spoofing.

The record hits the ten-lookup limit before reaching all

SPF allows at most ten DNS-querying mechanisms. If your include chain exceeds that, evaluation returns a PermError and your all policy never applies cleanly. This is one of the most common SPF failures; our guide on fixing SPF PermError: too many DNS lookups covers how to flatten or consolidate includes.

Where Palisade fits

Getting to -all safely is really a discovery problem: you cannot enforce until you are sure every legitimate sender is listed, and on a busy domain those sources change constantly. Palisade inventories every service sending on your domain, keeps your SPF, DKIM, and DMARC records aligned as that list shifts, and tells you when it is safe to tighten ~all to -all without dropping real mail. See where your domain stands with the Email Security Score.

Related reading

• What is SPF? Sender Policy Framework explained
• SPF hard fail vs softfail
• SPF record syntax explained: mechanisms and qualifiers