There is a trick. Sign up with them, configure custom domain, but don’t set your MX records. On your MTA, route mail that goes to Outlook/Hotmail to go through their MSA with your Outlook credentials and headers stripped as if submitted directly by user. Outlook gets mail through their own MSA it trusts, rest of the world talks to your mail system directly. Replies still go to your MXes.

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.

Funny, they have no problem handling mail for essentially every Fortune 500 company and others large and small.

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

Complain all you want about the monopolists, and I do think you're right to do so, but a lot of their power comes from and is aimed at defeating the overwhelming flood of spam.

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.

Decentralization is not a bulletproof solution. It is a mitigation. Until someone gets 50 percent of market share. Then they can run havoc on the ecosystem with their own customized system.

Why are we so willingly ceding one of the few widely used free and open protocols to a handful of $mega-billion providers?

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

Sounds more like using outlook.com is a mistake. I've been running my own mail server for over 20 years and outlook.com is literally the only domain I have had problems with, and this is the only reason that I now send via Scaleway's free transactional email service.

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.

Alt take: Using a Microsoft-hosted email service is a big mistake in 2026...

You can take my email server from my cold, dead hands.

Proudly self-hosting since 2001. My mail server is in my basement. Do not know what you are talking about.

Why?

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.

This is what google and microsoft want the make you think for obvious reasons.

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

Requiring DMARC may be good, but Outlook's approach is awful.

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.

No. You're supposed to understand how mail works on the Internet, and configure it correctly so that everyone else accepts it.

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

To be fair, DMARC has been required for a very long time. IIRC Google warned about 2 years ago circa that non-compliant emails would land in spam or be null-routed. And the DMARC noise started even before that.

As a company we realised about 12 months ago that email can no longer be considered a reliable method of communication. I understand the reasoning but the result is the result. Many new clients we deal with have whitelists on and we have to pester our clients to add us to their lists. Not a great experience for anyone. I think we should consider email pretty much moribund at this point.

You don't have to, this is the key reason to have a DMARC monitoring service. It will tell you when there's a deliverability issue with some particular receiver.

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

If running a mail server is central to your business, you should keep up with best practices. If not, 2 days of non-delivery aren't important, just resend.

Delivery to Microsoft's products has been patchy for several years. I am not remotely an email deliverability expert but I have made different SMTP service choices based on how companies approach shared-IP sending plans.

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.

That is not true. Reports are just one of the features of DMARC. The policy which allows you to instruct senders what to do with unauthenticated emails is the much more relevant part an when the receiver follows it, it very much does prevent spoofing.

DMARC gives you 20 reminders that you have sent an email, just incase you had forgotten.

It's an interesting argument. The fact this article exists is somewhat proof that it is a differentiator. The flipside, however, is that spammers very specifically require their emails to get to add many mailboxes as possible, so their motivation is greater to make their emails service compatible.

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.

> DMARC = telling receivers how to handle mail that fails authentication.

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

[delayed]

"Quietly" in the title is an AI slopspam pattern. It's an over-used teenager hyperbolic crutch word on par with "literally", "actually", "honestly" and similar.

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.

Selection bias: you don’t see the spam that get rejected at HELO.

No, not delivering is much better. You get a clean error message that tells you exactly what to do, it can be fixed in minutes. Spamfoldering email for not having DMARC would be a mistake, it might be years before low volume senders notice and figure out what's wrong (if they ever do).

I don't know. I think this disenfranchises a lot of independent operators, and the blow of that could at least be softened by making a highly-visible public announcement about it a few months ahead of time.

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

That is a burden definitionally, though; and that's to say nothing of the effort required to understand the technology and its impacts on operations.

Unfortunately, the people abusing these are very persistent and adding more checks will just increase the sophistication of such attacks which works against the interests of the target.

This stops disguising yourself as a legitimate service.

If they did that you’d decry censorship.

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

email is weird, without this it doesn't perform the checks at all

Agreed. There's no additional verity provided by adding a DNS record with a static line of text. Reminds me of airport security theater: meaningless hoops for citizens to jump thru under the guise of stopping bad actors.

Under RFC 7489 [1], a domain with no DMARC record simply has no DMARC policy, the receiver is able to enforce whatever policy it likes.

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/

Googling around this started at least a year ago, but I worked at an MSP 3 years ago when it was first announced and we started getting customers into compliance. This wasn't something out of the blue.

Replying to all inbound messages with a bounce is an old idea. The theory was that legitimate senders would validate their address and get added to a white list. The scheme didn't work for the same reason captchas don't work.

Do you know if it’ll affect my (personal) account? I run everything through a normal Gmail account and have forwarding for incoming email and an alias for outgoing stuff

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.

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

I suspect that he/she means they runs a mail server and it was up to his customers to comply, but now they’ve had to deal with the fallout from their customers not complying.

The customers have to do it themselves since they control their domains. I recommend doing everything correctly but also understand that this stuff is pretty hard for people just trying to run a small business. But if it makes you happy to feel smug you can carry on assuming.

"The old technique of adding the sender to your contacts doesn't work reliably anymore."

An Outlook user first reaching out to you, and you replying and including the unique message-ID of their original envelope in your headers, doesn't affect anything either. Absurd. The whole situation is complete dog shit.

Anecdotal. I've self-hosted for many years but didn't run into these issues with O365 until this year. But not surprised to hear it.

DMARC is layered across (/is useless without) two other protocols (SPF, DKIM), both of which also require DNS records.. there's no way to DMARC with one record.. unless you're excluding those SPF and DKIM records in your count. You /could/ DMARC with two records: DMARC+SPF, or DMARK+DKIM but it's ill-advised - use all three. (Ignoring host hierarchy/cname delegation, you can have far more records)