The SMTP protocol and the message contents are essentially the same for MUA-to-MTA and MTA-to-MTA. An MTA may add missing or extra headers and will append a Received
header at the beginning of the headers, making it possible to trace the delivery path. Also, MUA-to-MTA connections may be authenticated and use a separate submission port with separate settings.
An incoming message is usually accepted immediately and then queued at the MTA. Most MUAs will show an error if the delivery fails because the server couldn't be reached. The workload is related to the queue. If there's plenty of mail to deliver, it's not possible to deliver it all at the same time. There might also be temporary problems with reaching the destination MTA, or temporary problems why it can't accept the message, like rate limits.
If the MTA gets an error that is temporary in nature, it will try the delivery later with increasing intervals, and the mail stays in the queue for the maximum queue period defined. After that, it will be considered as a permanent error and the mail will bounce back. The MTA might also give additional notifications on the delivery status.
The queue is an internal structure that handles a basic requirement in the SMTP model: as defined in RFC 5321, 2.1, a single MTA has the full responsibility for delivering the message at a time, until the next MTA accepts this responsibility:
Message transfer can occur in a single connection
between the original SMTP-sender and the final SMTP-recipient, or can
occur in a series of hops through intermediary systems. In either
case, once the server has issued a success response at the end of the
mail data, a formal handoff of responsibility for the message occurs:
the protocol requires that a server MUST accept responsibility for
either delivering the message or properly reporting the failure to do
so.