Thanks, that's what I expected. I'd like to implement it myself as a patch. Before I dig in, could you point me to the right place to hook this?
From what I've seen, queued_messages already has retry_after, locked_by/locked_at and ip_address_id, so my plan is:

at dequeue time, before a message is delivered, classify the destination by its MX host (not the recipient domain — so all Google Workspace / M365 domains collapse onto one bucket), then check a token-bucket keyed by (ip_address_id × MX-group);
if the rate/concurrency for that pair is exceeded, push retry_after forward and skip the message instead of delivering, reusing the existing requeue mechanism.

Two questions:

What's the cleanest place in the delivery path to intercept a message after it's dequeued but before the SMTP connection — the worker/sender code, or earlier in the queue processing?
Is there a hook or a supported extension point for this, or would it mean patching the sender directly (and carrying the patch across upgrades)?

I'd rather build it where you'd expect it to live, to keep it maintainable.

if I remember rightly, I think there are some checks after it gets dequeued so that might be the right place but if it doesn't have the extra information at that point, might be a bit tricky! I don't believe there is an extension point anywhere so it would have to be in the real code unfortunately and carried across to any future upgrades.

Thanks, that's really helpful. Confirms my plan: intercept after dequeue, do my own MX classification there since the FAI context isn't available at that point, and carry it as a patch across upgrades. I'll build it on top of retry_after. Appreciate you taking the time.