Definition
The SPF all mechanism is the catch-all term at the end of an SPF record that defines the default result for any sending IP not matched by earlier mechanisms. It is written with a qualifier — +all, ~all, -all, or ?all — that tells receiving servers whether to accept, softfail, hardfail, or remain neutral about unmatched senders. The choice of qualifier is one of the most important decisions in an SPF record.
How It Works
An SPF record lists authorised sending sources, then concludes with the all mechanism. The qualifier determines the fallback result:
| Qualifier | Meaning | Effect on unmatched IPs |
|---|---|---|
-all |
Hard fail | Treat as unauthorised; strict rejection signal |
~all |
Soft fail | Treat as suspicious; often accepted but flagged |
?all |
Neutral | No assertion; treated as if no SPF result |
+all |
Allow | Authorises all IPs, defeating the record's purpose |
The +all qualifier is effectively useless for security because it authorises every sender, while ?all makes no meaningful assertion. In practice, legitimate senders choose between -all and ~all.
Why the Choice Matters
The all mechanism determines how strictly receivers apply SPF. A -all record tells receivers to reject mail from IPs outside the list, which is the strongest protection against email spoofing. A ~all record is more forgiving, treating unmatched mail as suspicious but not necessarily rejectable.
Senders often start with ~all while they confirm all legitimate sources are listed, then move to -all once they are confident. Because SPF can be broken by forwarding, a -all record can cause legitimate forwarded mail to be rejected, which is why some domains keep ~all as a permanent compromise.
For DMARC purposes, either -all or ~all can contribute to authentication, but alignment still applies. The key is that the record ends with a deliberate, protective qualifier rather than +all or nothing at all.
Example
A company publishes v=spf1 include:spf.protection.provider.com -all. When mail arrives from an IP not listed by the included record, receivers treat it as a hard fail. A spoofed message using the company's domain from a foreign IP is therefore clearly flagged rather than accepted.
Was this useful?
Related Glossary Terms
Abuse Complaint
An abuse complaint is a report from a recipient who marks an email as spam, which negatively affects sender reputation and deliverability.
Alt Text
Alt text is the written alternative to an image in an email, displayed when images are blocked, slow to load, or consumed by screen readers.
AOL Mail for Email Marketers
AOL Mail is a legacy email provider with specific deliverability requirements and rendering quirks, now operating as part of the Yahoo+AOL network under shared infrastructure.
Email Authentication Protocols
Email authentication protocols are technical standards that verify the identity of an email sender, helping mailbox providers distinguish legitimate mail from spam and phishing.
BIMI
BIMI (Brand Indicators for Message Identification) is an email standard that allows brands to display their logo next to their emails in supported email clients. It requires DMARC enforcement at quarantine or reject policy.
Bounce Management
Bounce management is the process of handling emails that are rejected by mailbox providers, including classification, removal of bad addresses and protection of sender reputation.
Frequently Asked Questions
Use `~all` while you are still confirming all legitimate sending sources are covered, then move to `-all` for stronger protection. Many senders keep `~all` long-term if their mail is frequently forwarded, since `-all` can cause forwarded mail to be rejected.
`+all` authorises every IP, meaning the SPF record asserts nothing useful about who may send on the domain. It should be avoided, as it provides no protection against spoofing.
Yes. The SPF result feeds into DMARC evaluation. A hard fail (`-all`) combined with SPF alignment can produce a DMARC fail for unmatched mail, while a soft fail (`~all`) typically does not cause a DMARC fail by itself.
An SPF record without a terminating `all` mechanism returns a neutral result for unmatched IPs, weakening the record. Best practice is to always end the record with an explicit, protective `all` qualifier.