By Tangenix · Published 2026-10-24 · Free template

Email Bounce and Complaint Triage Card

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

Read this resource as Markdown

When to use this template

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.

Gather these 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.

Copy and adapt the template

Edit the text below and copy it into your own document. Edits stay in this browser field and are not submitted or saved by this page.

Worked example

Illustrative example, not a Crany customer result. Replace every example detail with facts you can verify.

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 it

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.

Check before using it

• 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 — checked 2026-10-24. Provider-specific bounce, retry, complaint and suppression distinctions; successful API acceptance is not delivery or inbox proof.

This original template and worked example were prepared with AI assistance. Source documentation supports the principles stated above; it does not endorse Crany or guarantee this template’s performance.

About Crany

Crany is an AI marketing co-founder in development for software founders and vibe coders, designed to strategize, execute approved marketing and improve based on results. This free resource is usable independently of the product. Join the public waitlist.