Read the delivery evidence for a message

Every message the platform sends has a row, and the row carries what happened rather than what was attempted.

What this does

Gives you one place to answer the question a client asks as a statement: I never got that.

How to read it

Open the record the message was sent from, then Outbound.
Each row shows the recipient, the time, and one state: queued, sent, failed or bounced.
Open a row for the detail, which includes what the receiving server said, in its own words.

What proves it worked

A row in a terminal state, with the response that put it there. Sent means a receiving server accepted it. Bounced means one rejected it and told us why. Failed means we could not hand it over at all.

Queued is not a terminal state. A row still queued an hour later is a problem, and it shows as a problem rather than resolving itself into a green tick.

Acceptance is not delivery

A server accepting a message means it took responsibility for it. It does not mean a person saw it, and no sending system on earth can tell you that from the send side alone. So the ledger records what it can actually observe and labels it precisely, rather than showing a delivered badge that means accepted.

This is why the platform also checks placement where it can, and why a message recorded as sent with an unchecked placement says so instead of implying more.

When a message is missing entirely

If there is no row at all, the send did not happen. Check whether the action that should have triggered it completed, and check the gate band on that action. A blocked action does not send, and it says on screen what is blocking it.