SPF Softfail vs Hardfail: Should You Use ~all or -all?

Short answer: An SPF record ending in ~all (softfail) tells receivers that servers not listed are probably not authorised, while -all (hardfail) says they are definitely not authorised. Without DMARC, some receivers reject hardfail messages outright, which can also reject legitimate forwarded mail. With DMARC in place, the DMARC policy decides what happens to failing mail, so the difference matters less. For active sending domains, ~all with an enforcing DMARC policy is a common, safe choice; for domains that never send mail, use v=spf1 -all.

What the “all” mechanism does

An SPF record is evaluated from left to right. Each mechanism, such as include: or ip4:, describes servers that may send for the domain. If the connecting server matches one of them, evaluation stops with that mechanism’s result, usually pass. If nothing matches, the receiver reaches the final all, which matches everything else.

The qualifier in front of all therefore defines your domain’s stance towards every server you did not list:

• -all: fail. “Anything not listed is not allowed.”
• ~all: softfail. “Anything not listed is probably not allowed; treat it with suspicion.”
• ?all: neutral. “I make no statement about servers not listed.”
• +all: pass. “Every server in the world may send as me.” Never use this.

The SPF standard, RFC 7208, defines these results but leaves it to each receiver to decide what to do with them. That is the root of the debate. Opinions differ among experienced administrators, and both sides have valid points: hardfail sends a clearer signal, softfail is more forgiving of the real-world messiness of e-mail.

How receivers treat softfail and hardfail

Without DMARC, receivers apply their own local policy to SPF results. In practice:

• Softfail is usually accepted and adds some weight towards spam filtering.
• Hardfail may be rejected during the SMTP conversation by some receivers, or treated as a strong spam signal by others.

With DMARC, the picture changes. DMARC does not distinguish between fail and softfail: for DMARC purposes, both are “not pass”. What happens to the message then depends on whether DKIM provides an aligned pass and on your DMARC policy. The DMARC specification also advises receivers not to reject solely on SPF hardfail before evaluating DMARC, although not every system follows that advice.

The forwarding problem

The main risk of -all is forwarded mail. When a message is automatically forwarded, the forwarding server is not in your SPF record, so SPF fails. If the final receiver rejects hardfail messages immediately, the forwarded copy is lost, even though your DKIM signature would have passed and DMARC would have accepted the message.

Forwarding is more common than many businesses think. Customers forward mail from old work or university addresses, associations forward member mail, and some companies route incoming mail through filtering services that effectively forward it to the final mailbox. Each of these hops puts a server between you and the recipient that your SPF record does not know about.

With ~all, the receiver is more likely to continue evaluating DKIM and DMARC, and the intact DKIM signature rescues the forwarded message. That is why many experienced administrators prefer softfail on domains that send real mail to real people, and rely on DMARC for enforcement.

Comparison

A practical recommendation

For most businesses, the sequence looks like this:

1. While building your SPF record and rolling out DMARC, use ~all. It keeps legitimate but forgotten senders working while DMARC reports reveal them.
2. Once DMARC is at p=quarantine or p=reject, spoofing protection comes from DMARC. Keeping ~all is perfectly reasonable, and it avoids early rejections of forwarded mail.
3. Switch to -all if you have a specific reason: for example, your mail rarely gets forwarded, you want maximum protection at receivers that ignore DMARC, or a security policy or audit requires it. Be confident that your SPF record lists every legitimate sender first.
4. For parked and non-sending domains, always publish v=spf1 -all together with DMARC p=reject. There is no legitimate mail to protect, so hardfail has no downside.

Both endings are valid and widely used by large organisations. Security scanners sometimes flag ~all as a weakness; in the context of an enforcing DMARC policy, it is a deliberate trade-off rather than an error. What a scanner should flag, and what really matters, is a domain with no DMARC policy at all, or one stuck at p=none for years, because then the SPF ending is the only statement the domain makes about unauthorised senders.

How to see which result receivers recorded

