# Email Bounce and Complaint Triage Card

Canonical page: https://waitlist.crany.ai/marketing-templates/email-bounce-complaint-triage-card

By Tangenix. Published 2026-10-24. Category: Email operations.

Classify a real delivery event before retrying a marketing email, keeping temporary failures, hard bounces, complaints and suppression distinct.

## Task

Turn a provider delivery event into an accountable retry or suppression investigation without treating accepted sends as delivered mail.

## When to use

Use this when a marketing campaign produces delivery failures or recipient complaints and an owner needs to decide what to investigate. Work from the actual event and provider semantics.

## Choose another approach when

You plan to retry every failure automatically, bypass a suppression to improve a reported delivery rate, or want to contact a complaining recipient through another address.

## Inputs

- The redacted provider event, timestamp, message reference and classification fields.
- The sending provider’s current retry and suppression behavior.
- Existing contact permission, suppression scope and the owner authorized to investigate.

## Template

    Provider / message reference / event time: [redacted evidence]
    Exact event label and reason: [preserve original semantics]
    Classification: temporary failure / permanent failure / complaint / suppressed / unresolved
    Provider retry already in progress? [actual status, not assumed]
    SES example: soft failures can be retried by SES; repeated attempts to hard-bouncing or complaining addresses are discouraged.
    Requested action: await provider retry / investigate / preserve marketing exclusion
    Recipient-address validity evidence: [unknown stays unknown]
    Suppression scope and current state: [do not bypass to force a send]
    Duplicate-event check: [one message can produce several notifications]
    Owner decision / rationale / follow-up evidence: [specific action]
    Reporting correction: accepted, failed, suppressed and delivered remain distinct
    Do not expose the recipient or paste a live message token into a public incident note.

## Illustrative example

This is not a Crany customer result. Replace example details with verified facts.

    Fictional example: a campaign's provider event reports a persistent mailbox failure. The founder records the actual classification and preserves the marketing exclusion rather than repeatedly resending a launch announcement.
    A separate temporary event is still within the provider's retry process. The owner waits for that outcome instead of adding an uncontrolled application retry on top of it. A complaint is handled as its own recipient signal, not as an address typo to route around.
    The event card uses redacted identifiers. It does not delete a contact, override suppression or send a follow-up. SES behavior is cited as provider-specific evidence; another service requires its own current definitions before the same operational decision is made.

## How to use

1. Preserve the actual provider event and classify it without renaming the reason.
2. Check retry and suppression state before proposing any additional send.
3. Assign a bounded investigation and update reporting from the observed final outcome.

## Checks

- A complaint has not been treated as a technical invitation to retry elsewhere.
- Provider retries and application retries are not accidentally combined.
- Suppressed or accepted messages are not mislabeled as delivered or inbox-placed.

## What to measure

Review repeated retry mistakes, unresolved event classes and reporting corrections. Count each message’s relevant outcome with the actual provider semantics. This triage does not guarantee a recoverable address or authorize removing an existing suppression.

## Research and sources

Amazon SES documents persistent and temporary failures, provider retries and complaint handling. This original triage card applies those distinctions as a bounded example; it does not generalize every SES status to other email providers.

- [Amazon SES: Understanding email deliverability](https://docs.aws.amazon.com/ses/latest/dg/send-email-concepts-deliverability.html) — checked 2026-10-24. Provider-specific bounce, retry, complaint and suppression distinctions; successful API acceptance is not delivery or inbox proof.

Prepared with AI assistance. Sources support the stated principles; they do not endorse Crany or guarantee performance.

## About Crany

Crany is an AI marketing co-founder in development for software founders and vibe coders. It is designed to strategize, execute approved marketing and improve based on results. These free resources are usable independently of app access. The public waitlist is at https://waitlist.crany.ai/.