Should I change SPF from ~all to -all when using DMARC quarantine?
Matthew Whittaker
Co-founder & CTO, Suped
Published 15 May 2025
Updated 17 Aug 2025
8 min read
When deploying DMARC with a policy of p=quarantine, a common question arises regarding your existing SPF record: Should you change the ~all (softfail) mechanism to -all (hardfail)? This seems like a logical step for stronger enforcement, but the interplay between SPF and DMARC is more intricate than it first appears.
My experience has shown that while both mechanisms aim to prevent unauthorized senders, DMARC often acts as the primary policy enforcer. The SPF ~all or -all qualifier becomes less critical when DMARC is actively guiding how receiving mail servers should handle authentication failures. However, there are nuances to consider that can impact your email deliverability and security posture.
This article explores the relationship between SPF and DMARC policies, helping you understand whether a change from ~all to -all in your SPF record is genuinely beneficial or potentially problematic when DMARC p=quarantine is in place.
SPF (Sender Policy Framework) is designed to specify which IP addresses are authorized to send emails on behalf of your domain. The final mechanism in an SPF record, such as ~all or -all, tells receiving servers what to do with mail that fails the SPF check. ~all suggests a 'softfail', meaning unauthorized mail should still be accepted but marked as suspicious, while -all (hardfail) explicitly tells the receiving server to reject unauthorized mail. To understand more about these qualifiers, you can check out SPF ~all vs -all: which is better?.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds upon SPF and DKIM (DomainKeys Identified Mail). For an email to pass DMARC, it needs to either pass and align SPF or pass and align DKIM. DMARC provides instructions to receiving servers on how to handle emails that fail both SPF and DKIM authentication or alignment. These instructions are dictated by the p= policy tag, which can be none, quarantine, or reject. A helpful resource for understanding these policies is the Microsoft Q&A on understanding DMARC.
When DMARC is implemented, it acts as the overarching policy. If an email fails SPF authentication (regardless of whether it's ~all or -all) and also fails DKIM, DMARC's policy takes precedence. This means if your DMARC record specifies p=quarantine, the receiving server will move unauthenticated emails to the spam folder, even if your SPF record had ~all.
The role of DMARC's quarantine policy
The p=quarantine policy instructs receiving mail servers to accept an email that fails DMARC authentication, but place it in the recipient's spam or junk folder. This is a crucial step in DMARC implementation, providing a balance between strict enforcement and monitoring without immediate rejection. It allows you to gather data on legitimate email sources that might be failing authentication while still mitigating some spoofing risks.
When you have DMARC with p=quarantine in place, the DMARC policy essentially takes over the enforcement decision for unauthenticated emails. So, if an email fails SPF (regardless of ~all or -all) and also fails DKIM authentication and alignment, the receiving server will follow the DMARC quarantine instruction.
This leads to the conclusion that for mail servers that properly implement DMARC, the effect of an SPF ~all versus -all qualifier becomes secondary. DMARC tells the recipient how to handle the message based on its overall authentication status. For more details on transitioning DMARC policies, you might find switching DMARC from none to quarantine helpful.
Best practice for DMARC p=quarantine
When implementing DMARC p=quarantine, your focus should be on ensuring all legitimate sending sources are properly authorized by SPF and DKIM, and that SPF and DKIM align with your DMARC policy. This is more critical than changing SPF from ~all to -all.
Utilize DMARC aggregate reports to monitor for any legitimate traffic that is failing authentication. This data is invaluable for identifying misconfigurations or unauthorized senders.
The case for SPF hardfail with DMARC
While DMARC p=quarantine provides a clear directive for most receiving mail servers, some older or less compliant servers might not fully honor DMARC. In such cases, the SPF record's qualifier could still play a minor role. An SPF -all (hardfail) explicitly tells these servers to reject mail that fails SPF, which could offer an additional layer of protection against spoofing.
However, moving to SPF -all with a DMARC p=quarantine policy in place could be considered redundant for DMARC-aware recipients. The DMARC policy is the authoritative instruction. The primary benefit of SPF -all is to immediately reject emails, which DMARC already handles for non-compliant emails according to its policy. You can read more on this subject in our guide Should SPF hardfail be enforced if DMARC is in place?.
The potential downside of SPF -all is if you have legitimate sending sources not included in your SPF record. If these sources send mail, SPF -all will cause immediate rejection, potentially leading to lost legitimate emails, even if DKIM is properly configured. This is less of a concern with SPF ~all, as it allows for a softfail, relying more heavily on DMARC or DKIM for delivery decisions.
SPF with ~all
Emails from unauthorized IPs will softfail, meaning they might still be accepted but marked as suspicious. With DMARC p=quarantine, these emails would typically be quarantined anyway if they also fail DKIM.
This configuration is generally safer during the DMARC implementation phase, as it reduces the risk of legitimate emails being outright rejected due to SPF misconfigurations.
SPF with -all
Emails from unauthorized IPs will hardfail, leading to immediate rejection by DMARC-aware servers. This can be problematic if any legitimate sending sources are missed in your SPF record.
While it offers a stricter stance against spoofing at the SPF level, DMARC's policy often renders this level of SPF strictness redundant for most modern mail servers.
Practical considerations for your SPF record
My advice is to stick with SPF ~all if you are using DMARC with p=quarantine or p=reject. The SPF mechanism primarily serves to inform DMARC. If DMARC is present and correctly configured, it will handle the disposition of emails that fail authentication. The ~all qualifier is safer because it avoids immediate rejections that could occur if legitimate sending sources are accidentally omitted from your SPF record. You can get a good overview of this in Critical Impact's article on DMARC DNS records.
Monitoring your DMARC aggregate reports is paramount. These reports will show you exactly which sources are sending mail on your behalf, whether they pass SPF and DKIM, and how recipient servers are handling them according to your DMARC policy. This data allows you to incrementally identify and authorize all your legitimate sending services, giving you the confidence to eventually move to a stricter DMARC policy like p=reject when you are ready. Our guide on DMARC p=reject policy can provide further insights.
The example below illustrates a DMARC record that sends unauthenticated emails to quarantine:
This record instructs receiving servers to place emails that fail DMARC checks into quarantine and send aggregate and forensic reports to the specified email addresses. These reports are essential for gaining visibility into your email ecosystem and ensuring that your authentication records are correctly configured.
Views from the trenches
Best practices
Ensure all legitimate sending sources are included in your SPF record before deploying DMARC at quarantine or reject.
Use DMARC aggregate reports to identify any legitimate email streams that are failing authentication or alignment.
Gradually increase your DMARC policy from none to quarantine, then to reject, to avoid unintended deliverability issues.
Common pitfalls
Changing SPF to -all prematurely, without fully auditing all legitimate sending sources, can lead to legitimate emails being rejected.
Assuming DMARC completely negates the need for SPF, when DMARC still relies on SPF (and DKIM) for its authentication results.
Not monitoring DMARC reports, which prevents you from understanding how your policies are affecting email deliverability.
Expert tips
Prioritize DMARC policy deployment and careful monitoring over immediate SPF hardfail enforcement.
DMARC's primary goal is to tell receiving mail servers what to do if authentication fails, superseding SPF's individual policy.
If moving to p=quarantine causes emails to spam, it usually indicates an underlying SPF or DKIM alignment issue, not the ~all vs -all debate.
Expert view
Expert from Email Geeks says an SPF check resulting in no match with a ~all record will not contribute to a DMARC pass, requiring aligned DKIM to pass DMARC.
2023-07-26 - Email Geeks
Expert view
Expert from Email Geeks says it is generally acceptable to keep the SPF record with ~all when DMARC is set to quarantine.
2023-07-26 - Email Geeks
Making an informed decision
When transitioning your DMARC policy to p=quarantine, the question of whether to change your SPF record from ~all to -all is a common one. While -all indicates a stronger enforcement for SPF failures, the presence of an active DMARC policy, especially p=quarantine, largely supersedes this SPF-level directive for DMARC-compliant receivers. DMARC dictates the ultimate action for unauthenticated messages.
For the majority of modern mail servers, keeping your SPF record at ~all while using DMARC p=quarantine is usually the safest and most practical approach. It helps avoid accidental rejection of legitimate emails, while DMARC provides the necessary instructions for handling suspicious mail. The key is to ensure all your legitimate sending sources pass SPF and DKIM authentication and alignment.
Ultimately, the decision to use -all or ~all in your SPF record, when DMARC is active, should be informed by a thorough understanding of your email ecosystem and consistent monitoring of your DMARC reports.
