Outlook.com is rejecting email from domains without DMARC
https://mailroute.net/blog/outlook-rejecting-email-without-dmarcOutlook.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.
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.
Yes, no one should not have DKIM or DMARC but holy yikes when neither side wants to actually give in to help the customer.
This is not Microsoft's fault. The building's on fire and they're locking out the arsonists.
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.
Selfhosted email is likely easier now than it ever was before.
Even lazy spammers, who didn't even bother to create MX records for their fake, auto-generated domain, are getting into Gmail (Spam folder mostly, yet, why not reject it entirely?)
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.
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.
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.
[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.
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.
10 years is nothing. I'm sure there's still millions of companies globally who still aren't properly signing mail with DMARC.
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.
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
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.
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.
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>]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
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?
Receiving is still self hosted.
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)
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.
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?
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.
https://telekomhilft-telekom-de.translate.goog/conversations...
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).
I haven’t really seen BIMI for less than practically $1000/year and most clients still don’t check it.
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-...
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.
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.