Outlook.com and similar are an anathema to email. This is why they tell you not to run a mail server .

On the other hand rejecting domains without dmarc is fine. Just not happy it is silent.

I bet Microsoft is single-handedly responsible for 80+% of complaints about email being impossible to host.

In a federated / pseudo-decentralized network, any provider with 10+% of captive users has an outsized leverage on the entire ecosystem. You don't need a monopoly; as long as you have a monopoly on just a few users that others absolutely need to be able to interact with, you can dictate terms to everybody.

I wish I could just wholesale block gmail.com like people used to do with the early webmail providers.

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.

Based on my broad experience, I’d comfortably rank Microsoft as the worst of the major email providers. (I am owner poste.io)

Yes, that may turn some users away, but they would complain and leave anyway, because they don't receive emails from your server. On the other hand, that's how one can contribute to unwinding ms's share of email accounts.

It should be the other way around though.. More people should run their own mail servers so that centralized players cannot control what should be a decentralized communication protocol.

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.

I ran a SaaS up until recently. Emailing users notifications for events was just a normal part of the app. Users got upset when the emails didn't come through. So then I had to be email tech support for something I had no control over. Lovely.

Which with cheap models like Jev as spam classifiers, this can now become a reality.

The problem is, Google and Microsoft have monopolized the entire email market, so their esoteric deliverability mysticism from 2007 still persists (basically blanket bans on entire IP spaces, locking out anybody trying to send emails on their own).

Email naturally followed this evolution.

