new | show | ask | jobs Github

ranger_danger 6 hours ago

> Nobody announced it

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)

https://www.mailreach.co/blog/outlook-dmarc-requirements

▲

hedgehog 6 hours ago | parent [-]

That says for "high volume senders" but they now apply the rules regardless of volume.

▲

jared_stewart 4 hours ago | parent | next [-]

Yes, this is an older announcement from last year. Yahoo and Google did the same at that time.

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.

▲

ranger_danger 6 hours ago | parent | prev [-]

Is there any actual evidence of this outside of this one company's AI-generated article?

▲

jared_stewart 4 hours ago | parent | next [-]

There's been ample evidence of this, many different blogs, notification emails etc.

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.

	▲	majorchord 3 hours ago \| parent [-]
		Ample evidence that the policy now extends to low-volume senders? Could you provide even one example?

▲

Tomte 6 hours ago | parent | prev [-]

I got a bounce on a mail from my personal Fastmail account (with my own domain) the day before yesterday.

I had SPF/DKIM set up, just not DMARC. Did that yesterday and don‘t see the point. My policy is "none".

	▲	jared_stewart 4 hours ago \| parent [-]
		The point is to have a DMARC record, setting it to none doesn't really do much of anything for you though. If you really wanted to take advantage of it you will need a DMARC monitoring solution - the market seems to typically price these around $10/month for small-ish domains (though there are a lot of caveats). I'm trying to build a reasonable free option that maybe isn't enough to get a domain to a reject policy, but should be enough for you to maintain a reject policy. 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.