What bounce and complaint rates trigger a suspension
Envello auto-pauses an account's sending when its bounce rate exceeds 5% or its complaint rate exceeds 0.3%, whichever hits first. These aren't arbitrary numbers, they're close to the thresholds mailbox providers and AWS SES itself use to judge whether a sender is trustworthy, so an account that crosses them is already at risk of a sending-reputation problem that a pause is meant to catch before it gets worse.
What these rates actually protect
On shared sending infrastructure, one account's bad sending pattern can affect every other account sharing that reputation. A pause at these thresholds exists to catch a problem (a stale list with a lot of dead addresses, a sudden spike in unwanted mail) before it degrades deliverability for the pool it's sending through, not to punish an account for a single bad message.
Why bounce rate matters more than it seems
A high bounce rate signals a list-hygiene problem: sending to addresses that don't exist, or haven't been valid in a long time. Mailbox providers read a high bounce rate as evidence a sender doesn't validate its recipient list, which is a real spam signal even for a sender with genuinely good intentions. Address validation before adding to a send list (checking syntax, disposable domains, MX records) is the actual fix, not just watching the rate after the fact.
Why the complaint threshold is so much lower
0.3% is a much tighter tolerance than 5% bounce, deliberately: a spam complaint is an explicit, active signal from a real person that they didn't want the message, which mailbox providers weight far more heavily than a bounce (which could be a simple typo or an outdated address, not necessarily unwanted mail). A small number of complaints represents real, decisive negative signal in a way a small number of bounces doesn't.
What happens when an account actually gets paused
A paused account stops sending immediately, existing queued messages don't go out, and new send requests return a clear error rather than silently failing. This is deliberately abrupt rather than a gradual throttle, because the whole point is to stop the bleeding before the rate climbs further while the account is investigated and the underlying cause fixed. The dashboard shows exactly which threshold triggered the pause and the account's current rates, so there's no guessing involved in diagnosing what happened.
Getting unpaused
Reach out once you've identified and fixed the underlying cause (removed a bad list segment, fixed a bug that was sending to test addresses in production, whatever triggered the spike). A pause isn't an automatic account termination, it's a circuit breaker, and it's reversible once the actual problem, not just the symptom, is addressed. Accounts that get unpaused without fixing the root cause tend to trip the same threshold again quickly, so the fix matters more than the speed of getting the pause lifted.
What to actually do before you hit either threshold
Validate addresses before sending rather than discovering they're invalid via a bounce, and treat a rising trend in either rate as the signal to act on, not the moment it crosses the line. By the time an account hits the auto-pause threshold, the underlying problem (a stale list, a mismatched audience) has usually been building for a while.