MQTT is a publish-and-forget system by default: if you subscribe to a topic after the last message was sent, you wait, possibly a long time, for the next one. The retained message feature fixes that by telling the broker to hold onto the most recent value for a topic and hand it to anyone who subscribes later. This guide explains how the retain flag works, how it lets a newly connected or reconnecting client get the current value immediately, and how a retained message differs from a last will.
MQTT Retained Message in one line: A retained message is an MQTT message published with the retain flag set, which tells the broker to store it as the last known value for that topic. The broker keeps only the most recent retained message per topic and delivers it immediately to any client that subscribes afterward, so a new or reconnecting subscriber gets the current value without waiting for the next publish. Publishing a new retained message replaces the stored one, and publishing an empty retained message clears it.
When a publisher sends a message with the retain flag set, the broker does two things: it delivers the message to any current subscribers as usual, and it also stores that message as the retained message for the topic. From then on, the broker holds exactly one retained message per topic - the most recent one - and any client that subscribes to a matching topic receives that stored message right away, flagged so the client can tell it was retained rather than freshly published. The stored value persists on the broker until something replaces or clears it.
Only the latest retained message is kept; retain is a last-value cache, not a history or a queue. Each new retained publish on a topic overwrites the previous retained message, so the broker always holds the current value and nothing older. To remove a topic's retained message entirely, a publisher sends a retained message with an empty payload, which the broker treats as a signal to delete the stored value so future subscribers get nothing until a real value is published again.
It is worth noting that retain is a per-message decision. A publisher can send some messages retained and others not on the same topic, though for status-style topics it is common to always retain so the broker consistently holds the current state. Retain also interacts naturally with subscriptions: a subscriber that briefly disconnects and resubscribes will be given the retained value on reconnect, which is what makes the feature so useful for clients that come and go.
The practical benefit is immediate context on connect. Consider a topic carrying a tank level that changes only when the level moves - perhaps every several minutes. Without retain, a client that connects just after an update must wait for the next change before it learns the level at all, and until then its view of that tank is blank. With retain, the broker hands the client the last published level the instant it subscribes, so the client's display is populated straight away with the true current value rather than an empty field.
This matters most for values that update infrequently or irregularly. A pump run status might sit unchanged for hours; a valve position might change only when an operator acts. For all such state-like data, retain is what turns a subscribe into an instant snapshot of current reality instead of a wait for the next event. Fast-changing telemetry benefits less, because a new value is coming momentarily anyway, but even there retain guarantees a starting point rather than a gap.
For a cloud SCADA such as Merobix, this behavior is what makes a reconnect graceful. When the platform's connection to a broker drops and re-establishes - a routine event over cellular or satellite - retained messages let it repopulate the current tank levels, pressures, and equipment statuses immediately on resubscribe, rather than showing stale or empty tiles until each point happens to change and publish again. Publishing state topics as retained at the edge is therefore a small configuration choice with an outsized effect on how quickly an operator sees an accurate picture after any interruption.
Retained messages and last-will messages are easy to conflate because both involve the broker holding a message on a client's behalf, but they answer different questions. A retained message is about state: it is the last known value of a topic, kept so future subscribers can learn the current condition immediately. It is published deliberately whenever the value changes and reflects normal, healthy operation - the answer to what is this topic's value right now.
A last will and testament is about failure: it is a message a client registers when it connects, which the broker publishes only if that client disconnects ungracefully, such as when it drops off the network without a clean shutdown. The will's job is to announce that a client has gone away, so other systems learn of the failure. Where a retained message says here is the current value, a last will says this client just died - one describes state, the other describes an event, specifically an unexpected disconnection.
They are frequently used together, and a will can itself be marked retained. A common pattern for a remote device is to publish a retained status on a topic - online while it is healthy - and register a retained last will on the same topic that flips it to offline if the device drops out. Then the broker always holds a current, correct status for that device: online while it publishes normally, and offline the moment its ungraceful disconnect triggers the will. Retain provides the persistence of current state; the last will provides the automatic failure signal that keeps that state honest when a device vanishes.
Exactly one - the most recent. Retain is a last-value cache, not a history or queue, so each new retained publish overwrites the previous one and the broker always holds only the current value for that topic. To clear it, a publisher sends a retained message with an empty payload, which deletes the stored value.
A retained message is the last known value of a topic, kept so any new subscriber immediately learns the current state during normal operation. A last will is a message the broker publishes only when a client disconnects ungracefully, announcing that the client has failed. One describes current state; the other announces an unexpected disconnection, and they are often used together.
Without retain, a client that resubscribes must wait for the next publish before it learns a slow-changing value, leaving its view blank in the meantime. With retain, the broker hands over the stored last value the instant the client resubscribes, so it repopulates current tank levels, pressures, and statuses immediately. That makes reconnects after a dropped link graceful rather than leaving stale or empty displays.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.