When an email arrives at the receiver’s end, their server checks the SPF record to see if the sending address’s IP matches one of the authorized sources published in the domain’s DNS. If the IPs match, the email is seen as legitimate, but if it does not, the receiving server refers to the mechanisms in your SPF record.
At this point, it’s not just about “pass” or “fail”; it’s more about the instruction you’ve published in the SPF record that essentially determines how the receiving server would handle the email if the IPs don’t match. One of those instructions is the neutral mechanism or “?all”. With this mechanism in place, you are basically taking a step back from making a judgment on unauthorized emails and telling the receiving server neither to accept nor reject them based on SPF alone. This action places the email in a gray area, not providing the recipient’s server with a definitive answer.
In this article, we will understand what this neutral mechanism is all about and, more importantly, when you should use it.
What is the SPF neutral mechanism (?all) all about?
The receiving server needs to know what to do with an email whose sending server does not match the list of authorized servers published in the SPF record. What to do with such emails is decided by the qualifiers published at the end of the SPF record. One such qualifier is “?all” or the neutral mechanism that tells the server not to treat the message as a clear pass or a clear fail, but instead to mark it as neutral.
In this case, you instruct the receiving server to neither trust nor reject the email simply based on SPF. This means that the responsibility is then shifted to the receiving server to use its own filtering methods, such as spam detection systems, DKIM checks, and DMARC alignment to decide what to do with the message.
The problem with the ambiguity this neutral mechanism introduces is that it does not protect against spoofing or phishing, which is ultimately the primary purpose of implementing an authentication protocol.
How is the SPF neutral mechanism different from other mechanisms?
As you know, SPF works on different mechanisms, each designed to tell the receiving server how to treat emails that don’t come from authorized senders.
The reason the SPF neutral mechanism stands out is that it does not give any clear instructions on whether to accept or reject such emails. It simply leaves it to the discretion of the receiving server, which may or may not deliver the email.
This makes it very different from the other mechanisms. With ~all (soft fail), the server is told to treat emails that don’t match as suspicious. These emails usually end up in the spam folder, but are not blocked completely. With -all (hard fail), the server is told to reject emails that don’t match at all, giving the strongest level of protection.
Here’s a quick comparison between the three:
| Mechanism | What it does | Where is it used |
| ?all (neutral mechanism) | Gives no clear instructions to accept or reject unauthorized emails | Rarely used, that too, during the testing phase |
| ~all (soft fail) | Flags the email as suspicious, but allows it to be delivered | Implemented in the SPF rollout phase |
| -all (hard fail) | Outrightly rejects unauthorized emails | Best for strict security once SPF is thoroughly tested and configured |
Why is the SPF neutral mechanism (?all) not a preferred choice?
The reason why security teams or organizations don’t consider the “?all” mechanism when implementing SPF is that it does not provide any real protection against unauthorized domain usage. Also, with this mechanism, you are not telling the receiving server what exactly to do with emails that don’t match your authorized sender list. This ambiguity weakens the effectiveness of the SPF, ultimately rendering the protocol redundant.
Since the entire point of SPF is to only let authorized senders send emails on your behalf, the neutral mechanism works against this goal. This means any fake or spoofed email can still be delivered, which puts your domain at risk and reduces trust in your emails. Things get worse if this continues to happen persistently. It takes a hit on your domain’s reputation, as receiving servers and users may start to treat all emails from your domain with suspicion.
Moreover, the neutral mechanism also creates conflicts with DMARC enforcement, as it does not provide a pass/fail result that DMARC needs to enforce its policies. This weakens overall email security and leaves your domain more vulnerable to spoofing and phishing.
When should you use the SPF neutral mechanism?
Although it is not recommended to use this mechanism, there are some rare cases when you can implement “?all”.
For legacy systems
Sometimes, older systems and infrastructure cannot handle the strict SPF mechanism; in such cases, you can take a neutral stance by using “?all”. By implementing this mechanism, emails from these systems will still be delivered without going through any rigorous checks. However, this also means less protection, since fake emails are not clearly stopped.
During the testing phase
When you’re first setting up SPF, it is safer to start with the neutral mechanism. This gives you some leeway to fine-tune your SPF setup, without worrying about legitimate emails being blocked. It allows you to monitor how different mail servers handle your emails, review reports, and confirm that all legitimate sending sources are included.
Rare edge cases
There are times when other mechanisms (~all or -all) cause deliverability issues. To identify these problems, it is recommended that you temporarily use “?all” to avoid mail disruptions. But remember, this is not a long-term solution. It should only be applied while you’re fixing your setup. Once the issues are fixed, you should move back to stricter mechanisms to properly protect your domain from spoofing and misuse.
If you’re unsure how to get started with SPF or which mechanism suits your setup best, it’s always best to consult with an expert. Get in touch with our team of experts to get started!
