SMTP Delivery Logs: Diagnose Why an Outbound Email Did Not Send

When one contact says they never received an outbound email, a dashboard total is not enough. Operators need a per-recipient history that answers: was the contact eligible, was a job created, did the worker attempt delivery, did the provider accept it, and did a later event change the outcome?

What the evidence supports

Measured evidence: the current analytics provider timed out after two bounded attempts. This article uses the approved provider-outage fallback, not a claim about current search demand. The brief scored 94 out of 100 for product alignment, gap, search evidence, source strength, and operator utility.

External evidence: Amazon SES documents event payloads for sends, deliveries, bounces, complaints, rejects, and delays. Gmail documents SMTP error classes. These sources help interpret provider events, but each provider has its own event names and timing.

Operational inference: an operator can make safe retry and suppression decisions only when every lifecycle transition is recorded against one recipient and one message attempt.

Use a single state history

State	Question answered	Safe operator action
Ineligible	Was the contact suppressed, opted out, missing consent, or outside the journey rule?	Do not enqueue. Correct data or honor suppression.
Scheduled	Was an eligible send time assigned?	Check journey window, timezone, and branch condition.
Queued	Did a job enter the sending queue?	Check queue age, rate policy, and worker availability.
Attempted	Did the worker call SMTP or the provider API?	Capture timestamp, connection, response, and idempotency key.
Accepted or delayed	Did the provider accept it, or return a temporary response?	Record message ID. Retry only delayed messages under policy.
Rejected, bounced, or complained	Did a permanent outcome arrive?	Suppress or investigate. Do not blindly resend.

Start with eligibility, not SMTP

Many “not sent” cases are correct behavior. Before checking infrastructure, confirm the contact was eligible for that exact journey step. Inspect suppression state, unsubscribe, prior bounce or complaint, workspace membership, branch condition, send window, frequency cap, and whether another worker already recorded a completed send.

This prevents a dangerous habit: treating a compliance or safety control as a delivery defect.

Required log fields

Store a durable event record for each attempt. At minimum capture workspace, journey, step, recipient identifier, sending identity, provider connection, scheduled time, attempt count, idempotency key, provider message ID, SMTP or API response, enhanced status code when available, event timestamp, and final disposition. Keep sensitive message content out of routine logs unless your retention and access policy explicitly permits it.

Read provider outcomes in order

An accepted SMTP response means the provider took responsibility for processing, not that the recipient inbox displayed the message. A delayed or 4xx outcome is generally a reason to retain the job and retry with controlled backoff. A 5xx outcome may be permanent, but the exact enhanced code and provider guidance matter. A later bounce or complaint changes the contact's future eligibility even if the initial send was accepted.

Amazon SES event publishing illustrates why the event timeline matters: send, delivery, reject, bounce, complaint, rendering failure, and delivery delay are distinct events. Do not collapse them into one Boolean called “sent.”

A safe diagnostic sequence

1. Find the recipient, journey step, and idempotency key.
2. Confirm eligibility and verify that a prior successful send did not already satisfy the step.
3. Read the newest state event, then walk backward to the first missing transition.
4. For queued work, inspect rate limit, backlog age, worker health, and planned send window.
5. For temporary provider failures, preserve the response and use the documented retry policy.
6. For permanent rejection, bounce, complaint, or unsubscribe, suppress before any manual resend.
7. For an unknown outcome after a timeout, query provider events by message ID before retrying.

Retry, pause, suppress, or escalate

Retry only a temporary, well-classified failure with a bounded backoff policy. Pause a journey when event ingestion, suppression processing, authentication, or provider health is uncertain. Suppress a recipient after unsubscribe, complaint, or applicable hard bounce. Escalate when an acceptance-to-delivery gap grows, a provider reports reputation pressure, or a pattern crosses workspaces.

Never respond to an unknown result by sending another copy immediately. The message may already have been accepted while the worker lost its connection.

Make the log operational

OutboundOS should keep this trace next to journey timing, branches, workspace isolation, and SMTP ownership. A log is useful only when it leads to a decision a human can explain: wait, retry later, correct the journey, suppress the contact, or investigate the sending infrastructure.

Sources

• Amazon SES event contents
• Amazon SES sending notifications
• Gmail SMTP errors