You do not have to guess how your ending behaves. Every receiver that checks SPF writes the outcome into the message headers, and DMARC reports summarise it across all your mail.

• In headers, look for spf=softfail or spf=fail in the Authentication-Results line, together with smtp.mailfrom showing which domain was checked and the IP address that was not listed.
• In DMARC aggregate reports, the auth_results section lists SPF results per source. A legitimate service appearing repeatedly with softfail or fail is a sender missing from your record, and it should be added or moved to aligned DKIM before you consider -all.
• In bounce messages, receivers that reject on hardfail usually say so, often with text mentioning SPF and the IP address. If such bounces appear only for forwarded recipients, the ending is the likely culprit.

Reviewing these three sources for a few weeks gives you a factual basis for the decision instead of a rule of thumb.

What ~all and -all do not fix

The ending cannot compensate for a broken record. If your SPF has two records, more than ten lookups or a syntax error, receivers return permerror and the all qualifier is never reached. If a legitimate service is missing from the record, -all makes its mail fail harder, and ~all only softens the blow. And no SPF ending protects the visible From address: that is DMARC’s job.

So before debating the last four characters, confirm the rest of the record: one SPF record, every real sender included, no unnecessary a, mx or ptr mechanisms, and a total lookup count comfortably under ten.

What about ?all and missing all?

?all tells receivers you make no claim about unlisted servers. It offers almost no protection and is mainly useful during very early testing. A record without any all mechanism behaves like ?all for unlisted senders, which is equally weak. If you see either in production, it is usually a leftover from an old setup and worth changing to ~all.

+all deserves a special warning. It authorises every IP address on the internet to send as your domain, turning SPF into a free pass for spoofers. It sometimes appears after a well-meant attempt to “make mail work” by someone who did not understand the record. Replace it immediately.

How to change the ending safely

1. Review DMARC aggregate reports for at least a few weeks and confirm that every legitimate source passes SPF or aligned DKIM.
2. Edit the existing SPF record rather than creating a new one; only the ending changes.
3. Wait for the TTL to pass, then send test messages from each system and check the headers.
4. Keep watching DMARC reports and bounce messages for a couple of weeks after the change, especially for forwarded mail and rarely used tools.

Site AI Audit checks your SPF record from the outside, including whether it is valid and within the ten-lookup limit, next to DKIM, DMARC and MX checks, and explains findings in plain words. A free check shows the current state; paid plans monitor it and alert you when it changes.

Related reading

• SPF Record Explained: What It Does and How to Set It Up
• Email Forwarding and Authentication: SPF, SRS and ARC Explained
• DMARC Explained: Policies, Alignment and a Safe Rollout

The bottom line

~all and -all are both legitimate SPF endings. Hardfail is stricter but can cause early rejection of forwarded mail at some receivers; softfail leaves room for DKIM and DMARC to decide. With an enforcing DMARC policy, ~all is a safe, common choice for active domains, while non-sending domains should always use -all. Whatever you choose, get the rest of the record right first.

DUK

What is the difference between ~all and -all in SPF?

~all produces a softfail for unlisted servers, meaning suspicious but usually accepted. -all produces a hard fail, which some receivers use to reject the message outright.

Is ~all less secure than -all?

On its own, slightly. With an enforcing DMARC policy, spoofed mail is rejected or quarantined either way, so the practical difference is small.

Does DMARC treat softfail and fail differently?

No. For DMARC, both are simply “SPF did not pass”. DMARC then looks for an aligned DKIM pass and applies your policy.

Should parked domains use -all?

Yes. Domains that never send mail should publish v=spf1 -all and a DMARC record with p=reject.

Why does my security scanner complain about ~all?

Some scanners treat anything other than -all as weak. If your DMARC policy is enforced, ~all is a deliberate choice that protects forwarded mail rather than a vulnerability.

What does ?all mean in an SPF record?

It returns neutral for unlisted servers, meaning the domain makes no claim. It offers almost no protection and should normally be replaced with ~all or -all.