Email statuses

Every email has one status that shows where it is in its lifecycle. This page lists all 14 statuses, how an email moves between them, and what to do when an email stops somewhere you didn’t expect. The status is the latest state only; the full history is on the email’s detail page and in events.

Status reference

“Final” means Emailit won’t change the status on its own any more. A final email can still be retried, which creates a new email with a new ID.

Webhooks receive email.canceled and email.held when they’re subscribed to all events, or when you add them to the webhook’s event list with the API. See Event types.

Lifecycle

Most emails move along this path:

1. Created. An API send creates the email as accepted, or scheduled when scheduled_at is in the future. SMTP sends start as accepted too. Inbound mail is created as received and never changes.
2. Checked. Before each delivery attempt, Emailit checks the workspace, domain, API key, credits, suppression list and spam score. A failed check ends the email as held, rejected or suppressed without sending it.
3. Delivered or deferred. The delivery attempt either succeeds (delivered), fails temporarily (attempted, then retried), or fails permanently (bounced).
4. Engagement. If tracking is on, opens and clicks move a delivered email to loaded and then clicked.
5. Late reports. A bounce report that arrives after delivery changes the status to bounced. A spam complaint changes it to complained.

At any point before delivery, a scheduled, accepted or attempted email can be canceled.

The engagement ladder

Delivery and engagement statuses only move forward:

accepted, scheduled or attempted → delivered → loaded → clicked

A later event never moves an email back down the ladder. If a click is recorded, the email stays clicked even when more opens arrive. An open or click can skip ahead of delivered, because it proves the message arrived. Statuses that end delivery (bounced, failed, rejected, suppressed, complained and canceled) are never overwritten by opens or clicks.

Retry schedule for attempted

When a receiving server answers with a temporary error (a 4xx reply such as 421 or 451, a timeout or a connection error), the email becomes attempted and Emailit tries again. Each wait is twice as long as the previous one:

That’s 7 delivery attempts over about 21 hours. When they run out, the email is marked bounced with “Maximum number of delivery attempts (7) has been reached”, and the recipient is added to suppressions with the reason too many soft fails, unless your automatic suppression settings exclude bounces.

Each attempt is listed on the email’s Deliveries tab with the server’s reply, and each one sends an email.attempted event that includes smtp_code, smtp_enhanced_code and smtp_response. Some temporary replies that clearly mean a permanent problem, such as a disabled mailbox, are treated as bounces straight away. When a provider is throttling, Emailit can also pause delivery to it briefly; those rows say “Delivery delayed due to…”.

Why an email is held

A held email was taken out of the send queue without being sent. The Deliveries tab on the email shows which reason applied:

Held emails aren’t released automatically. After fixing the cause, select Retry on the email, or call Retry an email. Retrying creates a new email with the same content and charges credits again.

Why an email is rejected

Until your workspace has production access, you can only send to workspace members’ account emails. The API returns 403 and SMTP returns 550 for other recipients at send time, so most of the time you see the error instead of an email. The rejected status appears when the same check fails later, at delivery time, for example for an email that was scheduled earlier. The Deliveries tab shows “Unverified workspaces can only send to workspace members’ account emails” and the blocked address.

Retry rules

For a suppressed email, remove the address from your suppression list first, otherwise the retry is suppressed again.

Related