Switch Moldova to almost any country (or even a state that isn't California or Washington), and it's the same story everywhere

You shouldn't own your car or your house, give them to all the corporations as well.

As soon as you want to do business with Outlook's customers, you play by their rules.

"They're allowed to do it" is one of those things that doesn't really bear saying so much because that's already been implicitly established. Nobody is claiming what they're doing is illegal, so how does this add anything of value? Who is still unaware that corporations will use their size and market control to their benefit?

I've never even had the key to mine. I've lived here over a decade.

With LLMs on the other side trying to make spam less detectable by cheap models like Jev?

It's funny when people assume benefits from some tech go one way and baddies will surely never use it...

https://www.mimar.rs/blog/a-journey-of-my-mx-server-to-new-r...

And yes, it's cool not to have to let scum read your private communications :D

Four hours later, I got the same message by email. I thought he was back - nope. An email sent at 10am that was delivered at 4pm showed it was from 2pm until I looked at the header and saw sent at 10am and just... chilling out for 4 hours. DMARC was set up for them just fine.

I've had the same issue with my own custom domain, with DMARC set up. A year later, it finally got bumped up to some sort of "trusted" domain for that one place and my emails get delivered the same day now.

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

Yes, no one should not have DKIM or DMARC but holy yikes when neither side wants to actually give in to help the customer.

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.

This is not unique to Microsoft and really the source's problem — they did something to get blocked in the first place.

Add in the fact that you're almost certainly not the only one impacted, and that they have no interest in fixing it, it screams incompetence on the source's part.

Been there, done that, good luck explaining the problem to the app's first-level support in the Philippines because it's not in their script.

> and had Outlook forward to GMail

Till the day GMail hits you with the "We couldn't verify it's you" bullshit and locks you out of your account forever. Good luck getting support from Google, the word is not in their lexicon.

I've never encountered this issue with GMail. Delivery just works. I'm trying to think of the last false-positive spam flag I've had with GMail, and I've definitely never had mail be entirely dropped.

This is also true of Microsoft though.

Stop being so ignorant

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.

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.

AI becoming faster empowers attackers far more than it empowers defenders. We're seeing this in every discipline and every corner of the software industry.

I'll never pay for email so your options are either outlook or Gmail and I don't trust Google.

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.

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

The solution is allow only communications that are demonstrably not spam and not unwanted.

There have been lots of proposals to this effect but maybe you have to put up two cents in a crypto wallet, which the other person can claim if the mail is unwanted. If someone takes your two cents, you remove them from your lists ASAP. The receiver doesn't benefit meaningfully from the 2c so they are unlikely to claim it. The sender is only damaged if a lot of different people claim the 2 cents. Maybe a few domains are default whitelisted even if they don't put up 2 cents, to protect against entities that are important but would be frequently spite-claimed (IRS, courts, and other similar). If you use a provider that doesn't whitelist, fine, but you're going to miss those emails.

Maybe the top 'spite claim' users are published and it becomes difficult to get people to agree to put up money to talk to you.

This reduces spam to the level of junk mail, which is still not totally trivial but is orders of magnitude more manageable.

There is and it's the same as other protocols including proprietary ones - a sender address whitelist.

There's no proprietary protocol that solved spam either.

Seems they are the disease not the cure

Lately I've also been getting a lot from compromised MS365 accounts.

It seems insane that gmail doesnt provide a way to automatically send a mail (eg based on domain, keywords, etc) to spam. I know theres block sender but for example aliexpress uses a different name for every email so that's useless.

What this is called is survivorship bias. The question I would ask is how much mail are you not seeing at all because it's dropped at the edge first thing because it's IP block listed?

Next, how much spam are you seeing from them because they and Google are the largest providers on Earth? Kind of like selecting a random person from the population in the US and going "look, it's a white guy". Yea, that's how statistics works.

Lastly, because the are good at blocking spam at the edge, then that's the last bastion of attack for spammers to put their efforts in if they want any return at all.

Self-hosting allows me to use a different receiving address for each entity I contact, so I know exactly who put me on spam lists and if it gets bad I can route that address to the garbage bin.

These entities communicate via plain old mail, that costs more than 2 cents already.

We have dozens of different ways to send E2EE messages to each other, with realtime publish-subscribe, and yet billions of dollars are spent trying to duct tape email. Who cares if Outlook/Gmail/Icloud use IMAP or Websocket? If the interface looks the same to the end user will they really care?

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

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.

What about tencent.com, foxmail.com, or qq.com?

Most of them wouldn't even care probably...

User signs up, uses @outlook. Your app declines it and explains that they block with no way to remedy, and explain they are a bad vendor.

Emails would be accepted by Outlook.com, but would never deliver. We had SPF/DKIM/DMARC and full reporting. They RBL'ed us with no remedy.

We told the customer to not use outlook.com BECAUSE we told them we could not guarantee any delivery of messages.

Means you're not using your email seriously. For example, to send CVs in response to job postings.

I send up to 20 email per day to people who have issues with their package build scripts, and I have no idea whether they ignore me because they stopped using the distro or because mail got dropped.

You should be able to see this on your DMARC dashboard

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

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.

Good for Microsoft customers and I don't care one bit for the lazy people who have to late-patch now.

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

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

It's been a while, but monitoring DMARC seemed pointless once you got things started. If my outbound mail fails to validate, I've asked the receivers to bounce it, and I should be able to see that on my own system.

Otherwise, I'm just getting reports about spoofed spam or people who need to adjust their mail forwarding, but I can't do anything about either.

But it provides a safe guard against accidentally broken mail flows as your email stack evolves over time which is where it pays dividends.

I would love to say that it would have alerted you ahead of time to this particular event, but given that it's the fix here you would never have seen it.

Also why they do non-standard stuff like accepting mail but then simply not delivering it, rather than bouncing it.

"Reputation scores" and blacklists / greylists started in late 1990s / early 2000s as multiple grassroots efforts when spam started to overwhelm systems. Gmail did not exist, outlook.com did not exist, it was easy and expected to run your own SMTP (which I did). And it was very unpleasant.

DMARC appeared 10 if not 15 years ago. There's no reason for a sane MTA configuration not to have it.

- it was a way to outsource the mail server administration and already free in our corporate package

Which is pretty much all I have from the corporate side. On the personal or small business side its most often

- I don't really care that much about running my own stuff

- I needed a personal email address

All these are valid reasons/motivations but none explicitly argue that email messaging should become proprietary.

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.

It doesn't prevent spoofing, it doesn't say which IPs are authorized to send on behalf of a domain, it doesn't sign messages. Spoofed messages are still sendable.

Can you explain the benefit of only accepting email if Microsoft knows that you may or may not accept emails about scammers unsuccessfully spoofing your email domain? (Note, there's nothing you can do if they do tell you.)

Don't confuse DMARC with DKIM or SPF; DMARC doesn't actually do anything for email security.

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.

"Oh, please, don't ignore the other two ways I told you to ignore unauthorized messages" shouldn't need a knob.

You get an email without a DKIM signature from me.

Is that because I do not use DKIM and do not sign my emails or because the message is forged and not from me at all?

You cannot tell. There is a single SPF record that you can look up to see if SPF is configured. It's just a TXT record on the domain. But there is no standard DKIM record. A DKIM signed email tells you what key identifier it used and you have to use that to look up the DKIM key at <key identifier>._domainkey.<sender domain>. When the email has no DKIM signature you cannot tell if that's because the sender domain does not use DKIM or if it does have a DKIM key record but it was not used, potentially because the email is forged.

Or do you think it's critical to support mail that doesn't have dkim?

Setting a DMARC policy that allows unsigned emails is easier than configuring DMARC signing including key management. It's just adding a DNS record. Although large senders should of course do DKIM and it's not that hard either

But I'm not arguing with you about whatever Outlook did.

gmail runs with p=none

so tell me what benefits that has over having no dmarc record at all ?

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.

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.

[0]: As in: They accepted the email just fine (according to the logs) but it still didn't end up in the recipient's mailbox.

I had kinda assumed that a lot of providers would start rejecting domains without DMARC support. I'm surprised it's happening this late.

When I ran that server, outlook.com was also the only one that would blackhole my email for no known reason. Support was unhelpful and also could not point to any reason. I've since given up, but for a short time it was glorious, email to family would not leave the lan and we could send attachments of arbitrary size.

[0] https://news.ycombinator.com/item?id=7708882

Is there a risk some people on this thread are mixing up DKIM and DMARC?

DKIM = proving that an email was sent from a specific domain using cryptography. Good for spam fighting and deliverability.

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

DMARC is primarily useful for large, complex organizations where email admins may not be aware of everyone inside the org who is sending mail that advertises the domain in the From header, or organizations that might be targeted by impersonation attacks (e.g. phishing). Being able to tell recipients "yes we absolutely have our act together so feel free to reject or spamfolder unauthenticated email" is great for killing phishing campaigns, and being able to request reports is great for finding that one sales org that signed up for a guerrilla marketing SaaS that's impersonating them.

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

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.

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

DMARC is primarily about "alignment" (switching SPF from caring about the envelope sender to instead using the from header). Yes, it does also tangentially address those other points, but the primary reason it was adopted was to prevent spoofing of from headers (where in original spf that was a non-goal)

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

10 years is nothing. I'm sure there's still millions of companies globally who still aren't properly signing mail with DMARC.

No, you will never be contacting your bank over Instagram DMs or getting hotel confirmations via Facebook or dealing with governments over Youtube.

Nobody sends physical mail to each other anymore either, yet last mile delivery is as important as ever.

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.

Although there seems that there hasn't been any communication which is the bad thing here. However, nobody looks at those and sending detailed emails back seems like a good enough solution.

This stops disguising yourself as a legitimate service.

These days, hosting a proper mail server isn't really that hard, thanks to Stalwart https://stalw.art/. I did it to my Talos Linux cluster located on LA and utilizing idle resources. It is pretty great

  5.4.1 smtp; 550 5.4.1 Recipient address rejected: Access denied.
  For more information see https://aka.ms/…ors
  <redacted>.eurprd02.prod.outlook.com 2026-11-08T19:48:58.651Z <redacted>]

https://learn.microsoft.com/en-us/troubleshoot/exchange/emai...

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...

Email is, I think, among the most distributed popular online services, and there's a ton of stuff that's legacy, self-managed, or otherwise janky. Supporting SPF, DKIM, and DMARC does put a burden on independent operators, but is it an undue or unreasonable one in the current landscape? Or is it just the new cost of doing business?

That said checking for these things is a good idea, the only problem I see is dropping the mail on the floor, rather than rejecting it at SMTP time - at least that lets the self-hosting users who haven't got things configured know their email is being rejected, and to pick up the phone instead.

There's nothing worse than sending an email, it being accepted, and then later discarded with no clue to either sender or recipient.

Maybe 1 in 5 emails I get is spam, and because I use a different address with every sender I know who sold "my" address to a spam list.

Yes. In the first place, this should not even be a thing. Two corporations should not be in control of who can send e-mail. If they want to mark not having DMARC as spam, mark it as spam, or better yet flag it with a specific warning about the domain, but these games with refusing to deliver are just bullshit and essentially force a monopoly where other e-mail providers cannot compete because their e-mails aren't delivered.

We are literally talking about a situation where this is not happening! And the problem is that it's not just this. Once you give them a license to police e-mail, they start policing e-mail for all kinds of arbitrary and inscrutable reasons. If this were going to be done, it should really be formalized as an industry standard by an independent consortium, not up to the whims of Microsoogle.

DMARC, DKIM and the rest are industry standards set through an independent consortium (it's called the MAAWG iirc)

En contraire, I think not delivering mail is the fastest way to adoption. People will use an old system for as long as it works. It now does not anymore.

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

When I see in my logs that the e-mail has been successfully delivered to their MTA then I don't have a problem.

(If this happens to you, don't admit that you know Microsoft drops your emails, or you'll be liable again!)

I had an email server and configured everything by the book. Still some scammer were able to send emails which looked like they came from me, so i got responds back.

If not even this was fixed...

> The sender gets a bounce

?

It's quiet only if the server accepts it and then deletes it on their end without notifying the sender, but if your mail provider shreds your mail that's then also your provider's responsibility and not the sender's

I had a legal dispute once where a shop didn't provide warranty on a product. They took the product in but then it was indefinitely in repair. Long story short, it ended up being helpful that I have email server logs that show every transaction, so that I could say "on date+time the email was delivered to IP address X, which was registered as the mail exchanger for your domain, and your server took the email with status code XYZ Queued <ID> For Delivery." Would have been interesting to hear what a judge has to say about it but they simply agreed to give the full purchase price back after that

Afaik that's not what Microsoft/Hotmail does though: since it rejects noncompliant setups (as well as a lot of legitimate email, unfortunately), the sender gets a delivery failure notification

Sounds like kind of a hack:

"ARC was devised to solve this problem by giving intermediate servers a way to sign the original message's validation results. Even if the SPF and DKIM validation fail, the receiving service can choose to validate the ARC chain. If it indicates that the original message passed the SPF and DKIM checks, and the only modifications were made by intermediaries trusted by the receiving service, the receiving service may choose to accept the email."

maybe someone was too lazy to set up "inbound block list" and just did a total blackout instead?

Not true, at least in my experiences.

I have a bunch of email accounts which have SPF and DKIM, but are missing the DMARC line - I've had no deliverability problems at all, until this weekend, and now only with Outlook. Emails to Gmail accounts go through just fine.

The combination of: √ Valid SPF √ Valid DKIM signature X Missing DMARC policy

Is clearly ambiguous. Since a DMARC of "p=none" (in the context of valid SPF and DKIM) really adds no information, so interpreting "missing DMARC" as "p=none" seems reasonable. Sounds like Microsoft was taking that approach until this weekend.

I wonder if there's an actual written standard?

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/

Receiving is still self hosted.

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)

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

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.

Just not for this.

But this is not one of them.

This would be naive. It currently means that Microsoft censors and decides what you can see in the first place. I do not recall having given Microsoft such a permission. On the other hand I don't use Microsoft for email anyway (though, unfortunately, one local university here does, which is super-annoying. Europe is unable to think strategically here).

It's stupid, but not terribly difficult to set up and authorize.

Like most people who run their own mail, I have had repeated problems with Microsoft in particular, who treats small mail server operators like crap.

This post reminded me that I had gotten some email requesting me to "Re-attest Your Network Access". I went in, clicked a few things, and I'm good for another year or whatever.

https://substrate.office.com/ip-domain-management-snds/snds

https://www.litmus.com/blog/what-is-microsoft-snds-why-your-...

(dmarc only requires one of spf or dkim, not both, but it is a good idea to use both)

https://mastodon.social/@davisr/117570496362439342

When you talk about a single entity to single entity connection it can be any protocol. Email, Matrix, WhatsApp, SMS... Discord... Instagram. All of them work especially if you whitelist the other party.

What doesn't work any more is assuming that everyone is using the same thing. Back when email was invented it was the only computer-based communication protocol - I don't remember whether it came before or after USENET - I'm assuming before. If you wanted to send a message to someone you sent it to their email address. Now things aren't so clear.

Oh god the slop.

Only an LLM would describe DMARC as just "one DNS record".

It doesn't have to be just one record, but it doesn't have to be more than one record either.

Because i doubt that has worked at all in the last decade.

Yes, a proper email authentication stack has DMARC + SPF + DKIM. But each of these is a separate protocol.

This also doesn't take into consideration the other protocols that have arisen BIMI, APRF, MTA-STS / TLS-RPT and are at even lower levels of adoption.

BIMI is a pay-to-spam protocol that helps senders, you can add a rule to postfix to mark it as such.

APRF is a draft, and likewise helps senders, not receivers.. not sure why anyone would want to adopt this standard. A little closer to DMARC reports, but sharing PI that you owe no sending server.

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.

It's not months it's years.

I'm personally seeing this with some email systems I manage - email sent from a domain that has proper SPF and DKIM signatures, but had no DMARC record started bouncing this weekend.