When you're setting up your Sender Policy Framework (SPF) record, you'll inevitably encounter the choice between using ~all (softfail) or -all (hardfail) at the end. This seemingly small detail can have a significant impact on how receiving mail servers handle your emails and, ultimately, your email deliverability. The decision often sparks debate, especially among those focused on email security versus those prioritizing maximum deliverability.
For years, the recommendation was often to use -all for stricter enforcement against unauthorized senders. However, with the widespread adoption of DMARC, the landscape has evolved. While the choice between ~all and -all still exists, its direct impact on how emails are handled has largely shifted to how it interacts with your DMARC policy. I'll explain what these mechanisms do and help you decide which is best for your specific setup.
SPF (Sender Policy Framework) is an email authentication standard designed to prevent sender spoofing. It allows domain owners to publish a DNS TXT record that specifies which mail servers are authorized to send email on behalf of their domain. When an email server receives an incoming email, it checks the SPF record of the sender's domain to verify if the sending IP address is listed as authorized. For more about SPF, read our guide on what SPF means in email.
The all mechanism in SPF records dictates the handling of emails sent from unauthorized IP addresses. The preceding qualifier determines the action. It's crucial to understand these qualifiers, as they directly influence how receiving mail servers interpret SPF failures.
~all (softfail)
The softfail mechanism (~all) indicates that emails from IP addresses not explicitly listed in your SPF record should be treated with suspicion, but not necessarily rejected outright. Receiving mail servers are encouraged to accept these messages but mark them as suspicious, often routing them to the spam or junk folder.
Flexibility: Ideal for domains transitioning to stricter policies or those with complex, evolving sending infrastructures. It reduces the risk of legitimate emails being outright rejected.
Deliverability: Minimizes the chance of inadvertent rejections during SPF record updates or when new sending services are added before the SPF record is fully updated.
-all (hardfail)
The hardfail mechanism (-all) instructs receiving mail servers to outright reject emails from unauthorized IP addresses. This is the strictest policy and is meant to provide strong protection against spoofing attempts.
Security: Offers the highest level of protection against direct domain spoofing by unauthorized senders. Any email failing SPF is immediately rejected.
Risk: If your SPF record is incomplete or incorrect, legitimate emails can be rejected, leading to deliverability issues. This is why many are cautious.
A common question is whether a subdomain used for sending emails needs its own SPF record. The answer is yes, each subdomain from which you send email should have its own SPF record to properly define authorized sending sources. This helps maintain email deliverability and prevents unauthorized use of your subdomains for sending. For more details, check out our article on subdomain SPF records.
The critical role of DMARC
The introduction of DMARC (Domain-based Message Authentication, Reporting, and Conformance) significantly changed the SPF game. DMARC builds upon SPF and DKIM by providing instructions to receiving mail servers on what to do with emails that fail authentication and also offers reporting capabilities. It's this DMARC policy that often overrides the direct impact of your SPF all mechanism.
When DMARC is implemented, it looks at the SPF authentication result and, more importantly, SPF alignment. For an email to pass DMARC via SPF, the domain in the SPF Return-Path (also known as the Mail From or envelope from) must align with the domain in the From header (the one users see). If a message fails SPF and also fails DKIM (or alignment), the DMARC policy (p=none, p=quarantine, or p=reject) will dictate the final action. This means the SPF ~all or -all mechanism becomes less critical for final delivery decisions if DMARC is actively enforcing a policy. For an in-depth look, see this article on SPF authentication.
SPF and DMARC interaction
If you have DMARC implemented with a policy of p=quarantine or p=reject, a message failing SPF (regardless of ~all or -all) and also failing DKIM will be handled by the DMARC policy. This is why many experts now recommend ~all even when DMARC is at enforcement, to provide a safety net while still leveraging DMARC's power. It simplifies the decision between hardfail or softfail with DMARC. If you are not using DMARC, then SPF's -all will be the sole enforcement mechanism.
Transitioning your DMARC policy from p=none to p=quarantine or p=reject is a critical step in enhancing your email security posture. This process involves careful monitoring of DMARC reports to ensure all legitimate email sources are correctly authenticated. We have a guide on how to safely transition your DMARC policy.
Practical implications and recommendations
Choosing between ~all and -all largely depends on your specific email ecosystem and security posture. If you're utilizing DMARC, particularly with an enforcement policy, ~all provides a flexible and safer approach. It ensures that DMARC is the primary decision-maker for unauthenticated mail, while minimizing the risk of inadvertently blocking legitimate emails due to SPF misconfigurations or unknown sending sources.
General recommendations
With DMARC: If you have a DMARC policy of p=quarantine or p=reject, using ~all is generally recommended. DMARC will handle the enforcement, and ~all acts as a safety net. This allows you to leverage DMARC's reporting to identify unauthorized sending sources without immediately blocking mail.
Without DMARC: If you haven't implemented DMARC, or are still at p=none, consider using -all only if you are absolutely certain that all your legitimate sending IP addresses are included in your SPF record. Any misconfiguration can lead to significant deliverability problems. You can use our free online email testing tool to test your setup.
Monitor and update: Regularly review your SPF records, especially when adding new email sending services. Mistakes can lead to email deliverability issues or even being added to a blocklist (or blacklist).
Always prioritize having a complete and accurate SPF record, regardless of the all mechanism you choose. For guidance on how to avoid DNS lookup issues and format your SPF TXT records correctly, refer to our comprehensive article on SPF record formatting and DNS size issues. Keeping your SPF record updated is crucial for maintaining good sending reputation and avoiding being flagged as spam. You can also review this discussion about SPF ~all or -all.
Views from the trenches
Best practices
Always publish an SPF record for your sending domains; it is considered a best practice for email authentication.
Combine SPF with DMARC for comprehensive email security and better deliverability control.
Use ~all (softfail) in your SPF record if you have DMARC enforced (p=quarantine or p=reject) to allow DMARC to handle policy enforcement.
Common pitfalls
Assuming that SPF alone will prevent all forms of email spoofing; it primarily protects the envelope from address.
Implementing -all (hardfail) without a robust DMARC policy can lead to legitimate emails being rejected.
Neglecting to update SPF records when adding or removing email sending services, causing valid emails to fail authentication.
Expert tips
For most modern setups with DMARC, the choice between ~all and -all has minimal direct impact on the final inbox decision, as DMARC acts as the primary enforcement layer.
Use DMARC reports to identify all legitimate sending sources before moving to stricter SPF or DMARC policies.
If you are using a hosting service that abruptly starts honoring -all, it can cause legitimate mail to fail, making ~all a safer choice in dynamic environments.
Expert view
Expert from Email Geeks says that the choice between ~all and -all doesn't really matter in most modern email setups.
2021-12-29 - Email Geeks
Marketer view
Marketer from Email Geeks says that many security specialists mistakenly claim ~all is bad, but with DMARC, there's no difference.
2021-12-29 - Email Geeks
Making the right choice for your domain
Ultimately, the choice between ~all and -all for your SPF record is less about a universal best practice and more about your specific email ecosystem and security posture. If you're utilizing DMARC, particularly with an enforcement policy, ~all provides a flexible and safer approach. It ensures that DMARC is the primary decision-maker for unauthenticated mail, while minimizing the risk of inadvertently blocking legitimate emails due to SPF misconfigurations or unknown sending sources.
Conversely, if DMARC isn't part of your current email authentication strategy, -all offers a stronger, albeit riskier, defense against direct domain spoofing. In this scenario, meticulous management of your SPF record is paramount, as any oversight can lead to severe deliverability problems. Remember, SPF is just one layer of your email security.
Regardless of your choice, the continuous monitoring of your email deliverability, DMARC reports, and any associated blocklist or blacklist statuses remains crucial. This proactive approach ensures your emails consistently reach their intended recipients, maintaining your sender reputation and preventing your messages from landing in the spam folder. Building a robust email authentication setup is an ongoing process, not a one-time configuration.
