You'd need a socketmap-based transport(5) table, with the daemon
serving the socket doing the MX lookups and deciding what to do.
If the MX lookup temp-fails, you'd need to return "retry:4.1.2 MX
resolution failed" as the transport. (You could also use "tcp"
tables, but the "socketmap" protocol is somewhat better).
Transport lookup needs to be low-latency, so the daemon needs to
be capable of processing many requests in parallel, and needs to
consolidate multiple requests for the same domain while the answer
is still pending).
Unfortunately, transport(5) lookups in qmgr(8) are single-threaded,
so you're going to see a significant throughput penalty for doing
this. Your queue manager may stall for multiple seconds delivering
no mail. This is only suitable for low-volume senders.
To support this properly the Postfix queue manager would need to
be redesigned to load messages into the active queue in parallel,
with multiple front-end servers reading queue files and doing
transport queries, and only delegating work to "the one" qmgr that
only does scheduling and does not block doing file I/O or transport
lookups.
Such a re-design would be a major undertaking.
Another approach would be a content filter or pre-queue proxy filter
that rewrites addresses whose domains have the special MX hosts.
Because there can be many parallel proxy or content filters, the
latency cost of lookups for slow domains will be ammortized across
a wide pool of concurrent processes.
The rewritten addresses would then be forwarded to a second Postfix
instance and returned to their original form in the process. The
second instance would do MX-based routing and bypass the relayhost.
--
Viktor.