Outlook.com is rejecting email from domains without DMARC (mailroute.net)

Experience shows that the walls will get taller and the moats will get deeper.

At the most you need to use an external service for delivery (usually because you have problems with MS) but you can still run your own server with no difficulties once you do that.

That said, DMARC is required by a lot of people now, so I do not think this particular issue is a problem.

I have been self hosting my my personal email (and for family). Few problems so far other than delivery to MS and I have recently moved a domain I use for work email over.

Oddly enough the MS problems come from hotmail, but not other services. If that is a problem, then pay a bit to have email delivered.

The people working on outlook.com are just talentless amateurs - the rest knows how to do it right. It's a shame it's so widely used.

Fortunate for those running their own servers is that they actually still get all the cool emails from people not complying.

I haven’t productionized this setup (I send maybe a dozen emails a year) but it worked for me ad hoc a couple years back, when I had to send a mail to an Outlook-hosted address and they blackholed everything I tried to send while 250 OKing me.

It's always people self-hosting mail on a shared server in Moldova (because they think it makes them cool) that are complaining.

Mail, then emails, then home phones, then cell phones, then texts, then social media have been gradually rendered less and less usable by bad actors systematically abusing every single tool we try to use to communicate with one another to steal from us, lie to us, and manipulate our beliefs, and we'll just keep inventing and discarding new ways of communicating until we reckon with this.

But we won't.

So that people would vote for the government to manipulate them instead?

Honestly, I hate outlook as much as you do, but I'd still prefer it to Max

https://en.wikipedia.org/wiki/Max_(app)

Oh man, please tag me if you're ever the lead on any project so I know to stay far away from it.

I was working for Microsoft when outlook.com launched and got a good email address that was my primary for more than a decade.

I had so many issues with things getting silently dropped with no recourse (2FA codes, account recovery mails, etc.) on so many sites that I finally gave up, reversed the stream, and had Outlook forward to GMail instead of vice versa. A few months after that, I realized that all my Outlook got was an enormous volume (hundreds of day) a spam and that all legitimate mail was going to my other accounts, so I turned it off entirely and haven't read that mailbox in over a year.

I have access to a fairly large dataset of known bad hosting providers, but most people don't. So how do you tell the difference between getting a good deal and "this is cheap because it's sketchy as all hell".

We also don't block all of Vietnam, or all Jio customers in India, even if we know that 20% of bot traffic is from those two alone.

Wait until this guy realizes that all spam these days comes from Azure ASNs, and abuses cross-tenant issues as well as a simple "Fwd: ..." and "Re: ..." tricks to bypass Microsoft Outlook spam filters.

Stop being so ignorant

Mildly infuriating for emails containing OTP codes "valid for 10 minutes".

They are the reason I dropped self-hosting my mails. They were silently dropping some of my mails depending on the day I sent them. If they were at least sent to the spam folder, it would be easier to communicate with their users. And since a lot of their users are not technical at all, it's complicated to explain them the issue.

It's absurd in every way. I was trying to get it to stop spamming maillist traffic. It's impossible. Global level filters enacted as admin to not spam check are ignored.

Company sys admins have likely got all sorts of other issues to worry about, and the occasional report of an email not getting through is likely low on their to-investigate list.

Having said that, I self host a mail server, and have all those things setup correctly, and my workplace uses Outlook, and I've not had issues with delivery, so it's not a particularly difficult bar to jump.

Go to https://mail-tester.com. Send a test email. If you don't get 10/10, fix your shit.

Some can affordably deliver to Microsoft because they aggressively police what they are actually sending on their customers' behalf; others don't get involved and you end up having to spend a fortune on a dedicated IP.

The DMARC thing is just another part of this; one of my clients discovered this silent failure themselves a few weeks back and addressed this.

DMARC applies not on your mail server, inbound or outbound, but on the server that is receiving your mail (which may in fact be your mail server).

That server will look at how the mail authenticates and decide if it should allow the mail to proceed, it (for the most part) will then tell you whether or not it allowed the mail. This is how you will know you might have a deliverability problem before your customers do.

