Event Types Reference

Complete Event Type List

EmailElement-Side Events (IDs 1–4, 12)

These events originate from EmailElement's own processing before or instead of reaching the ESP.

Unknown

• No information is available about this event
• May occur during edge cases or system errors

Paused

• Email was paused on the EmailElement side
• Manual pauses: user clicks Pause on a Scheduled Email
• System pauses: triggered by error thresholds or volume cap limits
• The send can be resumed from the Scheduled Email page

Canceled

• Email was canceled on the EmailElement side
• Emails already Submitted or Sent are not affected
• Only emails still in the queue are canceled
• This action cannot be undone

Failed

• Email failed to send on the EmailElement side — it never reached the ESP
• The Message field contains the specific error
• Common causes: invalid API key, send integration misconfiguration, authentication failure
• Check the Send Integration status and run a connectivity test

Submitted

• Email was submitted to the ESP from EmailElement's system
• A successful Submitted event means EmailElement successfully communicated with the Send Integration
• If emails are Submitted but not Sent, the issue is on the ESP side

Suppressed

• Email was blocked because the recipient appears in a Suppression List
• The email will not be sent
• This is expected and healthy behavior — it means your suppression lists are working
• No action needed unless the contact should not be suppressed (remove them from the Suppression List)

ESP-Side Events

These events are reported back from the ESP after EmailElement submits the email.

Initiated

• ESP indicates the email was received and they are initiating the send
• This is the first ESP-side event in the email lifecycle
• High volume of Initiated events without corresponding Sent events may indicate an ESP processing delay

Retry

• ESP indicates the email will be reattempted
• Usually follows a temporary failure (soft bounce or rate limit)
• Retries happen on the ESP's backoff schedule
• If all retry attempts fail, the final event will be Error, SoftBounced, or HardBounced

Error

• ESP indicates the email was not sent
• Different from Failed (3) — Error means the ESP received the email but could not process it
• The Message field contains the ESP-specific error details
• Check the ESP's dashboard or status page for more information

Sent

• ESP indicates the email was sent to the recipient's mail server
• This does not guarantee inbox delivery (the email could still land in spam)
• The most common positive outcome for a healthy send

SoftBounced

• ESP indicates the email soft bounced — a temporary delivery failure
• Common causes: mailbox full (452), server temporarily unavailable (421), rate limiting
• The ESP may automatically retry soft bounces
• If a contact repeatedly soft bounces (3+ times), consider suppressing

HardBounced

• ESP indicates the email hard bounced — a permanent delivery failure
• Common causes: mailbox does not exist (550), domain does not exist (550 5.1.2)
• Hard-bounced addresses should be suppressed immediately to protect sender reputation
• Navigate to Suppression Lists to add hard-bounced addresses or configure Bounce Rules for automation

Complained

• ESP indicates the email recipient complained (marked as spam via feedback loop)
• This is a serious signal — the contact should be suppressed immediately
• High complaint rates can damage sender reputation and lead to IP/domain blocklisting
• Monitor complaint rates and review email content and targeting

Unsubscribed

• ESP indicates the email recipient unsubscribed
• The contact is automatically added to the brand-level suppression list
• No further emails will be sent to this contact for the associated brand

InternalRetry (14)

• EmailElement is internally retrying the send after a previous attempt failed
• Different from Retry (6) which is an ESP-side retry — InternalRetry is initiated by EmailElement itself
• The system will attempt to resend through the same or a different Send Integration