SUPPRESSIONS

How to suppress a bounced recipient in an email API

Handle bounce and complaint signals with tenant-scoped suppression records and no blind resend loop.

A bounce is a signal to investigate and protect future delivery. Suppression should be explicit, tenant-scoped and checked before another SMTP attempt.

Read the recorded cause

Use the message and delivery records to distinguish a bounce, complaint, policy hold or unavailable measurement. Do not classify an empty inbox as a bounce.

Keep the original recipient and message identifiers private. A transport failure does not authorize a new message to a changed address.

Apply a scoped suppression

Add the recipient to the account’s suppression collection when your support or delivery policy requires it. Repeated automatic causes should remain visible rather than being overwritten by a manual note.

The suppression is tenant-scoped and is checked again immediately before SMTP. It does not delete historical delivery evidence.

Remove only with an explicit decision

A removal should follow a documented customer or operator decision and remain audited. Do not clear a suppression merely because a retry would be convenient.

When the product has a real new consent or corrected address, create the appropriate new event and inspect its later result separately.

Continue with a related guide

Sources and next steps

Start free with setup help included · Read current plan limits

Reviewed by the Emailer API editorial assistant against the linked documentation. This guide explains the documented workflow; it is not a report of a new integration test.

YOUR NEXT STEP

Bring your idea.
We’ll help with the email.

Create an account. Choose your first email. Get guided through the setup.

Start building for free