Your SPF record ends in one of three ways: ~all, -all, or the trailing tag is missing or set to +all entirely — and that last piece decides what happens the moment someone forges your domain. Pick the wrong one and you either let spoofed mail slip through with just a spam-folder warning, or you risk rejecting a legitimate message from a sending tool you forgot to list. SPF is a DNS record that lists which mail servers are allowed to send email for your domain, and every receiving server checks it against the sender's IP address before deciding what to do with the message. EmailControl reads that record on every scheduled check and flags an ambiguous or missing trailing tag before it costs you inbox placement.
This decision looks small — one character at the end of a DNS string — but it is the single setting that determines whether a spoofed invoice email from "your" domain gets rejected outright or lands quietly in a customer's spam folder where they might still read it.
What Does SPF ~all (Soft Fail) Actually Do?
The ~all tag tells a receiving server that a message from an unlisted source probably is not legitimate, but to accept it anyway and mark it for extra scrutiny. Most inboxes route a soft-fail message to spam rather than bouncing it. This makes ~all forgiving while you are still confirming that every legitimate sending source — your marketing platform, your CRM, your helpdesk tool, your invoicing software — is included in the record.
The trade-off is that ~all does not stop a spoofed message from landing in someone's spam folder. It still delivers. A recipient scanning their spam folder can still open it, and a determined attacker knows that. If the goal is to keep forged mail out of your customers' spam folders entirely, soft fail alone does not get you there — it is a transition state, not an end state.
What Does SPF -all (Hard Fail) Actually Do?
The -all tag tells the receiving server to reject a message from an unlisted source outright, before it reaches an inbox or a spam folder at all. This is close to what Google and Yahoo expect from anyone sending meaningful volume — their bulk-sender requirements call for aligned SPF as a condition of reliable inbox placement, and a permissive record works against that.
Hard fail only works safely once every legitimate sending source is confirmed in the record. Miss one — a forgotten transactional email provider, a sales tool sending on your behalf, a support platform replying from your domain — and -all rejects your own mail along with the forged mail. The receiving server cannot tell the difference between a source you overlooked and an actual forgery; both simply fail the same check.
Soft Fail vs Hard Fail: Side by Side
Put next to each other, the difference comes down to what happens the moment a receiving server does not recognize the sending source.
| Behavior | ~all (soft fail) | -all (hard fail) |
|---|---|---|
| Unlisted sender is | Accepted, flagged | Rejected outright |
| Typical destination | Spam folder | Bounced before delivery |
| Risk if a sender is missing from the record | Low — mail still lands, just filtered | High — legitimate mail bounces |
| Best used | While you confirm every sender | Once every sender is confirmed |
A third option, +all, accepts mail from anywhere and authenticates nothing — it makes the record worthless for spoofing protection, and most monitoring tools flag it as a misconfiguration on sight rather than a real policy choice.
Do Multiple Sending Platforms Change This Decision?
Most domains past a certain size are not sending mail from one place. A typical setup has the primary mailbox provider, a marketing platform sending newsletters, a CRM sending sales sequences, a helpdesk replying to support tickets, and an invoicing tool emailing receipts — five sources, one SPF record. Every one of them has to appear in the same v=spf1 line for -all to be safe, and every one of them has its own SPF include mechanism (something like include:_spf.provider.com) that you copy from that provider's documentation, not guess at.
This is also where the ten-lookup limit on SPF matters: each include mechanism costs at least one DNS lookup, and a record that references too many providers can hit that ceiling and return a permanent error regardless of which trailing tag you chose. If you are adding a fifth or sixth sending platform, check the total lookup count before you also flip to hard fail — fixing two problems in the same DNS change makes it harder to tell which one caused a bounce if something breaks.
How Do You Know When You're Ready to Switch to -all?
Moving from soft fail to hard fail is a one-line DNS edit, but the readiness check behind it takes real effort. Work through it in order rather than skipping straight to the edit:
- Publish
~alland let it run for at least two to four weeks. - List every platform that sends mail on your domain's behalf — website host, helpdesk, CRM, marketing tool, invoicing software.
- Add every one of those sources into a single, unified
v=spf1line; two separate SPF records at the same hostname trigger a permanent error and neither one evaluates. - Watch your outbound mail for a week and confirm nothing is landing in spam because of a missing sender.
- Change the trailing tag from
~allto-alland re-check the record immediately after the DNS change propagates. - Watch your monitoring closely for the first 48 hours after the switch for any bounce tied to SPF.
Most domains that get burned by -all skip step one and go straight to step six, which is why the observation window matters more than the DNS edit itself.
What Should You Watch For After Switching to Hard Fail?
The failure mode with -all is quiet: a legitimate email bounces and nobody flags it internally, because the sending platform's own log still shows the message as "sent." The recipient never sees it, and you find out only when someone asks why they never received your invoice or your password reset.
That is the specific gap EmailControl closes for SPF policy changes: it checks your record on a schedule and flags an ambiguous or newly broken ~all/-all/+all state the same day it appears, instead of you finding out from a customer weeks later. See exactly what EmailControl checks on every SPF scan.
What's the Real Objection to Enforcing -all?
The honest objection is fear of blocking your own mail — nobody wants to be the person who flipped a DNS record and broke invoicing for a week. That risk is real, but it is front-loaded: almost every missing sender shows up in the first few days of running ~all, not months later. The organizations that get burned by -all are the ones that skip the soft-fail observation period entirely and jump straight to hard fail after reading a single blog post telling them to. Run the checklist above, watch the first two days closely after the switch, and the risk drops to close to zero.
Get Started
If your SPF record still ends in ~all and you are not sure which senders are actually using it, that is the first thing to confirm before you touch the record. Start free monitoring on one domain — it checks your current SPF tag today and tells you whether it is safe to move to hard fail yet.