SPF -all vs ~all: Which should you use in your DMARC record?

You’ve just finished setting up your SPF record, feeling pretty good about securing your domain’s email authentication. Then you get to that final part (the “all” mechanism), and suddenly you’re staring at options like -all, ~all, +all, and ?all, wondering which one won’t accidentally tank your email deliverability.

Don’t panic. You’re not alone.

Yes, that tiny symbol before “all” makes a huge difference in how email providers handle messages that don’t pass your SPF check. Choose the wrong one, and you might find legitimate emails bouncing back or disappearing into spam folders. Pick the right one, and you’ve got a solid foundation for email security without the headaches.

However, while there are technically four different “all” mechanisms you can use, the real choice comes down to two viable options: -all (hard fail) vs. ~all (soft fail).

Key takeaway: Most email security experts lean toward the ~all SPF policy, and we’ll explain why below.

What is SPF (and how does it work)?

SPF (Sender Policy Framework) is an email authentication method that lets you declare which mail servers are authorized to send emails on behalf of your domain. Only the servers you’ve approved can send emails that claim to come from you.

When someone sends an email from your domain, the receiving email server checks your SPF record (which is published as a DNS TXT record) to see if the sending server is on your approved list:

• Pass: If the server is authorized, the email passes SPF authentication. 
• Fail: If it’s not on the list, the email fails SPF.

What is the SPF “all” policy?

The SPF “all” mechanism is the final instruction in your SPF record. It tells email providers what to do when a message comes from a server that’s not explicitly authorized in your record. It’s essentially the default rule that kicks in when none of your specific authorizations match the sending server.

There are four possible “all” policies you can use, each with a different symbol that changes how receiving email servers should handle unauthorized messages.

• -all (Hard Fail): Reject emails from unauthorized servers completely
• ~all (Soft Fail): Accept emails from unauthorized servers but mark them as suspicious
• +all (Pass): Accept emails from any server (don’t use this—it defeats the purpose of SPF)
• ?all (Neutral): No policy specified (also avoid this—it provides no protection)

SPF -all (hard fail) explained

The -all policy tells receiving email servers to completely reject any email that comes from an unauthorized server. When an email fails SPF with a hard fail policy, it typically gets bounced back to the sender with an error message. 

That means it doesn’t reach the recipient’s inbox (or even their spam folder).

Hard fail sounds like the strongest security option, but it can cause serious delivery problems if you haven’t accounted for every legitimate way emails might be sent from your domain. The following can all trigger hard fails: 

• Email forwarding
• Backup mail servers
• Third-party services you forgot to include in your SPF record

This could cause some of your important (but maybe forgotten) emails to disappear entirely. 

The main risk with -all is that it’s unforgiving. If you miss even one legitimate sending source in your SPF record, emails from that source will be rejected. This makes -all a risky choice unless you’re absolutely certain your SPF record is complete and you have tight control over all email sending from your domain.

SPF ~all (soft fail) explained

The ~all policy tells receiving email servers to accept emails from unauthorized servers but treat them with suspicion. This usually means the email gets delivered, but might be marked as spam or given a lower reputation score in the recipient’s email system.

Soft fail provides a safety net that hard fail doesn’t offer. If you accidentally leave out a legitimate email service from your SPF record, emails from that service will still reach recipients—they just might end up in the spam folder. 

This gives you time to notice the problem and fix your SPF record without losing important messages.

Most email security experts recommend ~all because it balances protection with practicality. You still get SPF authentication benefits and protection against obvious spoofing attempts, but you’re less likely to accidentally block legit emails due to teeny-tiny mistakes.

SPF -all vs ~all: Which should you choose?

For most domains, ~all (soft fail) is the better choice. While -all might seem like stronger security, it’s riskier because it can completely block legitimate emails if your SPF record isn’t perfect (and we all make mistakes, right?).

The ~all policy gives you the same authentication benefits with a built-in safety net. Emails from unauthorized sources still get flagged, but they’re delivered to spam folders instead of being rejected entirely.

Only use -all if you have complete control over your email infrastructure and are certain your SPF record covers every legitimate sending source.

SPF “all” policy mistakes to avoid

Getting your SPF “all” policy wrong can cause everything from delivery headaches to serious security gaps. Here are some of the most common mistakes that can mess up your authentication:

• Using +all: This tells email providers that any server can send emails from your domain, completely defeating the purpose of SPF and leaving you wide open to spoofing attacks.
• Using ?all (neutral): This provides zero protection and essentially tells receiving servers “I don’t care who sends emails from my domain,” which isn’t much better than having no SPF record at all.
• Including multiple “all” mechanisms: Your SPF record should only have one “all” policy at the end (multiple ones creates confusion and can cause authentication failures).
• Email forwarding: Email forwarding often breaks SPF authentication because the forwarding server isn’t listed in your SPF record.
• Assuming stricter is always better: Many people think -all is automatically more secure than ~all, but it often just creates more problems (without providing meaningful additional protection).
• Not testing before going live: Jumping straight to -all without monitoring how it affects your email delivery can lead to blocked legitimate emails and confused recipients.

How DMARC impacts your SPF “all” choice

If you have DMARC implemented (which you should), your SPF “all” policy becomes way less important. DMARC takes over the decision-making process for what happens to emails that fail authentication checks.

When DMARC is active, email providers look to your DMARC policy (not your SPF “all” mechanism) to determine whether failed emails should be delivered, quarantined, or rejected. Your DMARC policy (p=none, p=quarantine, or p=reject) becomes the primary instruction for handling authentication failures.

This is why most email security experts recommend using ~all in your SPF record regardless of how strict you want your overall email policy to be. Since DMARC is calling the shots anyway, there’s no benefit to using -all, and you still get the safety net that soft fail provides.

SPF with ~all does the authentication checking and reports the results to DMARC, then DMARC decides what action to take based on your domain’s DMARC policy. The SPF “all” mechanism becomes more of a backup instruction that rarely gets used when DMARC is properly configured.

How to test your SPF record after making changes

After updating your SPF record, you need to verify that your changes are working correctly. DNS changes can take time to propagate, and syntax errors can break your entire SPF setup without obvious warning signs.

Start by using online SPF checking tools like Valimail’s domain checker to verify your record syntax and confirm it’s visible in DNS. These tools will catch formatting errors and show you exactly how your SPF record is being interpreted.

Send test emails from your domain to different email providers (Gmail, Outlook, Yahoo) and check if they’re delivered properly. Pay attention to whether emails end up in spam folders, which might indicate authentication issues.

Monitor your email delivery over the next few days after making changes. Watch for bounce messages or delivery complaints that might indicate your new SPF policy is too strict.

Use your DMARC reports to get detailed authentication data showing how your SPF changes are affecting real email traffic.

Simplify how you monitor your SPF records 

You’ve set up your SPF record with the right “all” policy, but you’re not done (quite) yet. Instead of wondering whether your SPF changes are working correctly or trying to interpret cryptic bounce messages, you need visibility into how your authentication is performing across different email providers.

Valimail Monitor gives you a clear view of your SPF authentication status along with DMARC and DKIM results. You’ll see which emails are passing authentication, which ones are failing, and most importantly, you’ll spot problems before they turn into major delivery problems.

It works whether you’re using ~all or -all, and it’s completely free.

Don’t leave your email authentication to chance. Sign up for Valimail Monitor (for free) to monitor all emails being sent on your behalf.