Deliverability: bounces, complaints, and the guardrails
Last updated July 21, 2026
In short. SEMAOS watches your rolling 24-hour hard-bounce rate on platform sends: 5% throttles sending until the rate recovers, 10% suspends it. Hard bounces and complaints suppress the contact automatically.
Platform sending runs behind automatic deliverability guardrails. They exist because reputation damage is collective: on the shared domain, one tenant's bad list hurts every tenant's inboxing, and on your own custom domain it hurts every future send you'll ever make. This article explains what's measured, where the thresholds sit, and what to do on the wrong side of them.
What exactly is measured?
The hard-bounce rate over a rolling 24-hour window of platform sends: hard bounces divided by attempted sends. Two deliberate exclusions keep the number honest. Soft bounces (full mailbox, temporary server trouble) don't count, since the mail system retries those itself and they say nothing about list quality. And under 50 attempted sends in the window, the rate isn't acted on at all, so a single unlucky bounce on a quiet day can't trip anything.
What happens at each threshold?
At 5%, new platform sends are throttled: they're refused with a clear error, sequences pause rather than fail, and the block lifts by itself as soon as the rolling rate drops back under 5%. You'll get an admin email when this trips, at most once per day.
At 10%, sending is suspended outright and stays suspended until support reactivates the account. This is the "your list is actively damaging the domain" line, and it's intentionally sticky: the automatic recovery that applies to throttling doesn't apply here.
Mailbox sends are not gated by these thresholds; they ride your own account's standing instead. The bounce data still records, so the deliverability dashboard reflects both channels.
What lands a contact on the suppression list?
Two events, both automatic and immediate: a hard bounce (the address doesn't exist) and a spam complaint (the recipient hit "mark as spam"). Suppressed contacts are skipped by every future send on every channel, which is the mechanism that stops a bad address from bouncing twice. Unsubscribes join the same list; the compliance guide covers that side.
Complaints deserve extra respect: the dashboard flags complaint rates from 0.08%, and 0.1% is the level at which inbox providers themselves start punishing senders. If complaints are climbing, the problem is consent or targeting, not mechanics.
Where do I see all this?
Settings → Deliverability shows the rolling bounce and complaint rates with green, amber, and red health bands, plus the most recent bounces and complaints individually (downloadable as CSV, with each suppressed contact badged). When a rate looks surprising, start there: the individual bounce list usually names the bad import or the stale segment within a minute of looking.
How do I stay out of trouble?
Three habits cover nearly all of it. Import your suppression list from your previous tool before your first send, so known-bad addresses never get attempted. Clean stale segments before big broadcasts, since addresses go dead at a few percent per month and a two-year-old list can bounce enough to throttle you on its own. And watch the first sends to any new list: SEMAOS also rate-limits every new account's first 100 platform sends to 10 per hour precisely because early sends set first impressions with providers.
If you do get throttled: pause whatever sequence or broadcast targets the worst list, let the window age, and re-import a cleaned version. Throttling recovers on its own; the goal is not crossing 10% while it does.