deliverToMX hands its context to the MX lookup and the dial, but net/smtp takes no context, so nothing bounds the session once the connection is up. An MX that is slow to answer, whether to the greeting or anywhere later in the session, holds the delivery for as long as it takes. processReady waits for the whole batch before it starts the next one, so the rest of the queue is head-of-line blocked behind that delivery. The stuck entry is also back in the queue and due at once after a restart, so restarting the relay doesn't clear it either.
The connection now carries the context's deadline, and it is closed if the context ends first. A silent MX now costs one delivery timeout and a deferred retry instead of the whole queue.