If your SPF record ends in +all, you have told every mail server on earth that any IP address is authorized to send email using your domain. That is not a loophole or an edge case. It is an explicit, published instruction that turns SPF from a spoofing defense into a spoofing invitation. Of all the ways to misconfigure email authentication, +all is the single most damaging, because it does the opposite of what SPF exists to do.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
Below is exactly what the "all" mechanism controls, why +all is so dangerous in practice, and how to move safely from a permissive record to a hard fail without blackholing your legitimate mail.
What the "all" mechanism actually does
An SPF record is a list of mechanisms that a receiving server evaluates from left to right against the IP that connected to it. Each mechanism can carry a qualifier that decides the result when it matches. The all mechanism sits at the end and always matches, so it is the catch-all verdict for any sender that did not match an earlier rule like ip4, include, a, or mx.
There are four qualifiers defined in RFC 7208:
+Pass. The sender is authorized.-Fail, also called hardfail. The sender is not authorized and the message should be rejected.~SoftFail. The sender is probably not authorized, accept but mark.?Neutral. No statement, treat as if there were no policy.
The qualifier is optional and defaults to + when omitted, which is why +all and a bare all mean the same thing. Because all matches every remaining IP, the qualifier you attach to it decides the fate of every sender you did not explicitly list. +all says "pass everyone."
Why +all effectively invites anyone to spoof you
Read +all the way a receiving mail server reads it. A message arrives claiming to be from billing@yourdomain.com. The server pulls your SPF record, walks the mechanisms, finds no match for the sending IP, then reaches all with a + qualifier and returns SPF Pass. The spoofed message passes SPF. It came from an attacker's server in a datacenter you have never heard of, and your own DNS just vouched for it.
Here is a record that does this:
v=spf1 include:_spf.google.com +all
The include:_spf.google.com looks reassuring, but the +all after it makes the include pointless. Every IP that is not Google's still gets a Pass. You have published a policy that authorizes the entire internet.
This matters beyond SPF alone because of how DMARC works. DMARC (RFC 7489) passes when either SPF or DKIM passes and aligns with the visible From domain. With +all, SPF will pass for a spoofed message on an aligned domain, which can hand a phisher a DMARC pass they should never have earned. The authentication stack that is supposed to stop domain spoofing instead certifies it. If you want the fuller picture of how these three records interact, see SPF, DKIM and DMARC explained.
The real-world fallout
The damage is not theoretical. When your domain passes authentication for anyone, attackers use it to send invoice fraud, credential phishing, and payroll-diversion emails that sail past filters because they authenticate cleanly. Your customers and staff see a real domain with a green authentication check.
The reputation cost lands on you. Mailbox providers tie sending reputation to the authenticated domain. A spoofing campaign that authenticates as you drives spam complaints, blocklist entries, and deliverability decay against your domain, not the attacker's. Cleaning that up after the fact is far more expensive than never publishing +all in the first place. This is one of the quieter reasons legitimate mail starts landing in junk, which we cover in why emails go to spam.
-all vs ~all vs ?all: the confusion, resolved
This is where most SPF records go wrong, usually out of caution rather than carelessness. People fear that a strict record will bounce their own mail, so they soften the ending. Here is what each choice really means at the receiving end.
-all (hardfail): the correct answer for most domains
-all tells receivers to reject mail from any IP you did not authorize. This is the setting SPF was designed to end with. It is unambiguous, it gives DMARC something real to enforce, and it is what you want once you are confident your record lists every legitimate source.
v=spf1 include:_spf.google.com include:sendgrid.net -all
~all (softfail): a temporary state, not a destination
~all tells receivers the sender is probably not authorized, but to accept the message anyway, usually filing it to spam or tagging it. Softfail exists for one honest purpose: a transition period while you confirm you have not missed a sending source. It is safe to sit in softfail for a couple of weeks. It is a mistake to leave a domain there forever, because a softfail still lets spoofed mail be delivered.
?all (neutral): almost never what you want
?all makes no assertion at all. It is functionally close to having no policy for unmatched senders. There is very little reason to publish it deliberately. If you see it, treat it as an unfinished record.
+all (pass): never, on any real domain
There is no legitimate configuration where you want strangers to pass SPF as you. The only time +all appears intentionally is on a domain that is deliberately open for testing, and even then it is a bad habit. On a production domain it is a defect to fix today.
A safe migration from softfail to hardfail
The goal is -all without breaking your own mail. Rushing straight to hardfail before you have inventoried your senders is the reason people got scared into +all in the first place. Do it in order.
-
Inventory every legitimate sender. Your mail platform (Google Workspace, Microsoft 365), any marketing tools, CRM, helpdesk, invoicing, and application servers. Each one needs an
include,ip4, oramechanism in your record. -
Publish with
~allfirst. Build the complete record ending in softfail so nothing bounces while you verify. Watch for any legitimate source that is not yet covered. -
Confirm your DNS lookup count. SPF is limited to 10 DNS-resolving mechanisms per RFC 7208. Blowing past that causes a PermError that can void the whole record, so consolidate if you are near the limit. See fix SPF too many DNS lookups if you hit this.
-
Switch to
-all. Once you have watched softfail for a week or two with no surprises, change the ending to hardfail. Your final record should look like this:
v=spf1 include:_spf.google.com include:sendgrid.net -all
- Verify the change is live. Run your domain through
Reads public DNS only. Nothing is stored unless you save the domain to an account.
above to confirm the record resolves, the lookup count is under 10, and the qualifier is a hardfail. Pair this with a DMARC policy so alignment is actually enforced, which we walk through in how to set up DMARC.
Remember that SPF alone does not stop all spoofing, and it breaks on forwarding, which is exactly why DMARC leans on DKIM too. If you have not set up DKIM yet, how to set up DKIM is the next step after your SPF record is clean.
Frequently asked questions
Is +all the same as having no SPF record?
It is worse. No SPF record means receivers have no statement to act on, so a DMARC policy falls back to DKIM alignment. A +all record makes an active, positive statement that unauthorized senders should Pass, which can produce a spurious SPF pass and, with alignment, a DMARC pass for spoofed mail. Missing is neutral. +all is affirmatively harmful.
Should I use -all or ~all on my domain?
Use -all once you are confident your record lists every legitimate sending source. Use ~all only as a short transition while you verify, then move to hardfail. Leaving a domain on softfail permanently means spoofed mail still gets delivered, which defeats most of the point.
Will -all cause my real emails to bounce?
Only if a legitimate sender is missing from your record. That is why you inventory every source and sit in ~all first. Once every platform you send from is covered by an include, ip4, a, or mx mechanism, -all rejects only mail you never authorized.
Does DKIM protect me even if my SPF is +all?
DKIM helps, but it does not cancel the risk. A valid DKIM signature can still let a message pass DMARC on its own, which is good. The problem is that +all independently hands out SPF passes, and any receiver evaluating SPF in isolation, or any system that trusts SPF results, is misled. Fix the SPF record regardless of your DKIM setup.