Sender Policy Framework (SPF): to Tilde(~) or to Hyphenate(-) the “All”
An Introduction to SPF’s “All” Versions
A question Tangent receives on occasion concerns SPF records and the optionality associated with the “all” mechanism that completes the SPF’s DNS record. Since the advent of SPF, two different versions of all the “all” mechanism have been available, each with a slightly different function. In practical terms, only one gets used today, but given how often this question has arisen, we’ve decided to create a brief look back at the history and purpose of the two versions.
To make envisioning this easier, imagine SPF as the bouncer at an exclusive club, deciding who gets in and who gets the boot.
Now, let’s dive into the nitty-gritty of SPF ~all and -all.
The Difference Between the All Mechanism Versions in SPF
SPF Basics: The Bouncer’s Guest List
SPF (Sender Policy Framework) is like a VIP list for your email domain. It tells the world which servers are allowed to send emails on your behalf, including marketing services like Constant Contact, MailChimp, SendGrid and others.
At the end of this list, you need a catch-all rule to handle the riff-raff. Enter the “all” mechanism, which is basically the bouncer’s way of saying, “And the rest of you, listen up!”
The Tilde (~): The Softie Bouncer
When you see ~all, think of it as the bouncer saying, “You’re not on the list, but I’ll let you hang around outside.” This is a “softfail.” It means the email didn’t pass the SPF check, but it’s not getting tossed out immediately.
It’s like getting a warning instead of being thrown out on the street and often wound up being used by email filtering services as a sign that the email should receive heightened scrutiny as potentially being harmful or spam, often qualifying for the Quarantine or Spam tags but still getting delivered to the end recipient.
The Hyphen (-): The Strict Bouncer
Now, -all is the bouncer with zero tolerance. If your email doesn’t pass the SPF check, it’s getting the boot. No questions asked. This is a “fail” and means, “You’re not on the list, and you’re definitely not getting in.”
Most email servers will outright discard these emails, treating them like they’ve shown up in flip-flops to a black-tie event.
The History of the Tilde and Hyphen
Before DMARC (Domain-based Message Authentication, Reporting & Conformance) came along, SPF was trying to figure out how strict it should be. Some bouncers (email servers) took -all very seriously and started discarding emails left and right, even legitimate ones (largely due to misconfigurations from the sending domain’s SPF record).
This caused quite a bit of chaos, like a bouncer who can’t tell the difference between a VIP and a party crasher.
To help ease the implementation of SPF and reduce the amount of people thinking that SPF was a terrible new feature of mail transfer (you might think so too if most of your email suddenly stopped getting delivered after turning it on, right?), the ~all mechanism was used to basically state that the sending domain was mostly confident in their SPF record, but to please treat any emails they send out that didn’t get onto the formal SPF record a little more gently and only mark them as “suspicious” or “quarantine” instead of outright rejecting them the way the hyphenated version would.
This was designed as a means of slowly stepping up the SPF policy of the organization over time, especially if they had lots of Shadow IT situations where there were potentially unknown senders that Proper IT was not aware of that may still have been important or necessary.
DMARC to the Rescue
With DMARC in the picture, email servers now have a better way to verify if an email is legitimate. In this context, ~all and -all both mean “NOT PASS,” but with the twist of letting DMARC have the final word on the matter and tying up the Tilde loose end.
With DMARC Director, our reporting interpretation and constant monitoring of alerts allows us to use the -all mechanism to find any email sending sources both in advance of fully enforcing DMARC rejection policies (for fraudulent or unauthorized emails) and after implementation, in case someone is trying to add a new service and didn’t run it past the IT team or those malicious guys out want to try and get around SPF’s other weaknesses to still make an attack.
Tying in DMARC with SPF allows for a far more secure method of handling email security that doesn’t allow for any wiggle room for the troublemakers out there.