Microsoft ignores SPF hardfails

Mail has been around for ages and spam right along with it. However, there have been many methods to try to prevent spam and the Sender Policy Framework (SPF) is one of them. SPF targets spoofing and allows a domain owner to designate certain (sets of) IP addresses as valid sources for e-mails for said domain. But some of the largest providers in the world for e-mail services don’t bother following the standards properly, letting fake e-mails pass as if legitimate.

SPF works by setting a DNS record, either TXT or SPF, with a certain format that lists IP addresses, trusted mail exchange (MX) hosts and a ruleset. Full details, documentation and validation suites are on An example could be, such as with my mail server: IN SPF “v=spf1 -all”

The domain in this case ( allows MX servers for its domain to send e-mail using the domain ( but noone else (-all). This is a rather effective method to get rid of e-mails from spoof mailers (like the well known, easily found Whichever server tries to send from should fail if the receiving server looks up SPF records for the MAIL FROM command in SMTP.

SPF works to validate a domain if DNS lookup works. If lookup fails, because of error or non-existing SPF rules, it just means less data for the spam filter to consider. If SPF gets a “pass”, it really doesn’t mean much, as anyone can get an SPF record for their own domain. However, you can’t modify anyone _else’s_ SPF records to _include_ your own domain. So spoofing gets harder (though still possible with the From: e-mail header of course…).

Not everyone use, supply or check SPF of course. But most of the large providers of e-mail do – publish policies and validate when receiving. But the notorious providers Google ( and Microsoft ( etc.) both apply “~all” rules instead of “-all”, meaning to “softblock”. This just causes a dip in the common spam filter methods, it won’t cause the e-mail to get dropped (by standard). But it’s better than nothing I guess… (my server is configured to interpret softfail as hardfail).

So, to the point, I publish a rule for which uses “-all”. I tell remote servers, which validate SPF, to DROP ALL e-mails that aren’t listed in my SPF record (i.e. MX for Then why does Microsoft happily pass SPF-denied e-mail through even though it expressly hardfails? Sure, the standard doesn’t explicitly say the mail should be dropped (either deliver somehow or give an error message) – but then what’s the point of having both soft- and hardfailing mechanisms?

Received-SPF: Fail ( domain of does not designate as permitted sender); client-ip=; helo=localhost;

In the case of my domain name I also deploy DomainKeys, which has caused my mail to at least get dumped in the “junk mail” folder. However, for a friend’s address which deploys only SPF and no DomainKeys (and no DMARC policy), Microsoft delivers e-mails from the known spoof service straight into the inbox (if the spoofed address has at least once been accepted before – such as the common case where a legitimate mail was dumped in the junk bin).