Right at the end of January, Microsoft appears to have made couple of changes to how they’re handling authentication. The interesting piece of this is that, in both cases, Microsoft is taking authentication protocols and using them in ways that are slightly outside the spec, but are logical extensions of the spec.
The first is an extension of DMARC. They’re rolling out inbox flags for Office365 users that identify some emails as Unverified Sender. It appears they’re basically doing DMARC verification whether or not the sender is publishing a DMARC record. They’re comparing the SPF and d= domains with the 5322.from to identify those senders that are unverified. Mail that doesn’t pass gets a mark in the inbox. Initial reports indicated that some messages were failing even if the authentication was in alignment as well as some increase in bulk foldering.
This is a very logical use of the concept of alignment. If the SPF domain or the d= domain are the same as the domain in the visible from, then it’s a clear sign the mail is actually from that company. And this isn’t new, companies were mentioning looking at the authentication and alignment for years. But it’s interesting that Microsoft is pushing that marker out to the user.
The other thing Microsoft is doing is around ARC. ARC is “authenticated received chain” and is one of the ways folks are trying to fix the breakage in forwarding introduced by DMARC. Essentially, when a company receives a message, they note whether or not the authentication passed, then sign the message with a ARC header (similar to a DKIM header). It’s a programatic way for a forwarder to say “hey, we received this and verified that it was authenticated and here’s our authenticating that fact.”
You may have seen ARC headers on some mail, Gmail’s been adding them for a while. At the end of January, I noticed that Microsoft was signing them fas well. But there was a bit of weirdness in it with regards to DKIM. Microsoft was asserting that they’d seen a DKIM signature that wasn’t available in the headers and a DNS lookup didn’t show any visible public key.
For Office365 tenants that have not implemented custom DKIM signing Microsoft is faking a DKIM signature and then wrapping that up in an ARC header and saying “yeah, this won’t authenticate for you, but we’re saying we authenticated it before sending it on.” The really clever bit about this is that there is no DKIM signature involved. Microsoft is using their login and customer authentication process to assign a d= to the message without forcing their customer to publish a DKIM key.
It does make for some messy headers (but ARC does that anyway). But it’s Microsoft saying “we authenticated that this person is legitimately using this domain to send mail even though they don’t have DKIM set up.” It’s outside the scope of the ARC protocol, but actually makes sense. Microsoft knows the user is legit and can just sidestep the work needed to publish custom DKIM.
Extend and Embrace, indeed.
RSS - Posts
What if the mail is DKIM-signed, but the sender- and from-domain are different (unaligned)? Will MS claim the sender is univerified even though it’s a DMARC pass?
When it initially rolled out, folks were reporting that Microsoft was marking fully aligned and DMARC passing mail as unverified sender. Asking around I am being told this is still an issue for some senders.
It’s not the first time Microsoft has marked authenticated mail as unauthenticated. The last time it took a few months to fix, IIRC. This is user visible, though, so it may be a faster resolution than that problem was.
If the signing domain isn’t aligned, then the message is not authenticated. You could assert that it hasn’t been changed in transit, but not that it’s authenticated.
The problem is, Microsoft is failing domains that are fully SPF and DKIM aligned with the authentication passing.
I hope they’re sticking to the DMARC spec and only requiring SPF OR d= to match the From, and not both!
I’m afraid this is still the issue with Microsoft: fully authenticated email from my business address still goes to junk at 100% of times and gets marked as Unverified sender.
Fun part is that the email headers show that all passes for Authentication-Results: in the outlook mailboxes. Still counts as unverified for some reason.