What to do when order and booking emails bounce

A send request is not delivery

An order platform may show an email as sent because its provider accepted the API request. That state does not prove the recipient's mail server accepted it, still less that the customer read it. Amazon SES documentation distinguishes send, delivery, delivery delay, bounce and complaint events. Use the event types your own provider actually exposes, and keep the provider's message identifier linked to the order or booking record. A customer service agent should be able to see a concise delivery state without having to search raw mail logs. The business event itself must remain valid even when the notification fails: an order does not disappear because its receipt bounced, and a booking cannot rely on an email as its only record.

Classify the failure before taking action. SES describes a hard bounce as persistent, such as a nonexistent mailbox, and a soft bounce as temporary, such as a full mailbox or transient connection problem. SES retries soft bounces itself and reports them when it stops retrying; do not start an independent loop that sends the same message repeatedly just because your application has not yet seen a delivery event. A complaint is a different signal that a recipient marked a message as unwanted. A delivery delay is not a final failure. The exact event names and retry policy vary by provider, so the workflow should map provider events to business states explicitly rather than guessing from a single status field.

Build an event history that is append-only at the business level: requested, accepted by provider, delayed, delivered, bounced, complained or suppressed, with occurrence time and a safe reference to the provider event. Events can arrive later than the checkout page response, so the interface should not imply final delivery immediately. Deduplicate repeated provider notifications by event identity before changing the current state, and preserve the underlying history for investigation. If the recipient address changes, treat that as a new contact decision tied to the same order, not a rewrite of the earlier failed attempt. Avoid putting order contents, authentication links or full customer data into general-purpose logs. This makes a failed notification auditable without creating another data leak.

Respond by consequence and cause

For a permanent bounce on an essential order confirmation, stop automatic sends to that address and flag the order for a customer contact route that the business already verifies. An account page can show the order reference and status after the customer signs in; staff may use an existing verified phone channel where appropriate. Do not expose order details to someone who merely supplies an email address over a call. Ask the customer to correct the address through an authenticated account flow or another established identity check, then send only the necessary replacement notice. The goal is to restore access to essential information without turning a typo into either an endless retry loop or an opportunity for impersonation.

For a temporary delay, keep the customer-facing business state separate from mail state. If the booking is confirmed, show confirmation inside the product and explain that the email is delayed, while monitoring the provider's final event. Decide locally when an unresolved notification becomes a staff task; the threshold should reflect the time sensitivity of the message and the provider's retry behaviour, not an invented universal number. A same-day appointment reminder needs faster attention than a routine monthly statement. If the provider eventually reports a bounce, move to the verified-contact route. If it delivers, close the task with the actual event and time rather than a manual guess.

Consider a worked case: a customer completes a booking and mistypes one letter in the email address. The booking service stores the reservation and shows its reference on screen. The provider accepts the message, then reports a hard bounce. The workflow links that event to the reservation, blocks another automatic send to the same bad address, and places a contact task in the booking team's queue. The customer later signs in, corrects the address and requests a fresh confirmation. Staff can see both the failed original attempt and the new delivery result. This is a proposed process, not a claim that any specific business has measured such outcomes; its value lies in preserving the booking while making the notification recoverable.

Own the suppression decision

SES offers an account-level suppression list that can automatically record hard bounces and complaints when configured. It is scoped to the AWS account in a Region, and the settings can vary by configuration set or tenant. Do not assume that a global suppression list will act as your complete customer-contact database, or that a successful send API response means a suppressed address received a message. Inspect your actual provider configuration and make the application aware of suppressed contacts. If you run separate tools for receipts and campaigns, decide how a hard bounce or complaint flows between them without erasing the distinction between transactional necessity and marketing preference. This article concerns delivery failure, while consent and unsubscribe require their own rules.

Do not clear a suppression entry merely to make an important email appear sent. First establish why the address failed, verify a corrected or confirmed address with the customer, and check whether the provider requires a deliberate removal step. SES notes that addresses on its account-level list remain there until removed, subject to documented exceptions. It also says Gmail does not provide complaint data to SES through this route, so the absence of a complaint event is not proof that every recipient welcomed the message. A customer support script should explain that the order remains available in the account and offer a safe correction route; it should not promise inbox delivery. Record the operator, reason and evidence for any override.

Test the complete path with controlled addresses or provider test facilities before relying on it. Verify that a hard bounce creates one task, repeated notifications do not create multiple tasks, and a temporary delay does not immediately suppress a valid contact. Check that staff can locate the order without reading sensitive mail payloads, that a corrected address produces a new traceable attempt, and that an unresolved essential notification is visible before its business deadline. Reconcile counts of accepted, delivered, bounced and suppressed events with provider reporting, while recognising that provider event coverage and timing may differ. The acceptance result is a demonstrated recovery path for a customer action, not an attractive deliverability percentage produced without a trustworthy denominator.

Design the queue around the customer's deadline, not around the provider's dashboard. A delivery problem attached to a booking tomorrow should be visible to the team that can contact the customer today; a bounced archive copy may be reviewed on a different schedule. Show staff the order reference, contact verification status, event reason and next permitted action. Separate the ability to view a failure from the authority to change a contact address or lift suppression. Otherwise a well-meaning agent may reroute a confirmation to an unverified mailbox. Provide a customer-facing route to retrieve the current order or booking after signing in, so a delayed message does not force the customer to contact support just to learn whether the transaction exists. During testing, deliberately disconnect event ingestion and verify that monitoring catches the stalled queue; a flawless bounce handler cannot help if its provider notifications are never received. The operational test should prove ownership, timing and recovery, not only that an event can be parsed.

Make the contact policy specific to message type. A receipt, password reset, booking reminder and marketing campaign have different purposes, deadlines and permitted recovery routes. A bounced reset link should not be copied into an agent's chat reply; the customer should use a secure new request after correcting the address. A booking reminder may justify an early staff task because the event is time-sensitive, while a receipt can remain retrievable in the signed-in account. Keep a clear boundary between a delivery failure and a customer preference: a hard bounce says the address failed, not that the customer withdrew marketing consent; an unsubscribe says something about consent, not that the mailbox is invalid. If the tools share a contact database, preserve both facts separately. This prevents one automated flag from silently deciding every future form of communication.