Should you use -all or ~all in your SPF record?

SPF (Sender Policy Framework) is an email protocol that allows domain owners to tell receiving mail servers which source IP addresses are authorized to send messages on behalf of the domain.

One important concept in SPF is the all mechanism and its qualifier, which determines how receiving mail servers should treat emails that come from sources not listed in the SPF record.

In practice, the all qualifier is usually found at the end of the SPF record. For example, the following SPF record authorizes Google Workspace accounts and otherwise produces a result of soft fail, as specified by the ~ symbol.

v=spf1 include:_spf.google.com ~all

There’s a debate around whether domain owners should use ~all (soft fail) or -all (fail) in their SPF records: while -all is stricter and it may seem obvious it should be preferred for the highest level of protection, things are unfortunately not that easy.

In this article, we’ll go through this debate, exploring the quirks of SPF and how it interacts with DMARC.

What ~all and -all mean

In an SPF record, the all mechanism can be qualified with either a (hard) fail (-all) or a soft fail (~all).

Since the all mechanism always matches and it’s usually found at the end of the SPF record, the qualifier effectively tells receiving mail servers how to treat emails that come from sources not listed in the SPF record.

With ~all (soft fail), such messages aren’t outright rejected: they typically get accepted but marked as suspicious or spam by receivers. Here’s what the SPF standard (RFC 7208) defines “soft fail”:

A “softfail” result ought to be treated as somewhere between “fail” and “neutral”/“none”. The [Administrative Management Domain] believes the host is not authorized but is not willing to make a strong policy statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal.

The ADMD wants to discourage the use of this host and thus desires limited feedback when a “softfail” result occurs. For example, the recipient’s [Mail User Agent] could highlight the “softfail” status, or the receiving [Mail Transfer Agent] could give the sender a message using greylisting, with a note the first time the message is received, but accept it on a later attempt based on receiver policy.

In contrast, -all (hard fail) is a more strict setting: it indicates that any sender not in the SPF record is not authorized, and many receivers will reject or bounce those emails immediately.

Rejecting is however not strictly mandated by the standard, which says:

SPF “fail” results can be used to reject messages during the SMTP transaction based on either “MAIL FROM” or “HELO” identity results. […]

SPF “fail” results can alternately be used as one input into a larger set of evaluations that might, based on a combination of SPF “fail” results with other evaluation techniques, result in the email being marked negatively in some way (this might be via delivery to a special spam folder, modifying subject lines, or other locally determined means). […] Such an approach might result in email that was not authorized by the sending ADMD being unknowingly delivered to end users.

Historically, administrators often used ~all during SPF deployment and moved to -all once they were confident their SPF configuration was complete.

The situation is unfortunately a bit more nuanced than this, especially when forwarding and DMARC are used.

The issue with indirect email flows

While SPF works as expected for most use cases, it can be harmful to the delivery of emails that are part of indirect email flows. These include automatic email forwarding (done at the SMTP server level, not with the “forward” button) and mailing lists.

When an email is forwarded, the recipient server sees the forwarder’s IP as the sending source, not the original sender. Since the forwarder’s IP isn’t in the sender’s SPF record, SPF fails. This becomes problematic if the domain uses a hard SPF fail (-all), because some receiving servers may reject the message outright before evaluating other authentication signals. As a result, even a legitimate email that originated from an authorized server can be marked as unauthenticated.

To mitigate this, Sender Rewrite Scheme (SRS) was designed: SRS rewrites the envelope sender address (MAIL FROM) on forwarded messages to a new address controlled by the forwarder’s domain, which has an SPF record authorizing the forwarder’s IP. Since this new address is used in SPF checks, this strategy ensures that the forwarded email message will pass SPF validation at the final destination.

SRS is however not a perfect solution: while its usage is growing, it’s not universally adopted. Even large email providers took a long time to adopt it: for example, Microsoft 365 added support for it only in 2023. Moreover, SRS is known to sacrifice SPF alignment in the context of DMARC to get an SPF pass result, therefore fixing one issue while creating another one later down in the authentication process.

DKIM and DMARC are more robust

Given how fragile SPF sometimes is, the industry is increasingly relying on DKIM (DomainKeys Identified Mail) for email authentication purposes.

DKIM works by attaching a digital signature in the email headers, which covers certain headers and the message body. Since forwarding typically doesn’t modify these headers or body, the original DKIM signature remains intact in most cases and thus survives forwarding.

This is where DMARC (Domain-based Message Authentication, Reporting and Conformance) becomes essential. DMARC ties together the results of SPF and DKIM and adds the crucial concept of domain alignment.

The key benefit here is that DMARC doesn’t require both SPF and DKIM to pass: only one of them needs to (as long as it aligns with the “From” domain). This is particularly useful in the context of indirect flows, because while SPF may fail due to forwarding or relays, a valid DKIM signature that aligns with the sender domain can still lead to a DMARC pass and therefore to a successful message delivery.

DMARC and the early rejection problem

One of the benefits of DMARC is that if SPF fails (due to forwarding or a missing IP) it doesn’t necessarily impact deliverability, provided that the receiving mail server evaluates DMARC even after an SPF failure.

This is a crucial point: DMARC is designed to work with either SPF or DKIM, so an SPF failure on its own shouldn’t be a problem, as long as DMARC processing still occurs and DKIM passes with proper alignment.

However, if a domain uses a hard SPF fail (-all), some receiving servers might reject the message before DMARC or DKIM are even evaluated. This so-called “early rejection” short-circuits the authentication process and can lead to legitimate mail being rejected/bounced unnecessarily.

