This would be a useful feature. I have just transitioned a mail system to a PMG+365+(IMAP/POP/SMTP) and have encountered a speedbump with one external mail destination. That destination uses a mail security gateway which had a whitelist entry for the old mail system from ancient times before my time and from before anyone else with insitutional memory. Mail to that destination is being bounced. This is a slightly different use case from yours where you're on a blacklist and need to work to get off. But the feature solution in PMG I see as being the same.

PMG has a feature called "Transports" which is configured at Configuration > Mail Proxy > Transports. This feature operates on inbound email and can route email for a domain or user's address to a specific location. This is how I have setup the hybrid 365+traditional mail system. The 365 users are all individual Transports entries.

The feature that would solve your problem and mine would be "Outbound Transports" or the equivalent. It could be configured to operate on a specific sender email address (a user on a sending mail system on the "inside") or it can operate on a destination domain. Outbound mail traffic that meets the criteria would then be sent to the host, port, and transport protocol as configured.

For my use case, I would send mail from that particular user to the domain with the gateway to the old mail system's SMTP server for delivery while we get in touch with the other party and get their gateway updated. Our end user and their end users would then be able to continue with their work and not need to think about email problems.

For your use case, mail being sent to 365 could be put in an outbound Transport that delivers that email to a smarthost that you have setup outside PMG (or a second PMG on a different IP) or whatever solves your problem temporarily while you work out the blacklist issue. Again, your end users don't have to think about email problems while you work on a solution.

I experienced a problem with the connector from PMG to 365 where internal emails were being semi-greylisted. The email address lists are handled in the traditional half of the hybrid setup, so foo@example.com is sent to the IMAP/POP where it is split into separate envelopes for jack@example.com and jill@example.com which are then delivered locally, and romeo@example.com and juliet@example.com which are then sent back to PMG and then delivered to 365. Some lists have three or more 365 users on the list.

If there are three or more 365 users on the list, two of the 365 users will be delivered by 365 and one or however many more than two will be temporarily rejected (like greylist) and then queued on PMG. PMG then retries later, and the list is slowly delivered in pairs. No email was lost, but this made things very slow. I contacted Microsoft support and they added some kind of additional whitelist entry in the back end for the PMG IP address. From then on, everything was smooth sailing.

However, I never experienced getting blocked by MS. There was one single block on Yahoo and a single block on Google for test emails someone sent. I then taught people to send to a mailinator account we setup for testing. This allows test emails for whatever, but doesn't endanger sending irregular emails to a big provider and risking an adjustment to the score for our IP.

BTW: before working on the production domain for my customer, I setup a scale model with every piece: OpenSMTPD server, Dovecot+OpenSMTPD, 365 w/ connectors, and PMG on PVE and a test domain that the customer owned. I worked out all the issues before making the main transition there. One tool that I found helpful was:
https://www.mail-tester.com/

You can send three test emails to it for free per day. This and using mailinator for testing was crucial. The test system had a perfect score for sent emails on mail-tester.com. The only issues I then encountered were the strange 365 semi-greylisting and the old whitelists on external mail systems and the handful of mistaken test emails.

BTW: reading the problem listed at that answers.microsoft.com page:
"Please contact your Internet service provider since part of their network is on our block list"

Your IP may be on a bad neighborhood blacklist. I can think of two reasons for this off the top of my head:

1. Microsoft has their own bad neighborhood blacklist. In this case you can only talk to them about it to get it fixed.
2. Your IP is listed on either or both of UCEPROTECTL2 and UCEPROTECTL3.

This second case can be checked using https://mxtoolbox.com/ just plug in your IP and then navigate from the results to the blacklist check. You can also see if they have you listed directly using their own tool: https://www.uceprotect.net/en/rblcheck.php

If the IP range is listed in UCEPROTECTL2 or the ASN is listed in UCEPROTECTL3, they operate an extortion / mafia protection racket here:
https://www.whitelisted.org/

You plug the IP in that and they give you a price to have your IP whitelisted. The whole process feels smarmy, and please don't take anything I have said as a recommendation to do what they want or to pay them for anything. I'm just pointing out that this can be the source of a blacklist problem depending on whether the destination mail server uses UCEPROTECT in their filtration.

That was actually very helpful info, thanks a lot. Seems the network to which our new IP belongs to was indeed on UCEPROTECTL2. Moving the gateway to another completely unlisted IP now shows successful direct delivery (without smarthost) also to outlook.com.

I still wish there would be better options for directing outgoing mails via selective smarthosts. For instance with our mail server we could also have different smarthosts for different domains: domain1.com to smarthost1, domain2.com to smartahost2, etc (and all with proper SMTP authorization).

This would be a useful feature. I have just transitioned a mail system to a PMG+365+(IMAP/POP/SMTP) and have encountered a speedbump with one external mail destination.

Are there any news from the proxmox team.
1) Outgoing smart host WITH authentication to the provider smart host.
2) Outgoging smarts hosts depending on destination domain (also with authentication)

I got nowhere trying to set the mapping with main.cf.in.

One post I found made reference to just setting up another transport. That works for specific domains when transport defined configuration/mail proxy/relaying/smarthost is used as primary. Similar to the OP, I want it to send directly first, to specified relays for defined sender/recipient domains and using another relay when either of the first fail or result in rejected/bounced.

bump, i have exactly the same issue. routing mails to different mx hosts depending on recipient domain (aka outbound transport in PMG language) is something which other products were able to do for decades.

i'd really like to see this in PMG.

+1 Outbound conditional relay (with authentication) would be something I’d be interested too. Ideally based on sender or recipient domain.

would also like to get an update on this pls

PMG team please add this outgoing email smart host selection.

Good luck. I gave up waiting. None of the maintainers of Proxmox have replied to this thread. I think the feature is probably not one that they will consider.

It is a shape how the proxmox team is ignoring this feature request for a standard feature for years now.