Troubleshooting Email Delivery to Microsoft Users

Not exactly on the same topic, but I think it's a good story. When my children were little we'd put them into summer camp. I would send an appointment with "something rather summer camp" from my @live account to my wife on her @hotmail account (you can tell the vintage of us by those, but anyhow). By then both of those were running on Exchange infra. I also had a b-dash@microsoft account at Microsoft which was was sure on Exchange, I wanted to block that time on that email. Well, I'd get these bizarre failures to deliver those calendar that were incomprehensible. I eventually tracked it to not liking "summer camp" in subject line. I changed it to "summer lamp" and they went through. !!! Because I was quite connected to Microsoft ecosystem, I was able to file this in proper raid/product studio repo and get it fixed (never sure of the exact reason though), but for years after that my children always went to "summer lamp" because it was funny that way.

As former email admin who has put up with this, you are breaking cardinal rule about mixing marketing and transactional emails.

Marketing should be different IP/Domain from transaction emails.

My email server is permanently flagged as spam in SNDS. No way to unblock it. I've tried everything. Its not sending any marketing or automated emails.

Microsoft just wants you to use O365 and happily blocks a lot of smaller email senders. Not even gmail is that strict. They've only greylisted my server for a few months and then unblocked it fully.

Plenty of advice here, which I'm certain is well intended, but it feels like we're victim blaming here.

Things like "you cannot mix marketing and transactional email" are good advice, but they do nothing if you're using different subdomains but the same infrastructure (IP address) to send them out.

Microsoft is simply trying to squeeze smaller operators out of the market.

I run an open source project, we send out transaction emails from ome subdomain, and a newsletter to 50K+ subscribers once every 3 months.

I can't afford to pay for different/dedicated IO addresses for each. We use Scaleway for email delivery and it's constant trouble with two providers: qq.com who don't give a damn about non-chinese senders, and Microsoft, who are simply trying to break the ipen internet.

Before, we were on AWS SES. Guess what, we didn't even bother using different subdomains. We also didn't have dedicated IPs. Yet Microsoft did not block us because the sender IP was AWS.

It's pay to play, as simple as that.

Fortunately, we're an open source project, not a business. So when people reach out, I simply explain to them that they have chosen a mail provider that is openly hostile to small volunteer-run projects like us and that that choice has consequences. No emails for you.

IMHO we need to be more vocal about what's really going on here (the rent-seeking on the open internet by big tech), and less victim blaming (what about dns-sec).

When it comes to email you have to be completely ... enthusiastic: "I was following all the best practices with SPF, SKIM, and DMARC."

DKIM. Obviously that was a typo on a forum but you cannot be complacent, ever.

You have missed out DNSSEC (nearly optional), SMTP-TLS and MTA-STS. Does your SPF record end with -all? Does your DMARC record have reporting addresses, does it have: "p=reject; sp=reject; adkim=s; aspf=s" in it?

I also suggest you send marketing emails from a sub domain or a separate domain or move your identity domain elsewhere. A cop out is getting someone else to send your stuff and I do not recommend that - it looks lax and trite.

I run a MS silver (its not Stirling and I'm not proud of it) partner. I recently shuffled our on prem to Exchange online, which at least saved a shit load of vRAM n vCPU on prem and horrendous Windows updates. I do insist on gatewaying all our SMTP via our on prem Exim n RSpamD n that. That means I get to decide where our mail goes and I also have a couple of Dovecots on prem.

I run rather a lot more mail systems than ours too. This works in the UK but I cannot comment on [elsewhere], for obvious reasons.

Been through this many times. Have no problems and then all of a sudden, servers get blocked, same misleading error message about it being temporary, same annoying auto response that "we cannot see anything wrong" and same opaque customer services that won't tell you anything.

They even have the cheek to link to a 15 year old guide on email best-practices, it is in equal parts awkward, annoying and incredibly shameful for a large organisation like MS. The fact that SNDS shows all greens seems to mean nothing and clearly they have been instructed not to engage in any conversation about why it is happening and the fact these are servers that are linked to a well-known business with static IPs that have been in use for over 3 years.

The best I can work out is the use of heuristic mail filters that detect anomolies for whatever reason they feel like. Too much email, not enough email, email sending rates that are too erratic, basically what 99.9% of email servers in the world are doing and they decide to block you. I could live with "rate limited" and I could live with "temporary" because I would disable the servers once they got blocked but nope. Just more "we don't give a shit" attitude from Microsoft.

Sadly, I had to accept the inevitable which I had avoided for many years and migrate all of our email sending to Amazon SES because life is too short to send emails to Microsoft.

There was a fairly active thread on the mailop mailing list about this, as you might expect given its userbase.

Annoyingly, mailop.org list archives are member-only (free to join however).

Mail Archive has the content, though I never much liked their UI. Link to the first message of the most interesting (IMO) thread, though there were others around the same time: https://www.mail-archive.com/mailop@mailop.org/msg26087.html

edited to add: this was a general MS issue and not necessarily senders having spam/dns/domain issues, which I suppose it why it annoyed mailops so greatly! and of course the long tail of the wider internet

I've seen issues last week onboarding a new employee, where emails from Jira and Slack and lastpass just weren't getting through.

crazy that they have such arbitrary ban while their mobile client doesn't even show the Sender email, but the self-disclosed name, that fits well to scammers needs.