The short answer is the ~all qualifier, often called a "SoftFail". When a receiving mail server checks your domain's SPF record and finds that the sending IP is not on the list, the ~all mechanism tells the server to accept the email but mark it as suspicious. This is different from a "HardFail" (-all), which instructs the server to reject the message outright.
Sender Policy Framework (SPF) is a fundamental email authentication protocol. It allows domain owners to publish a list of authorized IP addresses that can send email on their behalf. When an email is received, the recipient's mail server can check this list to verify the sender's authenticity, helping to prevent email spoofing and phishing.
An SPF record is made up of mechanisms and qualifiers. The mechanisms define which servers are allowed to send mail, while the qualifiers tell the receiving server what to do if an email comes from a server not on the list. The most important mechanism is the all mechanism, which is always placed at the end of the record and acts as a default catch-all. The character preceding all is the qualifier. Here’s a breakdown:
The primary use for a SoftFail (~all) is as a transitional step. When you first implement SPF, it can be difficult to identify every single service and server that sends email on your domain's behalf. Using ~all allows you to start the authentication process without the risk of legitimate emails being outright rejected. As stated by GoDMARC, a SoftFail allows the sender to receive feedback on authentication failures, which is invaluable during the setup phase.
The goal is to eventually move to a HardFail (-all) for maximum security. A SoftFail should be seen as a temporary measure while you gather data and refine your SPF record.
It's crucial to understand that SPF qualifiers are essentially suggestions to the receiving mail server. The server can choose to follow the suggestion or handle the email differently. This is where DMARC (Domain-based Message Authentication, Reporting, and Conformance) comes in.
DMARC allows you, the domain owner, to specify exactly what should happen to emails that fail SPF or DKIM checks. A DMARC policy of p=quarantine or p=reject will override the SoftFail suggestion. For example, if your SPF record has ~all but your DMARC policy is set to p=reject, an email that fails the SPF check will be rejected. This makes DMARC an essential part of a complete email authentication strategy, working alongside SPF and DKIM to secure your domain.