Is +all worse than having no SPF record at all?

Yes. With no record the result is none, which asserts nothing. With +all the result is an explicit pass for any sender, so a receiver that checks SPF is actively told the spoofed message is authorised.

Does DMARC protect me if I publish +all?

No. DMARC asks whether an authenticated identity aligns with the visible From: domain. If SPF passes for everyone, that alignment can be satisfied by anyone, and a strict DMARC policy provides no protection.

What is the difference between +all and ~all in practice?

+all tells receivers unlisted senders are authorised. ~all tells them unlisted senders are not authorised but asks them not to reject on that basis alone. The first removes the protection; the second keeps it while leaving room for senders you have missed.

Is there any legitimate reason to publish +all?

Essentially none for a domain that sends mail. The rare argument made for it is during a migration where the sending estate is genuinely unknown, but ?all expresses that honestly without asserting a false pass, and DMARC reporting answers the question properly within a fortnight.

CriticalPolicy

SPF record ends with +all

The record ends in +all, which authorises every server on the internet to send mail as this domain. It is not a permissive setting: it is the removal of the protection SPF exists to provide, and it is worse than publishing nothing, because a receiver checking SPF gets an explicit pass for a spammer rather than a neutral result.

Check your own domainSPF checker

What causes this

The all mechanism is the catch-all at the end of an SPF record, and its qualifier decides what happens to senders that matched nothing earlier. +all means 'pass': every server on the internet is declared an authorised sender for your domain. This is almost always a mistake made while debugging, where the qualifier was loosened to stop failures and never tightened again.

What it breaks

SPF provides no protection at all. Anyone can send mail claiming to be your domain and it will pass SPF. Worse, it can pass DMARC too, because a forged message that passes SPF with alignment satisfies DMARC.

What the receiving server does

The all mechanism matches everything, and the + qualifier means pass. Any host, anywhere, sending mail with your domain in the envelope sender receives an SPF pass. If that mail is also aligned with the visible From: address, it can satisfy DMARC as well, so a domain at p=reject with +all published is still trivially spoofable. Some receivers treat +all as a signal of misconfiguration or abuse in its own right and weight it negatively, meaning it can harm delivery of your legitimate mail at the same time.

What each qualifier tells the receiver

The qualifier before all sets the result for every sender that did not match an earlier mechanism. This is the single most consequential character in the record, and the difference between the four is entirely in what a receiver is being asked to do with unlisted mail.

+allv=spf1 include:_spf.google.com +allpass for everyone: authorises the entire internet

?allv=spf1 include:_spf.google.com ?allneutral: explicitly asserts nothing, treated much like no record

~allv=spf1 include:_spf.google.com ~allsoftfail: unlisted senders are suspicious but not rejected

-allv=spf1 include:_spf.google.com -allfail: unlisted senders are not authorised, full stop

How to fix it

Replace +all with ~all, or -all once the sender list is confirmed complete.

Confirm every legitimate sending service is listed in the record.
Change +all to ~all (soft fail).
Monitor DMARC reports or re-check for a week to confirm no legitimate sender is failing.
Tighten ~all to -all for a hard fail.

If you send with

Records that were opened up to fix a delivery problem: The usual history is that legitimate mail was failing SPF, and +all made the symptom disappear. It did so by making the check meaningless. The underlying cause is nearly always a sender missing from the record or a lookup limit breach, and both are fixable without giving up the protection.
Records copied from documentation: Some vendor examples and older tutorials use +all as a placeholder. It should never survive into a published record. If you inherited a record you did not write, +all is the first thing to look for.

Confirming the fix worked

Replace +all with ~all as an immediate step. That restores a meaningful SPF result without risking legitimate mail while you audit.
Confirm every system that sends mail as this domain appears in the record: the mail platform, marketing tools, invoicing and ticketing systems, and any application server.
Publish DMARC at p=none with a reporting address, and use the reports to find senders you did not know about, rather than guessing.
Once reports show everything legitimate is covered, move to -all.

Common questions

Is +all worse than having no SPF record at all?: Yes. With no record the result is none, which asserts nothing. With +all the result is an explicit pass for any sender, so a receiver that checks SPF is actively told the spoofed message is authorised.
Does DMARC protect me if I publish +all?: No. DMARC asks whether an authenticated identity aligns with the visible From: domain. If SPF passes for everyone, that alignment can be satisfied by anyone, and a strict DMARC policy provides no protection.
What is the difference between +all and ~all in practice?: +all tells receivers unlisted senders are authorised. ~all tells them unlisted senders are not authorised but asks them not to reject on that basis alone. The first removes the protection; the second keeps it while leaving room for senders you have missed.
Is there any legitimate reason to publish +all?: Essentially none for a domain that sends mail. The rare argument made for it is during a migration where the sending estate is genuinely unknown, but ?all expresses that honestly without asserting a false pass, and DMARC reporting answers the question properly within a fortnight.