# What does 'all' mean in an SPF record?

> The 'all' in an SPF record is the catch-all that decides unlisted senders. Compare -all, ~all, ?all and +all, where it goes, and which one to publish.

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.

## 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](https://datatracker.ietf.org/doc/html/rfc7208), 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](/learning/spf-record-syntax-explained-mechanisms-qualifiers) 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](/learning/spf-hardfail-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](/tools/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](/tools/spf) 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](/learning/how-many-spf-records-per-domain) — 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](/learning/how-do-i-fix-spf-permerror-too-many-dns-lookups) covers how to flatten or consolidate includes.

## Frequently asked questions

### Is `~all` or `-all` better?

`-all` is stronger and is the recommended end state, because it lets receivers reject spoofed mail. `~all` is safer during initial deployment because it will not bounce a legitimate sender you forgot to list. Start on `~all`, verify your senders in DMARC reports, then move to `-all`.

### Does `-all` guarantee spoofed email is rejected?

No. `-all` tells receivers the sender is unauthorized, but each receiver decides how to act, and SPF only checks the hidden return-path domain, not the visible `From:` address. That is why SPF needs DMARC on top of it — DMARC ties authentication to the `From:` domain and enforces a policy. See [why phishing emails can still pass SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim).

### What does `v=spf1 +all` do?

It authorizes every server on the internet to send email as your domain, which is the opposite of what SPF is for. `+all` (or a bare `all`, which means the same thing) should never be published. If you see it, replace it with `-all` or `~all`.

### Where does `all` go in the record?

Always last. SPF is evaluated left to right and stops at the first match, and `all` matches everything, so any mechanism after it is unreachable. Put every authorized sender first, then close with your chosen `all` qualifier.

## 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](/tools/email-security-score).

## Related reading

- [What is SPF? Sender Policy Framework explained](/learning/what-is-spf)
- [SPF hard fail vs softfail](/learning/spf-hardfail-vs-softfail)
- [SPF record syntax explained: mechanisms and qualifiers](/learning/spf-record-syntax-explained-mechanisms-qualifiers)