If you're wanting to know about deliverability (particularly for this Microsoft case), my company (Alesian Security) has a free check at https://alesiansecurity.com/try?tab=deliverability

DMARC doesn't introduce a new security mechanism by itself, but it fixed a few bad security flaws in SPF and DKIM. Without DMARC, SPF and DKIM do not add meaningful security.

DMARC updated and formalized how receivers should handle authorization and authentication of inbound email by adding the alignment requirement. Alignment ties the SPF and/or DKIM domain to the rfc5322.From domain. This also allows receivers to use domain reputation rather than IP-reputation.

SPF by itself has a bad design flaw that completely breaks any security that SPF was supposed to provide. By adding DMARC this security hole is fixed. (Although SPF is still horribly unreliable, it should be considered legacy at this point, don't rely on SPF).

DKIM benefits from DMARC alignment requirement too. DMARC ties the rfc5322.From domain to the DKIM signing domain, which makes DKIM practical for sender authorization, not just authentication.

The the existence of a DMARC assertion record in the DNS changes how the MTA (the receiving system) assesses the authentication of the message and authorization of the sender with SPF and/or DKIM, as per rfc7489 (and now also rfc9989).

No DMARC results in the MTA falling back to the original assessment method as defined in the original SPF and DKIM RFCs. These RFCs have design flaws and don't define the assessment flow all that well, they leave a lot up to the MTA's digression/interpretation.

So, the existence of a DMARC record with p=none is fundamentally different over not publishing a DMARC assertion record at all. It's just that with p=none you don't enforce the MTA to reject the email if it fails authentication/authorization, you're leaving it up to the MTAs digression.

No. DMARC is about if the from address has to match the address used in dkim/spf

A specification exists since 2012, 14 years ago. 10 years ago it was already old.

Back then, I didn’t use Terraform or anything like that, but I had text files with logs that described the DNS setup in detail so I could fix things. By grepping through the logs, I’m able to put a definitive bound on when I added DMARC—it was no later than June 2016, over 10 years ago.

At the time I thought, “Obviously, we should all be setting this up, because recipients will start rejecting mail from insecure domains, if they don’t already.” This was also back when I self-hosted email. I eventually stopped doing that because I thought it was too time-consuming.

>But for small personal domains the value isn't that high.

I don't understand the resistance. It benefits the entire mail ecosystem, not just mass senders.

SPF used to be niche thing, then everyone realised it's a good idea and it became more-or-less mandatory. Same with DKIM. Now it has happened to DMARC as well.

Sometimes it's use is appropriate, but not in this case. Microsoft announced this change loudly, multiple times, starting more than a year ago. I seem to recall one of those announcements being discussed here on HN. Even the article links to it's own previous announcements, so "quietly" here is stupid rage bait to justify a blogspam advert.

This stops disguising yourself as a legitimate service.

Allowing basically ~whatever, but proving the sender address is an obviously good approach to me.

Maybe you're right that just enforcing it is the way, but I don't agree with doing that with no heads up.

Some additional context:

- I checked online and they do have this email address listed on their pages

- This affected 2 separate domains served by Microsoft

- I sent them an inquiry email now from my @gmail.com and no bounce was returned so far

EDIT: Also gmail got the error response, so I guess it's really up to the outlook server these unrelated entities use...

Most receivers have chosen to treat this as p=none for the last decade (Microsoft included). This is changing to now so that mail with no record is simply refused. Nothing in the standard prohibits this.

a DMARC of p=none might be seen as ambiguous - SPF and DKIM have their own jobs and they work. However, the point of DMARC is not a new way of enforcing mail authentication. Instead it is a way of making certain that the mail is internally consistent and furthermore provides two additional things.

1. it indicates if the domain owner has thoroughly gotten their mail to authenticate (in which case they adopt a p=reject), and

2. it provides a feedback mechanism that allows the domain owner to know if they are seeing authentication and deliverability problems in such a way that they can fix those broken mail flows.

[1] https://www.rfc-editor.org/info/rfc7489/

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.