By mq messaging, we mean what happens within message queues or message brokers, during the lifetime of a message.
“Message” in message queues refers to data or packets being transmitted from one part of your architecture to another.
Messages constitute what is being communicated. They are the data that your system understands and needs to function. 

When a message broker receives a message, it could first validate its schema.
This is depending on whether you’ve set any data validation.
Next, the message broker stores the message on the disk. Storing on disk also depends on whether the broker is persistent. If it is not persistent, it keeps the message in memory. 

Once the message has passed validation and storage, the next step is routing or messaging.
In this actual mq messaging process, the message queue sends the message to a direct consumer(s).
In a pub/sub message broker, the broker routes the messages to subscribers of the channels or topics to which the message was published. 

The messaging protocol of the sending service could be different from that of the recipient service.
If they are different, the message broker will use the sending protocol to open the message.
And when sending the message to its consumer, it will use the messaging protocol that the recipient understands.

If during this mq  messaging process, the consumer does not receive the messages (maybe because it was offline), and the messages exceed their time-to-live in the broker, the messages are said to be poison messages and are sent to a dead-letter system. 

Some message brokers require consumers to acknowledge the receipt of messages.
If a consumer receives a message and does not acknowledge it, that message will continuously be sent to the consumer.
If the message finally exceeds its time-to-live in the broker, it also becomes poison and is sent to the dead-letter queue.