Posted by xmddmx 20 hours ago
However, it is worth mentioning that Gmail is fully dropping the ability to use a non-Gmail SMTP server as of January: https://support.google.com/mail/answer/22370.
They did: https://techcommunity.microsoft.com/blog/microsoftdefenderfo...
And it appears to be further documented here:
https://learn.microsoft.com/en-us/defender-office-365/anti-p...
https://learn.microsoft.com/en-us/defender-office-365/email-...
And other sites were reporting about it for at least a year and a half:
https://powerdmarc.com/dmarc-outlook-email-authentication/ (see #4)
That's an old announcement about a different change. As far as I can tell this one is completely out of the blue. I'm shocked by the number of people in this thread advocating for spontaneous changes without any warning.
The failure associated with that announcement is different. It is 5.7.515.
This new failure mode is "5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)", I haven't seen any formal announcement on my end. The important thing to know about 5.7.1 is that it represents a few different failure modes, the AS9031519 is the important bit and it indicates that the domain lacks a DMARC record.
This thread duplicates the first observations of this which showed up here yesterday at https://news.ycombinator.com/item?id=50404161
My mail provider, MXroute, sent me a notification of the issue early yesterday. There is commentary from various DMARC providers (Suped and PowerDMARC). This is a real thing.
It does not matter which host you are using, this has nothing to do with the hosting provider. It has everything to do with having your domain correctly set up on DNS so that anybody receiving mail will know how to authenticate it. Microsoft has apparently advanced a policy that if you don't even try you don't get to send.
IMO this is the right call, I've seen plenty of spoofing attacks where the attacker took advantage of nonexistent policy on non-sending domains. You might think that if you don't have an MX record the domain can't be used to send mail, that is wrong. The MX record only tells others where to send your mail, it says nothing about whether the domain can send mail itself.
I had SPF/DKIM set up, just not DMARC. Did that yesterday and don‘t see the point. My policy is "none".
The truth is that there are amply "non-sending" domains out there which ignore DMARC and allow abuse. Stopping the assumption of no policy mean p=none prevents this abuse from persisting.
New protocols only solved this by cutting compatibility. Signal can be E2EE because you can't send a message to an email address with it. Email can also be E2EE, but how do you know the recipient supports it?
I want something fundamentally new that doesn't stink of 70's era pre-security thinking.
A group of heavy hitters needs to just form a working group and propose Email 2.0. As long as it's supported by the biggest vendors and companies and they don't go all "IPv6: It's better because it's complicated!" on it people will sign up because it will be able to offer MUCH more in terms of features, usability, security, ease of hosting, etc.
We discovered when we set up a third-party to send via Amazon SES with one of our domains at the start of 2025 that Microsoft didn't correctly check DKIM alignment, and would incorrectly fail valid emails. The issue, so far as I could tell at the time, was that if an email had multiple (in our case 2) DKIM signatures, Microsoft's handling seemed to be non-deterministic, sometimes checking one signature, sometimes the other, and sometimes both. Of course, those times when it only checked one signature and that wasn't the one for the sending domain, it would then fail the alignment check, even though there was a perfectly valid and aligned signature right there it had just decided to ignore.
I raised it with Microsoft support at the time, but they were unsurprisingly useless, I think the most constructive thing they said was "just add the Amazon SES IPs to your SPF record", which, uh, no.
In the end, IIRC, we ended up setting up the third party to sign into a 365 email account on our domain we created for them so they could send through MS's infrastructure and avoid all that. So no idea what their DMARC checking is like these days, but I'd assume the same, if not worse.