Thanks for responding, really appreciated.

> made a prediction with high confidence

Do you somehow track the amount of false positives these predictions generate? How do you tune the prediction to not generate too many false positives?

> but in real life, you absolutely need to be proactive

Why is Microsoft the only provider who needs to do such proactive blocking? Why don't you need to do that for email addresses associated with Office 365?

> I think you should give me even more detailed feedback since there’s not much I can do except give a vague high level explanation unless you help me by being specific.

My story is very much the same as for everybody else having the same trouble, including the person whose blog post sparked this discussion: A root server for personal use located in the data center of a mid-sized hoster, running a mail server as part of its duties. In my case the whole mail setup runs on IP-addresses separate from everything else. Mail volume to Microsoft would probably be on average 1-2 emails per month. No issues whatsoever getting emails delivered to other mail providers, only to Microsoft. This whole setup is in place since several years.

The way you implement this, low-volume senders (nerdy individuals or small projects that can't use SES/Mailgun/… for GDPR reasons), even if they manage to get off the list once (olcsupport.office.com, escalate), never get the chance to build up reputation in the long term (I'd have to contact olcsupport again in a few months and that's just not sustainable for a small-time postmaster).

I get it, you're afraid that some VPS from a cheap cloud provider suddenly floods the inboxes of thousands of Outlook.com customers. I realize that a fresh IP that sends dozens of emails out of the blue has to be blacklisted.

But why don't you allow my VPS to send, say, 16 emails a day to Outlook.com inboxes? And if ⅛ of the recipients report junk, I get blacklisted. But if all 16 recipients are happy, my IP can now send 16+16=32 emails/day for the next few months (as long as the non-ISP hostname matches; otherwise, it might be a new VPS customer), and so on.

This way, your customers are happy (I don't think spammers rent/hack a fresh VPS in order to send 16 emails, and I don't think they are very good at building up IP reputation), and I'm happy (my personal VPS can send a few emails to my Outlook.com contacts every few weeks/months, and my project VPS can gradually build up and maintain the reputation it needs).

I'm obviously being naive about that approach, but I don't remember having trouble reaching Gmail inboxes or those of local providers, and at least for Gmail, I know that they have pretty effective spam filtering too, so I reckon that they use some approach like the one I described.

For a side project, I have just given up contacting olcsupport and instruct Postfix to send through our @outlook.com address instead, but that is a wobbly workaround at best. For personal email, I now relay through SMTP2GO because GDPR doesn't matter that much, but it makes me sad to have that gaping hole (called Outlook.com) in my decentralized email fantasy, after having spent so much time researching, configuring, diagnosing.