Outlook.com Is Quietly Rejecting Email from Domains Without DMARC
mailroute.net
mailroute.net
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 haven’t productionized this setup (I send maybe a dozen emails a year) but it worked for me ad hoc a couple years back, when I had to send a mail to an Outlook-hosted address and they blackholed everything I tried to send while 250 OKing me.
It's always people self-hosting mail on a shared server in Moldova (because they think it makes them cool) that are complaining.
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.
I've never even had the key to mine. I've lived here over a decade.
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
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.
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.
The only question is how many years the lazy network-effects monopolies (like Google, Microsoft, Verizon, etc) will hold this back from happening.
The optimist in me says this will unlock pathways to true decentralization of push communication protocols (like SMTP) instead of only have decentralization of pull-oriented protocols (like HTTP).
Selfhosted email is likely easier now than it ever was before.
This is not Microsoft's fault. The building's on fire and they're locking out the arsonists.
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.
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.
Seems they are the disease not the cure
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.
These entities communicate via plain old mail, that costs more than 2 cents already.
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.
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.
You should be able to see this on your DMARC dashboard
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.
Fortunate for those running their own servers is that they actually still get all the cool emails from people not complying.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
Maybe you're right that just enforcing it is the way, but I don't agree with doing that with no heads up.
We have seen a massive erosion of the latter aspect of the web in the past few years, and I think it's useful to frame conversations in terms of that loss. The web used to be fun, and now it's become, more than ever, a professional enterprise. You often can't stand up a website without having to buy into Cloudflare's DDoS protection or something equivalent. I think this is absurd, and it's not the only such case, though these changes are obviously reactions to how usage of the web's evolved over the years.
I wonder if we can get the old web back in some way, shape, or form, cause I think we've lost something with the corporatization of the internet.
And for what it's worth, yeah, I think grandma should be able to run a mail server. Why not?
When I see in my logs that the e-mail has been successfully delivered to their MTA then I don't have a problem.
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.
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.
> 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
https://telekomhilft-telekom-de.translate.goog/conversations...
Just not for this.
I haven’t really seen BIMI for less than practically $1000/year and most clients still don’t check it.
But this is not one of them.
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.
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.
(dmarc only requires one of spf or dkim, not both, but it is a good idea to use both)
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.
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.
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.