Abuse & compliance · Email
Email sending runs on the shared abuse model described in the Abuse & compliance overview: healthy traffic sends unrestricted, degraded reputation throttles your sending rate, and harmful signals pause it. This page covers the email-specific part — which signals drive that reputation, what Bird does automatically in response, and which levers you control. If your sending was throttled or paused and you want the non-developer walkthrough, see Why was my sending throttled or paused?.
The signals that drive reputation
Bird derives your email reputation from the same per-recipient events you can already observe through webhooks and the events API:
- Bounce rate — the share of sends ending in email.bounced with bounce_type: "hard". Hard bounces mean the address does not exist; a high rate is the signature of a purchased, scraped, or badly stale list, and it is the signal mailbox providers punish hardest.
- Complaint rate — the share of delivered mail reported as spam, surfaced as email.complained through mailbox-provider feedback loops. Complaints measure whether recipients wanted your mail at all.
- Unsubscribe behaviour — email.unsubscribed (your footer link) and email.list_unsubscribed (the provider-rendered one-click unsubscribe). Unsubscribes are a normal part of list life, but a spike on a campaign is an early warning that your targeting or consent has drifted — recipients who can't find the unsubscribe link report spam instead.
Because these are the same events your webhook endpoint receives, you can monitor exactly what Bird monitors. Watching your own bounce and complaint rates per campaign is the single best way to never meet the throttling machinery at all.
Indicative thresholds
The thresholds below are guidance, not contract — enforcement weighs volume, history, and trend, so a small test batch with two bounces is treated differently from a million-recipient campaign with the same rate:
- A hard-bounce rate approaching ~5% is the ballpark where sending gets paused. Healthy lists run far below 1%; mailbox providers start degrading your inbox placement well before 5%.
- Complaint rates need to stay well under 0.3% — Gmail and Yahoo enforce 0.3% as a hard ceiling for bulk senders, and sustained rates above ~0.1% already hurt placement. Bird throttles before your complaint rate damages the shared sending infrastructure.
If you expect an unusual send — a re-engagement campaign to an old segment, a list migration from another provider — clean the list first rather than letting the bounce rate discover the problem for you.
What Bird does automatically: suppression
Beyond throttling, the delivery pipeline acts on individual recipients immediately — you never have to process a bounce or complaint yourself. The signals above each add the address to your workspace suppression list, and every automatic addition fires an email_suppression.created webhook event so your systems can mirror the change:
| Signal | Suppression scope |
|---|---|
| Hard bounce (email.bounced, email.out_of_band_bounce) | All mail — the address does not exist |
| Spam complaint (email.complained) | Non-transactional mail only — transactional still delivers |
| Unsubscribe (email.unsubscribed, email.list_unsubscribed) | Non-transactional mail only — transactional still delivers |
Future sends to a suppressed address are rejected up front with email.rejected and rejection_reason: "recipient_suppressed" — they never reach a mail server, so they never count against your reputation again. Suppression is the mechanism that makes one bad signal per address sufficient: the bounce that hurt you once cannot keep hurting you.
Soft bounces and deferrals (email.deferred) do not suppress and do not carry the same reputation weight — they are transient failures Bird retries automatically.
Your levers: list hygiene and consent
Throttling responds to signals; the signals respond to how you build and maintain your list. Two practices prevent nearly every email pause:
- List hygiene — never import purchased or scraped lists, remove addresses that have not engaged in months, and validate addresses at collection time (a typo'd signup is a future hard bounce). The practical workflow is in the list hygiene guide.
- Consent — send only to recipients who asked, make unsubscribing effortless, and keep marketing in the marketing category so suppression policy and unsubscribe handling apply correctly. Most complaint spikes trace back to mail the recipient never opted into.
If sending has already been paused, fix the source list before requesting reinstatement — resuming with the same list reproduces the same signals. The throttled-or-paused walkthrough covers the recovery path step by step.
Related pages
- Abuse & compliance overview — the channel-agnostic trust & safety pipeline and throttle/pause model
- Suppressions — the four suppression reasons, the applies_to policy, and the management API
- Email events reference — full payloads for email.bounced, email.complained, the unsubscribe events, and bounce classification
- Why was my sending throttled or paused? — the non-developer walkthrough
- List hygiene — keeping bounce and complaint rates low in practice