Warning: this is an angry post. You might need some o’ this after reading.
Sadly, all it takes to find blatant misinformation about SPF is a search for “SPF.”
Scanning my recent Google alerts, I stumbled upon this fresh batch of wrong. And wow. It easily outdoes earlier examples for FUD and that weird wouldn't-it-have-been-easier-to-be-tell-the-truth quality.
To start, let's play Consider The Source. A hunch told me anybody so wrong about SPF in theory probably didn't have their own SPF set up right in practice.
Yep, like so many others, their SPF record breaks the fundamental DNS lookup rules and so in practice, they have no SPF record at all:
include:▓▓▓▓▓▓▓▓▓▓.net include:_spf.google.com include:ontimenow.com include:salesforce.com
This record requires more than 10 lookups when you chase down the includes. So much for waxing authoritative about SPF.
Although that should be enough to discard everything in the post, I can't leave alone some stuff that's just egregiously, even pointlessly wrong. What's the point of claiming:
If the SPF record exists, but the IP address of the sending mail server isn’t in the record, it’s considered a “hard-fail.”
That's only true if the SPF record ends with -all*. But the example record in the post ends with ~all! The tilde ~ is explicitly classed as a softfail and always has been. So this is both confusing and wrong.
At least the next line is mostly right:
This can often cause mail to be rejected or routed to the spam folder.
If we're talking about an actual -all now, yes. Although it would've been better to spread the word that a fail (it's actually called a “fail”, not a “hard-fail”) will usually (as opposed to merely often) cause mail to be rejected when SPF is being usefully checked.
Anyway, they ruin any lingering goodwill with:
If no SPF record exists at all, this is considered a “soft-fail.” [sic]
This is ludicrous. Completely false. There could not be a more wrong interpretation of what it means to be missing an SPF record. If you're missing an SPF record, the RFC specifies an explicit result for that case: none, which is emphatically not a softfail. Like, at all.
And they continue to offend reality with this head-scratcher:
[“None” results] are most likely to cause messages to be routed to spam, but can lead to a message being rejected as well.
Um, no. Having no SPF record does not cause messages to be rejected. Back in the day, we used to fantasize that SPF would be so commonplace that merely lacking a record would be grounds for extreme prejudice. It didn't work out that way.
Maybe there are some crazies still running their own home-brewed mailservers (likely the same ones they were running in 1999) who reject email from domains without SPF. That's not the real world. In the real world, not having SPF simply means your emails don't get any positive weight that they might get from an SPF pass in a typical multi-test matrix.
So the final effect may be that the message goes to spam quarantines/folders, if it was already leaning toward spam. It doesn't get bounced for having an SPF none, nor does none “cause” a message to miss the inbox.
The DKIM section
This section is… fine!
The DMARC section
This section of the blog post is surprisingly okay as well. It leaves out an important part of the interaction between SPF results and DMARC results, but there isn't any clear misinfo.
Takeaway
Trust no one. Except me.
Notes
* Or if there's an explicit - qualifier in the record that singles out the sending host as a fail. I guess it's acceptable to concentrate only on all since that's the way most people deploy SPF.