What Postfix status=sent actually proves.

“Postfix says sent” is often interpreted too broadly.

In a Postfix log, status=sent is a strong and useful event. It tells you that Postfix completed the configured delivery step and the next hop accepted the message according to the protocol being used.

That next hop may be an SMTP relay, an LMTP server or a local delivery transport. The exact meaning depends on the queue entry and transport. What the event does not prove is everything that may happen after that handoff.

A remote provider can accept a message and later filter it, quarantine it, route it internally, delay mailbox placement or apply policy that is invisible to your server. Turning “next hop accepted” into “recipient received it in the inbox” crosses an evidence boundary.

The hard part is usually joining the layers around one message.

An application can log that it submitted a message. Postfix can assign a queue ID. A content filter can record a Message-ID. A reinjection step can create a new queue ID with queued as. A relay response appears later under another part of the pipeline.

Looking at each log independently makes it easy to stop too early or accidentally combine two different messages that happened close together.

A stronger trace expands through identifiers: RFC Message-ID, Postfix queue IDs, explicit queue handoffs and application correlation IDs. When one event contains more than one identifier, it can bridge two layers of the same message path.

Timestamp proximity is useful context, but a dangerous correlation key.

Busy mail systems can process many similar messages in the same second. If two events are merged only because their timestamps are close and their recipients look similar, the resulting trace can become internally coherent and completely wrong.

Time is excellent for ordering already-correlated events. It is much weaker as the sole reason to decide that two log lines belong to the same message.

That is why identifier expansion is the safer default. Recipient addresses can help seed an investigation, but the graph should move through stronger identifiers once it has them.

Describe the last confirmed stage instead of inventing the missing one.

If the application logged a submission but there is no matching Postfix event, the evidence stops before Postfix. That does not prove Postfix failed.

If Postfix queued the message but there is no delivery result, the trace stops after queueing. If a filter accepted or transformed it and no later handoff is present, the trace stops there.

If Postfix records status=sent, the useful verdict is precise: the configured next hop accepted the message. Whether the recipient provider then placed it in the inbox is a different question and usually requires provider-side evidence.

A live queue snapshot proves existence at the time of capture.

Live queue inspection can answer another concrete question: was this queue item present when the snapshot was taken? That is valuable during a delayed or deferred delivery investigation.

It still needs the same discipline. A missing item in a later snapshot does not, by itself, reconstruct everything that happened between two observations. Queue state is another piece of evidence, not a substitute for the event chain.

The best mail diagnostic is conservative at exactly the point users want certainty.

It is tempting for a tool to print a single green “delivered” verdict. The problem is that the word can mean application submission, local queueing, relay acceptance or mailbox placement depending on who is reading it.

A better report names the confirmed stage and keeps the raw evidence available. That makes the result slightly less comforting, but much more useful when you are debugging a real incident.