Use SPF softfail (~all) when you are still auditing your sending infrastructure or cannot yet confirm every legitimate sending source. Use SPF hardfail (-all) once your SPF record is complete, accurate, and you are confident no authorized sender is missing. The right choice depends on how mature and stable your email configuration is. The sections below walk through each scenario, the role DMARC plays, and the mistakes that trip up even experienced senders.
What actually happens when a message fails SPF?
When a message fails SPF, the receiving mail server compares the sending IP address against the authorized senders listed in your DNS SPF record. If the IP is not on the list, the result is a fail. What happens next depends entirely on whether your record ends in ~all (softfail) or -all (hardfail), and on how the receiving server is configured to act on that result.
Most receiving servers do not automatically reject messages based on SPF alone. They record the SPF result in the email headers and factor it into a broader spam scoring decision alongside DKIM, DMARC, sender reputation, and content signals. A softfail typically adds a small negative score and may trigger spam folder placement. A hardfail signals a stronger policy violation and is more likely to result in rejection, though the final decision always rests with the receiving server.
This is an important nuance: SPF is an advisory protocol. Even a hardfail does not guarantee rejection. What it does guarantee is that you have communicated a clear policy to receiving servers, which they can choose to honor.
What is the difference between SPF softfail and hardfail?
The difference between SPF softfail and hardfail is the strength of the policy signal sent to receiving mail servers. A softfail (~all) tells receivers that mail from unlisted IPs is probably not authorized, but asks them to accept and flag it rather than reject it outright. A hardfail (-all) tells receivers that mail from unlisted IPs is definitively not authorized and should be rejected.
In practice, the two mechanisms differ in these key ways:
- Softfail (~all): Messages from unauthorized IPs are typically delivered but marked as suspicious. They may land in spam folders. The SPF result in the header reads softfail.
- Hardfail (-all): Messages from unauthorized IPs are more likely to be rejected at the gateway. The SPF result in the header reads fail.
- Neutral (?all): A third option that makes no policy claim at all. Rarely recommended for active senders.
The choice between them is not about which one sounds stricter. It is about whether your SPF record accurately reflects every IP and service that sends mail on your behalf. Hardfail on an incomplete record will block legitimate mail. Softfail on a complete record leaves you more exposed to spoofing than necessary.
When should you use SPF softfail (~all)?
Use SPF softfail (~all) when your sending infrastructure is still being audited, recently changed, or when you cannot yet confirm that every legitimate sending source is included in your record. Softfail is the appropriate policy for senders in a transitional state, not a permanent destination.
Specific situations where softfail makes sense include:
- You have recently added a new email service provider, CRM, or marketing automation platform and have not yet updated your SPF record to include its sending IPs.
- You are in the process of discovering shadow IT or third-party tools that send mail on behalf of your domain without your full knowledge.
- You have inherited an email program and are auditing what is actually sending before tightening policy.
- You are testing a new sending service in parallel with your existing infrastructure.
Think of softfail as a monitoring mode. It lets you observe what is happening without risking legitimate mail being blocked. Once you have confidence that your SPF record is complete, softfail becomes a liability rather than a safety net, because it signals to receivers that you are not fully committed to enforcing your own policy.
When should you use SPF hardfail (-all)?
Use SPF hardfail (-all) when your SPF record is complete, stable, and you are certain it includes every IP address and third-party service authorized to send mail for your domain. Hardfail is the recommended long-term policy for any domain with a well-maintained sending infrastructure.
Hardfail is the right choice when:
- You have completed a full audit of your sending sources and all authorized IPs are listed in your SPF record.
- Your sending infrastructure is stable and does not change frequently without a corresponding DNS update process.
- You want to send the strongest possible anti-spoofing signal to receiving mail servers.
- You are operating under DMARC with a p=quarantine or p=reject policy and want SPF to align with that enforcement posture.
One practical caution: before switching to hardfail, send a test from every service that touches your domain, including transactional email platforms, helpdesk tools, and marketing platforms. A single overlooked service can cause legitimate mail to fail. Review your SPF record against your actual sending infrastructure at least once per quarter, because third-party services sometimes change their sending IPs without prominent notification.
How does DMARC change the softfail versus hardfail decision?
DMARC significantly reduces the practical difference between SPF softfail and hardfail for most senders. Under DMARC, what matters for alignment is whether SPF passes or fails, not the specific flavor of fail. A softfail still counts as a failure for DMARC purposes, meaning DMARC will apply its own policy (none, quarantine, or reject) regardless of whether your SPF says ~all or -all.
This has two important implications:
- DMARC is the enforcement layer. If you have DMARC set to p=reject, unauthenticated mail will be rejected based on DMARC policy even if your SPF record uses softfail. The receiving server does not need the SPF hardfail signal to act decisively.
- SPF softfail does not weaken DMARC. Senders sometimes assume that using ~all makes their authentication posture less secure when DMARC is active. In practice, DMARC’s own policy takes precedence for receivers that honor it.
That said, hardfail still carries value as a clear, unambiguous policy signal for servers that check SPF independently of DMARC. Using hardfail alongside a strong DMARC policy creates a layered, consistent authentication posture. If you have DMARC fully deployed and enforced, the urgency of moving from softfail to hardfail is lower, but it remains best practice once your record is complete.
What are common SPF configuration mistakes to avoid?
The most common SPF configuration mistakes are exceeding the DNS lookup limit, using softfail indefinitely, and failing to include all third-party sending services. These errors either break SPF entirely or leave your domain under-protected.
Watch out for these specific pitfalls:
- Exceeding 10 DNS lookups: SPF allows a maximum of 10 DNS lookups per evaluation. Each include: mechanism that itself calls further includes counts toward this limit. Exceeding it causes a permerror, which receivers treat as a fail.
- Using softfail as a permanent policy: Softfail is a transitional tool. Leaving it in place indefinitely signals that your record may be incomplete and reduces the anti-spoofing value of SPF.
- Forgetting subdomains: Your SPF record on the root domain does not automatically cover subdomains used for sending. Each subdomain that sends mail needs its own SPF record.
- Multiple SPF records on one domain: Only one SPF TXT record is allowed per domain. If you have two, the result is a permerror. Merge all mechanisms into a single record.
- Not updating SPF when onboarding new tools: Every new platform that sends email on your behalf requires its sending IPs or include mechanism to be added before the first send, not after.
- Ignoring SPF alignment under DMARC: SPF must pass on the envelope from domain, not just the header from domain. If your ESP sends using a different return-path domain, SPF alignment may fail even if SPF itself passes.
How Email Industries helps with SPF configuration and email authentication
Getting SPF right is one of the most impactful steps a sender can take to protect deliverability and prevent spoofing. At Email Industries, we help organizations move from uncertain or outdated authentication setups to a clean, enforced configuration that actually works. Here is what we bring to the table:
- Full SPF and authentication audits: We review your current SPF record against your actual sending infrastructure, identify gaps, and flag issues like lookup limit violations or missing third-party includes.
- DMARC deployment and alignment: We guide you through moving from p=none to enforcement, ensuring SPF and DKIM alignment are correctly configured before tightening policy.
- Ongoing monitoring: Authentication is not a set-it-and-forget-it task. We monitor your records and sending behavior so that new services or IP changes do not silently break your configuration.
- Expert consulting for complex environments: Multi-brand senders, large enterprise environments, and organizations with legacy infrastructure often face SPF challenges that go beyond a simple record edit. We have seen it all.
If you want to move beyond softfail with confidence or untangle an SPF configuration that has grown complicated over time, explore our Deliverability Assurance Packages or browse our full range of services. Reach out and contact us to talk through where your authentication setup stands today.
Related Articles
- What is an example of a SPF domain?
- How does a strict DMARC policy reduce phishing and fraud risk?
- What are the biggest DMARC policy mistakes email senders make?
- How does DKIM signing work in email authentication?
- What is DMARC and why do I need it?
- How do you evaluate full service email marketing proposals?
- How does a full service agency differ from specialized email providers?
- How do email advertising agencies ensure brand consistency?
- What factors affect full service email marketing pricing?
- What size companies benefit most from full service email agencies?
- Can you warm up multiple domains at the same time?
- Can a poorly warmed domain damage your sender reputation?
- Should you warm up a new domain before sending bulk email?
- How does IP warming affect your sender reputation?
- How does IP warming work for email deliverability?
