Understand message delivery states

Message states in the conversation

The exact path can vary by channel and provider. A message may remain Sent when no later receipt event is available. Lack of Read does not prove the customer ignored it.

Additional email events

Email message details can expose provider events beyond the compact conversation state:

Received

Inbound email was received by the connected path

Sent

Provider accepted outbound email

Delivered

Receiving system accepted the message

Delayed

Provider reports temporary delivery delay; monitor for a later Delivered or terminal event

Bounced

Receiving system rejected the message; verify address and reason before another send

Complaint

Recipient/provider reported a spam complaint; stop and review consent/suppression policy

Opened

Tracking indicates an open where available; privacy controls and client behavior can affect it

Clicked

Tracking indicates a link click where available

Failed

Provider or connection could not complete the send

Unknown

Event was received but not mapped to a more specific supported type

Opened and Clicked are engagement evidence, not proof of understanding, identity, or acceptance.

Conversation state is separate

If a final customer reply failed, reopening or creating a recovery action may be necessary even though the conversation was closed.

Interpret common combinations

• Sending for a few moments: normal processing may still be underway. Refresh before acting.
• Sent, no Delivered: provider accepted the message; wait for available receipt evidence or inspect provider status if the customer commitment is time-sensitive.
• Delivered, no Read: delivery is confirmed; do not repeatedly resend merely to produce a read signal.
• Email Delayed: avoid duplicate send; monitor for later delivery or bounce.
• Bounced: verify recipient address and bounce reason, then correct the record before another approved attempt.
• Complaint: suppress further promotional or inappropriate contact according to policy and escalate consent review.
• Failed with inbound still working: outbound sender, message type, recipient, or provider authorization may be the narrower failure boundary.
• Read but customer disputes receipt: preserve the event, verify recipient identity and content, and resolve through human communication; do not treat the status as irrefutable proof.

Decide whether to retry

Retry only when:

1. the previous attempt is terminal Failed or otherwise confirmed not to have delivered;
2. the cause is understood and corrected;
3. the recipient, consent, sender, and content remain valid; and
4. another message will not create duplicate customer or commercial consequences.

For Delayed, Sending, or ambiguous provider evidence, wait or investigate before retrying.

Open full size

Evidence for escalation

Capture workspace slug, conversation ID or safe URL reference, message timestamp/timezone, connected sender, visible message status, and the exact provider event or error. Use a tightly cropped redacted screenshot. Never send full message exports, passwords, SMTP secrets, OAuth tokens, or unrelated customer content.

Measurable delivery health

Track the rate and age of Failed/Delayed messages, failure reason distribution, duplicate retries, and time to restore send readiness. Avoid measuring success by Sent count alone.