Outlook.com is also rejecting mail based on blocklists that are not public and you essentialy cannot get yourself out. My VPS provider is pretty much entirely blocked and their regular blocklist process says we are golden so nothing to unblock.
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.
outlook.com and O365 are horrible to deliver to. We regularly get issues where we sent an email it was accepted by O365 but was never delivered to the mailbox. We have one person working at least half the time on resolving stuff like that. And that's from a respectably maintained SES egress with good reputation, DMARC, DKIM configured.
> Outlook.com and similar are an anathema to email. This is why they tell you not to run a mail server .
It turns out that whoever has the most power is the most powerful. This is why distributed/decentralized systems cannot singlehandedly free us from tyranny, and why I find people who spend all their time preaching decentralized systems to be quite silly. We don't need better systems (well maybe we do but,,,), we need better education and awareness of how billionaires manipulate us; this goes beyond software.
Because the protocol is flawed at its foundation - there is no good way to make sure that the person sending you something is a person and sending content you'd want to interact with. If the big providers weren't doing this stuff, we'd whine about the enormous amount of spam.
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.
That may be so, but you can't control what mail service your recipients use. So whether or not it's a bad idea, it can be your problem. That said I don't agree with OP that self-hosting mail is a bad idea.
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.
It's not enough. I have a domain that I had a very long time but it is on an undesirable tld. I got it long before it was problematic. Outlook always puts my mail in the SPAM folder even though I have done everything I could. I even deliver through a trusted provider. Not on any spam list. DMARC, DKIM, SPF all set up. No dice.
I was viciously mean in my communication with the Outlook team when they said they “couldn’t” remove me from the blocklist. I pointed out that, as the operator of a perfectly compliant secure server their inability to deliver my mail is a technical failure on their end and one which I will be contacting their supervisor about and they somehow managed to scrabble together the heroic ability to delete my row from a table. Never back down from these bastards.
"Lazy people"? I only heard about this because a customer complained. Am I supposed to go around the Internet, checking what each mail server will allow or deny?
This seems overly dismissive especially for individuals who send emails from custom domains at low volumes. DMARC has previously been seen to only be really needed for high-volume senders. The mail testing service linked still gives 10/10 for emails received without DMARC (but with SPF and DKIK). My email is setup via Fastmail and I followed all the recommendations they provided (which didn’t include DMARC)
I just tried this out now with an email from my personal domain that I have configured to send via my gmail account. I got a 10/10, but DMARC does not seem to be required for this. It shows a yellow checkbox for me on this, the same as it shows for me not having an unsubscribe button, which hardly gives the impression of it being necessary, given that I would not expect an unsubscribe button to make sense for most people manually sending emails to their customers from corporate email accounts.
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.
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 to spam or be null-routed. And the DMARC noise started even before that.
Gmail only requires DMARC for senders that send >5000 emails per day. Below that it's not required. That rule only appeared in 2024 so I wouldn't say it's been required for a very long time. Perhaps you're thinking of DKIM, which is different.
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.
It is literally one of the last free and open channels on the Internet – I suggest you work on supporting its use and keeping it that way rather than moving to something controlled for profit or data harvesting.
It being free and open is exactly what the big providers can't stand and why they are coming up with ever more "standards" that are complex to configure as well as "reputation" scores that are hard for small senders to clear.
Also why they do non-standard stuff like accepting mail but then simply not delivering it, rather than bouncing it.
Calling it a "free and open channel" when 80% of consumers are on Microsoft/Google addresses that control who can deliver e-mail is laughable. It's dead, Jim.
Strengthen your contracts / terms of service. Make it their responsibility to configure their email systems properly so they receive emails sent from your domains.
If reliable means the message gets through no matter what, then it's good that no channel is reliable. Such a channel will inevitably be used for spam and attention grabbing.
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.
DMARC is a DNS record that says "send emails about spoofed messages here", or optionally "I don't need you to tell me that scammers exist on the internet".
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.
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.
And what should a provider do if the dmarc policy says that none of the dkim or dmarc records should matter? What was the point of spf saying what servers could send, or dkim specifying signing keys?
"Oh, please, don't ignore the other two ways I told you to ignore unauthorized messages" shouldn't need a knob.
I have MCP servers for the creation of domains, DNS records with DNSSEC, and email accounts with SPF, DKIM and DMARC. I'm sure if someone wants to be a professional spammer today, DMARC is not a differentiator.
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.
What? How does it prove it's a differentiator for someone who wants to be a spammer, which is what the comment you replied to made a claim about? As far as I can tell, it's evidence (not proof) that Microsoft thinks that they will reduce spam by requiring it, which in turn is circumstantial evidence (definitely not proof) that spammers might have to spend some amount of effort to start using DMARC. I don't understand how you can conclude that it would be onerous for them to do so indefinitely; it seems equally plausible that they might have just not bothered to do it before now but will be able to start doing it without much cost.
Tangentially-related: Gmail has started sending completely legitimate emails to spam. DMARC/SPF/DKIM (2048 bits) all properly configured of course so there has to be something else that isn't documented.
This was my second hackernews submit [0]! So, not even https in 2014 :)
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.
You adopted it the moment it was announced? Really?
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.
This is interesting. At some point, I think it'll be desirable to give increasing positive weight to emails with the DPF/DKIM/DMARC trifecta configured, since those are least likely to be problem emails (spam or phishing), but I wonder what the best avenue is to actually make that the default. It's almost certainly not this kind of unannounced cutoff.
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?
It seems like 90% of the spam I receive (on my google account) is sent from google addresses, so it will have valid SPF/DKIM/DMARC setup.
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.
> but is it an undue or unreasonable one in the current landscape
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.
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).
> You get a clean error message that tells you exactly what to do
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.
Most spam I get is from Google, Microsoft and Amazon. We should pressure those to start dealing with the problem. Right now they are conveniently ignoring it.
> I wonder what the best avenue is to actually make that the default. It's almost certainly not this kind of unannounced cutoff.
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.
I thought they've been doing this for years, along with gmail/etc. I basically just added setting up the correct DNS records as part of business when sending emails externally.
I have the opposite problem. I have a 3-letter email address, so for ease of giving out the email address, I use it, while having it forwarded to my Gmail. Somewhere around 2019, emails from legitimate services, especially password reset/OTP codes, stopped landing in my inbox or even junk because my address is so high up the chain of spammers. Nebula was the first to confirm this for me and work out of band to re-enable access to my account - their emails to me were bouncing. But ever since that happened, I’ve slowly moved back to giving my Gmail.
"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."
I actually totally agree with this. There's too much risk involved with scams disguised as legitimate services because the developers of said service couldn't be bothered to add 1 or 2 dns records.
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.
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.
I don't know what "v=DMARC1; p=none;" is proving to anyone when DKIM and SPF are already aligned but sure whatever. Just wish they'd given some warning!
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.
This has been going on for much longer than stated here - we had domain mismatch issues with outlook going back years and our policy was p=none. They’re very sensitive and mailing lists with forwarding are heavily impacted.
My first thought as well: how does one quietly reject email? Skimmed the comments and clearly it's not quietly. Saved a click...
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
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
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’ve been anticipating something like this for a while; the number of folks who don’t have their email-related DNS settings in order is remarkably high.
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 was hit by this twenty minutes ago. I don't disagree with the policy, but I wish my provider had warned me so I could add the headers. I already had DKIM and SPF, but not DMARC.
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.
It's possibly yet another issue relating to the long streak of problems seen the recent months by primarily self-hosters trying to reach people and businesses behind Outlook servers. The past few weeks a lot of my e-mails to friends and family using Hotmail have gone missing. All envelopes were OKd by Outlook servers, nothing bounced, e-mails just gone. My setup is clean, my network is clean.
I'm fine with providers imposing some default level of spam protection but as a user I'd like the option to disable it, even better if I can disable it per domain or sender. The old technique of adding the sender to your contacts doesn't work reliably anymore.
"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.
"Since November 5, 2026, Microsoft's consumer mail service has been turning away some of the email from domains that don't publish a DMARC record. If your company emails customers, vendors or applicants with outlook.com, hotmail.com, live.com or msn.com addresses, some of that mail may be bouncing right now. Nobody announced it. The fix is one DNS record."
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.
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.
It turns out that whoever has the most power is the most powerful. This is why distributed/decentralized systems cannot singlehandedly free us from tyranny, and why I find people who spend all their time preaching decentralized systems to be quite silly. We don't need better systems (well maybe we do but,,,), we need better education and awareness of how billionaires manipulate us; this goes beyond software.
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.
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
Also why they do non-standard stuff like accepting mail but then simply not delivering it, rather than bouncing it.
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.
"Oh, please, don't ignore the other two ways I told you to ignore unauthorized messages" shouldn't need a knob.
gmail runs with p=none
so tell me what benefits that has over having no dmarc record at all ?
https://ciphercue.com/blog/dmarc-enforcement-gap-rua-fragmen...
https://news.ycombinator.com/item?id=49081783
I have MCP servers for the creation of domains, DNS records with DNSSEC, and email accounts with SPF, DKIM and DMARC. I'm sure if someone wants to be a professional spammer today, DMARC is not a differentiator.
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.
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.
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.
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.
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?
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.
Allowing basically ~whatever, but proving the sender address is an obviously good approach to me.
I haven’t really seen BIMI for less than practically $1000/year and most clients still don’t check it.
> 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
Just not for this.
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?
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
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".
https://mastodon.social/@davisr/117570496362439342
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.