SPF +all (and bare all): your record authorizes everyone

The four qualifiers, and what each one tells a receiver

An SPF record is an ordered list of mechanisms. A receiver walks it left to right, and the first mechanism that matches the connecting IP ends the evaluation. Whatever qualifier sits in front of that mechanism becomes the result.

The all mechanism always matches. That is its whole job: it sits at the end and catches everything that did not match anything earlier. So the qualifier on all decides the outcome for every sender you did not explicitly authorize.

There are four qualifiers:

• -all produces fail. An explicit statement that the sender is not authorized. This is what you want once the record is complete.
• ~all produces softfail. A weaker statement: receivers may look harder at the message but must not reject it on softfail alone. It is the right setting while you are still discovering senders.
• ?all produces neutral. No assertion either way. RFC 7208 says receivers must treat neutral exactly like having no SPF record at all.
• +all produces pass. Every sender is authorized.

A record ending in +all tells every receiver on the internet that any IP is allowed to send mail using your domain. It is a valid record. It parses cleanly. It will pass a naive "does this domain have SPF" check. And it does nothing to stop spoofing.

The bare all case is the same thing

RFC 7208 section 4.6.2 states that the qualifier is optional and defaults to +. That means these two records are identical in effect:

v=spf1 include:_spf.example.com all
v=spf1 include:_spf.example.com +all

This is the version that slips through reviews. In a DNS editor, a trailing all looks like someone just wrote the terminator without thinking about the sign. It reads as neutral or unfinished. It is not. It is a full pass for everyone.

Worth separating from a related case: a record with no all at all. If evaluation reaches the end with nothing matched and no redirect, the result is neutral, as if ?all had been written. A missing terminator gives you nothing. A +all actively works against you.

Why this is worse than a weak record

With ?all or a missing terminator, a spoofed message gets a neutral result. Receivers largely treat that as "no useful signal" and fall back on everything else they know about the message.

With +all, a spoofed message gets an SPF pass. That is a positive signal, and it propagates. If you publish DMARC, alignment is evaluated against the SPF result: an attacker who uses your domain in the envelope sender gets both an SPF pass and alignment, which means a DMARC pass. Your DMARC policy, however strict you set it, does not fire. The record you published to stop spoofing is now certifying it.

Reputation systems that weigh authentication results inherit the problem. You are not just failing to protect the domain, you are lending it out.

How records end up like this

• Someone was testing. +all gets used to rule SPF out while debugging a delivery problem, and then the change never gets reverted.
• Someone was firefighting. Legitimate mail started failing, the fastest way to make failures stop was to open the record, and the underlying cause never got fixed.
• The record was copied from an example that used + on other mechanisms, and the pattern got carried onto all. A + on mx or ip4 is harmless and often redundant. On all it is the whole ballgame.
• Nobody ever finished the record. The bare all was meant as a placeholder.

How to fix it

1. Inventory your senders before you change anything: your mail platform, transactional and marketing services, ticketing systems, CRMs, monitoring tools, and anything sending from your own infrastructure.
2. Confirm each is represented in the record - either as the provider's include, or as ip4/ip6 entries if you send from fixed addresses.
3. Replace +all or the bare all with -all.
4. If you are not confident the inventory is complete, go to ~all first, not +all. Softfail keeps mail flowing while you watch what fails. If you have DMARC reporting on, use the aggregate reports to find senders you missed, then move to -all.
5. Re-scan to confirm the finding clears.

One thing to check on the way out: if the record also carries a redirect modifier, note that the RFC requires receivers to ignore redirect whenever an all mechanism is present anywhere in the record. Fixing the qualifier is a good moment to notice that.

How this is rated

DNSAudit rates this Critical, and it is an exposure finding: the risk is that someone else can send as your domain, not that your own mail breaks. Severity is highest on a domain you actively send from, on any domain with reputation worth abusing, and on a parked or non-sending domain, where the correct record is v=spf1 -all and a +all is a pure gift to a spoofer.

The one place the practical impact is smaller is a domain with no DMARC and nothing at stake, since nothing is enforcing the pass either way. Even there, +all manufactures a positive authentication signal that DMARC and reputation systems build on, so it is worse than having no policy at all. Remove it regardless of DMARC state.