Suppression & Suspension

Understanding how SendFleet handles email bounces, spam complaints, suppressed addresses, and automatic account suspension is essential for maintaining healthy deliverability on Shared SES plans.

Suppression list

SendFleet maintains a global suppression list for Shared SES sends. When an email address triggers a hard bounce or a spam complaint, it is automatically added to the suppression list. All subsequent send attempts to that address are rejected before they ever reach SES, returning a 422 error.

Why suppression exists

Re-sending to bounced addresses wastes your monthly quota, harms your sender reputation, and - because all Growth/Pro accounts share our SES infrastructure - can affect every other sender on the platform. The suppression list protects everyone.

What gets suppressed

Suppression error response

When you attempt to send to a suppressed address, the API returns immediately without queuing:

{
  "success": false,
  "error":   "recipient_suppressed",
  "detail":  "'user@example.com' is on the suppression list due to a previous hard bounce or spam complaint."
}

Handling suppressed recipients in your code

Check for "error": "recipient_suppressed" in your response handling. When you receive this, mark the address as undeliverable in your own database and stop attempting to send to it. Do not retry suppressed addresses automatically.

response = requests.post("https://sendfleet.net/api/send/", ...)
data = response.json()

if response.status_code == 422 and data.get("error") == "recipient_suppressed":
    # Mark undeliverable in your own database
    db.mark_undeliverable(recipient_email)
    # Do NOT retry - the address is permanently suppressed

Suppression cache

Suppression lookups are cached for up to 10 minutes to reduce database load. A newly suppressed address will be enforced within 10 minutes across all sends. This is intentional - new suppressions propagate quickly enough to protect reputation without impacting hot-path latency.

Bounce & complaint processing

On Shared SES plans, SendFleet receives bounce and complaint notifications from AWS SES via SNS webhooks. These are processed automatically in the background after each delivery.

Automatic account suspension

To protect the shared sending pool, SendFleet automatically suspends Shared SES accounts that exceed bounce or complaint rate thresholds. The check runs after every bounce or complaint event is processed.

Thresholds

The minimum sample size prevents accounts with very low volume from being suspended on noise. An account that has sent fewer than 50 emails in the past 7 days is not evaluated, regardless of rate.

What suspension does

When an account is suspended:

• ✕ All POST /api/send/ calls return 403 Forbidden with "error": "sending_suspended"
• ✓ Dashboard access is preserved - you can still log in, view email history, and contact support
• ✓ Your API keys remain valid - they will work again once reinstated

Suspension error response

{
  "success": false,
  "error":   "sending_suspended",
  "detail":  "Your account sending has been suspended. Reason: bounce rate 5.23% exceeds our threshold. Contact support to reinstate."
}

Requesting reinstatement

Reinstatement is a manual process - it is never automatic. This is intentional: an account that breached thresholds and is immediately reinstated will often breach them again within hours.

To request reinstatement, email support@sendfleet.net with:

We aim to respond to reinstatement requests within 2 business days. Accounts that have been suspended multiple times, or that cannot demonstrate corrective action, may not be reinstated on Shared SES and will instead be directed to the BYOC path.

Preventing bounce & complaint issues

Manual suspension by admin

In addition to automatic suspension, SendFleet support can manually suspend accounts for policy violations including spam, abuse, or Terms of Service breaches. Manual suspensions behave identically to automatic ones from your application's perspective - the same sending_suspended error code is returned.

All suspension and reinstatement events are recorded in an append-only audit log with the trigger reason, bounce/complaint rates at the time, and whether the action was automatic or manual. This log cannot be modified or deleted.