MQTT clients (e.g. devices) are connected over TCP/IP sockets, which has buffers and queues in the IP stack of the server to ensure the broker receives all the messages that are published to it. That’s the “promise” of TCP. The order of arrival of messages published by separate clients is not defined (messages can take different routes and potentially do TCP-level retries before they arrive at the broker machine).
There are three “qualities of service” that define how hard the client and broker try to successfully transfer messages between themselves. QoS 1 and 2 have built-in protocol-level acknowledgments which enable both ends to know that the message has been received. MQTT uses a time-out (coupled with watching for socket disconnections) to decide whether to re-try a publication.
MQTT v5 (the new one!) *does* have NAKs which can be used to tell a publisher why a message was rejected by the receiver (client or broker).