An email platform can accept a message without delivering it. A recipient server can accept it without the person reading it. A temporary delay can later become a delivery, a bounce, or an unresolved operational issue. If your reporting collapses all of those outcomes into “sent,” you cannot tell what happened or decide what to do next.
A reliable email workflow treats delivery data as a sequence of events with different meanings. It keeps the original message request, records provider events as they arrive, derives a current status for each message and recipient, and sends the right signals back to the CRM, automation platform, suppression logic, and reporting layer.
Start with the identities, not the status label
Before defining statuses, decide what each event identifies. At minimum, keep separate identifiers for:
- Campaign or journey: the automation, newsletter, receipt, or notification that created the message.
- Message: the individual outbound message created for a recipient.
- Recipient record: the CRM, subscriber, constituent, or customer identity associated with the address.
- Provider message ID: the identifier returned by the email service.
- Event ID: the identifier for the delivery, bounce, complaint, or unsubscribe event.
An email address is useful for delivery, but it is a weak system-wide identity. People change addresses, household records can share an address, and one person may exist in more than one platform. Store the stable internal record ID alongside the address, and preserve the provider IDs needed to reconcile later events.
Model delivery as events and a current projection
Delivery systems are asynchronous. The send request may return before a delivery event arrives, and a retry may produce more than one notification for the same underlying condition. Keep an append-only event record, then derive the current status from the ordered, validated events.
| State or event | What it means | What it does not mean |
|---|---|---|
| Queued | Your system accepted the work and plans to send it. | The provider has accepted the message. |
| Accepted | The email provider accepted the request for processing. | The recipient server accepted the message. |
| Delivered | The receiving server reported acceptance of the message. | The recipient opened or read it. |
| Deferred | A temporary condition prevented delivery at that time, so another attempt may occur. | The address is permanently invalid. |
| Bounced | Delivery failed, usually because the destination rejected the message or retries were exhausted. | The person intentionally unsubscribed. |
| Complained | A recipient or mailbox provider reported the message as spam or unwanted. | The address should simply be retried. |
| Unsubscribed | The recipient withdrew permission for a category or channel of messages. | A delivery failure occurred. |
Provider terminology varies, so normalize external events into an internal vocabulary while keeping the original event type and payload. A deferred message should not be marked as permanently failed before the provider finishes its retry policy. A delivered message should not clear a prior unsubscribe or complaint signal. Those are different dimensions of the workflow.
Separate message outcome from recipient permission
One of the most common design mistakes is placing delivery and permission in the same field. They answer different questions:
- Message outcome: Was this particular message queued, accepted, delivered, deferred, or bounced?
- Recipient permission: May this recipient receive this category of marketing or operational message?
- Address health: Should this address be treated as invalid, risky, or temporarily unavailable?
- Relationship state: Is the CRM record active, merged, deleted, or otherwise restricted?
A recipient can be delivered one transactional message and still be unsubscribed from promotional messages. A hard bounce can make an address unsafe for future sends, while a temporary deferral may only require monitoring. A complaint may require a stronger stop rule than a soft bounce. Keep these decisions explicit so a later automation does not accidentally overwrite a more important restriction.
Use the event path to find failures
A practical data flow has several checkpoints:
- Your application creates a message record with the campaign, recipient ID, template, and an internal message key.
- The email provider accepts or rejects the send request. Store the provider message ID and the request outcome.
- The provider sends delivery events through webhooks, an export, or another supported mechanism. Verify the signature or authentication, validate the event schema, and record the raw event safely.
- A normalizer maps the external event to the internal vocabulary and attaches it to the correct message and recipient.
- A projection updates the current message outcome, address health, permission, and reporting dimensions.
- Downstream systems receive only the decision they need, such as suppress this address, retry this message, update the CRM, or include the delivery in a report.
This structure makes it possible to answer operational questions without guessing. Did the provider reject the request? Did it accept the request but defer delivery? Did the destination reject the address? Did the webhook arrive twice? Did the CRM update fail after the email platform had already recorded the event?
Failure patterns that make email reporting misleading
Counting accepted messages as delivered
An accepted request proves that the provider took responsibility for processing. It does not prove that the destination accepted the message. Report accepted and delivered as separate measures, and define which one a campaign dashboard uses.
Letting late events overwrite newer decisions
Webhooks can be delayed, duplicated, or delivered out of order. Store the provider timestamp, receive timestamp, event ID, and message ID. Apply a documented precedence and freshness rule rather than letting the last database write win.
Retrying without classifying the failure
Temporary deferrals, permanent bounces, complaints, and local validation errors need different paths. A generic retry loop can increase duplicate sends, prolong delivery to an invalid address, or ignore a recipient’s request to stop.
Using the email address as the only join key
Address matching can merge records incorrectly or fail after an address change. Use a stable internal ID where possible, and treat the address as an attribute that still needs normalization and validation.
Logging sensitive event data without a retention rule
Delivery payloads can include addresses, subject information, provider metadata, and diagnostic details. Keep enough information to reconcile and investigate, but define access, retention, redaction, and deletion rules. A log is part of the data workflow, not a free archive.
Validate the workflow before trusting the dashboard
Test the full path with controlled addresses and known outcomes. Your checklist should include:
- One message that is accepted by the provider and later reported as delivered.
- A temporary deferral that resolves without producing duplicate sends.
- A permanent bounce that updates address health and prevents the next eligible marketing send.
- A complaint or unsubscribe that reaches every relevant sending path.
- Duplicate and out-of-order webhook events.
- A provider event that arrives after the CRM update has failed.
- A missing or unknown provider message ID that goes to review instead of silently disappearing.
- Reconciliation between provider totals, internal message records, CRM state, and campaign reporting.
For promotional email, also validate the permission workflow at the message level. Gmail’s current sender guidance requires one-click unsubscribe for relevant bulk traffic, and RFC 8058 describes the header-based mechanism. A visible unsubscribe link in the message body is useful, but it is not a substitute for the protocol requirements described by the receiving ecosystem. Review the current guidance for the providers and jurisdictions that matter to your organization.
Build reporting around decisions
A useful report does more than show a delivery percentage. It helps someone decide what to do next. Show the counts for queued, accepted, delivered, deferred, bounced, complained, and unsubscribed messages, then add the context needed to interpret them: campaign, template, provider, audience, time window, address-health rule, and data freshness.
When a metric changes, the next question should be answerable from the same workflow: Is this a sending problem, a provider problem, an address-quality problem, a permission problem, a tracking problem, or a reporting delay?
Email delivery events are operational data. Model them with stable identities, preserve the event history, separate delivery from permission, classify failures, and reconcile the downstream systems. That approach gives marketing and operations teams a clearer picture of what happened and a safer way to respond.
If your CRM, email platform, and reports disagree about delivery or subscription status, DigitalWerks can review the event model, identifiers, webhook or export path, suppression logic, and reconciliation checks as one connected workflow.
Further reading: Gmail Email Sender Guidelines and RFC 8058, One-Click Unsubscribe.