The DMARCbis draft specification explicitly warns about this:

SPF was intended to be implemented early in the SMTP transaction, meaning it’s possible for a message to fail SPF validation prior to any message content being transmitted, and so some Mail Receiver architectures might implement SPF in advance of any DMARC operations.

This means that an SPF hard fail (”-”) prefix on a sender’s SPF mechanism, such as “-all”, could cause a message to be rejected early in the SMTP transaction, before any DMARC processing takes place, if the message fails SPF authentication checks.

Domain Owners choosing to use “-all” to terminate SPF records should be aware of this, and should understand that messages that might otherwise pass DMARC due to an aligned DKIM-Authenticated Identifier could be rejected solely due to an SPF fail.

The draft, meant to be published as a Proposed Standard, also recommends following the best practices outlines in the M3AAWG Email Authentication Recommended Best Practices, which says that “SPF records should end in ~all”. The document also notes that some receivers are more likely to reject unauthenticated email when -all is used.

Early rejections are especially subtle because they’re not included in DMARC reports and can therefore be hard to discover and debug. As DMARCbis says:

Moreover, messages rejected early in the SMTP transaction will never appear in aggregate DMARC reports, as the transaction will never proceed to the DATA phase and so the RFC5322.From domain will never be revealed and its DMARC policy will never be discovered.

This concern of skipping DMARC evaluation is the primary reason many advocate for ~all in SPF records. With ~all, a failed SPF check does not immediately reject/bounce the email, instead allowing for DKIM verification and DMARC policy evaluation.

-all is not more secure (if you use DMARC)

At first glance, using -all might seem like a more secure choice, leaving little room for (mis)interpretation. However, when DMARC is in place this strictness doesn’t actually add any meaningful protection against spoofing. Let’s see why.

From a DMARC perspective, the outcome of an SPF check is binary: it either passes with alignment or it doesn’t. Whether SPF fails with a soft fail (~all) or a hard fail (-all) is irrelevant to DMARC’s decision-making.

The decision on whether an email message should be rejected is determined by your DMARC policy. A domain with p=reject instructs receivers to reject any message that fails both SPF and DKIM (with alignment), while p=quarantine instructs receivers to treat it with suspicion.

In this setup, using ~all in SPF achieves the same anti-spoofing outcome as -all, because the DMARC policy takes over enforcement. In other words, once DMARC is fully deployed with a strict policy and proper DKIM signing, the SPF -all qualifier no longer provides additional security.

What it can do, however, is introduce unwanted rejections, as mentioned above. Using ~all avoids these pitfalls. It ensures that a failing SPF doesn’t prevent DMARC evaluation, while not changing its outcome, and at the same time leaves the door open for older or DMARC-unaware systems to still accept messages they would otherwise wrongly reject (such as forwarded messages).

Should we care about legacy servers?

A common question is whether the “early rejection” issue with -all is largely theoretical or something that actually affects deliverability today. The answer is nuanced and not definitive.

In an ideal world, all email providers are DMARC-aware and don’t drop email messages based on SPF alone. However, it is still common belief that the issue hasn’t vanished completely. There are still plenty of organizations running their own mail servers with less-than-ideal configurations.

If you publish -all in your SPF record, you are trusting every receiver out there to handle its nuances correctly. Unfortunately, some won’t.

From a practical perspective, many consider early SPF rejections an avoidable legacy problem. While it’s true that it’s less of a problem that it once was, it’s not a relic of the past yet, and this is proven by the fact that the latest DMARC specification (completed in 2025) and the M3AAWG best practices still highlight this problem.

Recommendations for large email providers

You may wonder what large email providers (ESP) recommend.

The two largest ESPs are Google Workspace and Microsoft 365. Unfortunately, their documentation and recommendations don’t help us solve the debate.

Microsoft still advocates a “hard fail” approach, saying that “for Microsoft 365 domains, we recommend -all (hard fail) because we also recommend DKIM and DMARC for the domain” (it’s not very clear how these two are related in their recommendation).

On the other hand, Google recommends the use of ~all (soft fail) in the Google Workspace documentation, although they don’t elaborate on why they provide this suggestion.

Should we care about SPF at all?

Another common question is whether we should care about SPF at all.

Many large cloud providers, like Google Workspace, Microsoft 365, and SendGrid, operate infrastructure that sends mail on behalf of millions of domains. Their SPF records typically include large shared IP ranges that are authorized to send for any of those domains. If you’re including any of these large providers in your SPF record, you’re effectively authorizing a huge amount of domains, at least in theory (it’s up to the email provider to disallow unauthorized sending).

This is why DKIM is now considered the stronger signal. DKIM uses cryptographic signatures that are usually unique to each domain and can’t be spoofed by other tenants on shared infrastructure. It allows receivers to verify both the domain and the message content, independent of the sending IP, providing a much stronger authentication signal.

It quite likely that in the future the industry will move toward DKIM-only authentication (perhaps after DKIM2), deprecating SPF and all its pitfalls. That day is however still distant.

Summary

We went through all the nuances of using ~all or -all in your SPF record. Here’s a summary of what we learned:

• -all is the strictest option but can cause unwanted and early email rejections with legacy or misconfigured servers, also preventing failures from appearing in DMARC reports.
• ~all is a more permissive option that usually prevents the delivery issues associated with forwarded email and mailing lists (when mitigations like SRS are not used).
• With DMARC in enforcement mode, ~all and -all are equally treated as a failure. In this case, -all doesn’t provide additional security.

Given these considerations, we recommend using ~all (soft fail) in your SPF record. If you want to protect a domain not used for email sending, you can instead use v=spf1 -all.