
Any email service could be configured to block Microsoft.
Indeed, whoever controls the server could do that. But who does? I don’t have an always-on WAN-facing machine, so I am interested in finding an email provider who does the blocking because as an end user I don’t have the privs.
I’m not sure why you want to do that at the platform level though. That’s a great way to not have delivered legitimate email traffic.
Microsoft is a surveillance advertiser who I boycott. I do not want to feed MS’s ad machine. For outbound mail, I can do an MX lookup first and only send email to non-MS non-Google recipients, but that’s not reliable because some recipients mask their email providers using a firewall like barracuda networks. So when such users try to email me, I would like their email to be refused.
About blocking “legit” traffic, MS does that anyway. I’ve seen MS reject RFC-compliant non-spam email 1st hand. I am happy to reciprocate.






Filters are for email post-delivery. By the time a server is executing your filter instructions, Microsoft’s server has already delivered the message and disconnected. It’s too late at that point. If some rare mail service were to bounce a message based on user-specified filters, it would have to be after the msg has already been delivered. This would risk “backscatter”, whereby the bounced response attempts to connect to the /perceived/ sending server, which could be incorrect. And even if it is correct, the sending server may not accept the bounced msg.
The configuration I describe can only competently be done on the server and it necessarily must be the same behavior for all users on that server because the refusal happens before the sending server even has a chance to send an SMTP “RCPT TO” line.
It would be senders who lose access. I’m already happy to not connect to surveillance advertisers. The idea is that users on surveillance ad platforms lose access so they cannot deliver to my inbox.