Bounce rate gate: automatic stop at 3 percent

A bounce rate gate pauses a campaign mid-send, as soon as the share of hard bounces crosses a set threshold. This is not a gadget in the panel or a number to look at after the fact. It is sender reputation protection that works while there is still something to save. The standard threshold is 3 percent. Above that value, large mailbox providers stop seeing you as a company mailing its own recipients and start seeing a source of traffic to inboxes that do not exist.

What a bounce rate gate is and why the threshold sits at 3 percent

First a distinction, without which the rest makes no sense. A hard bounce is a permanent error: the address does not exist, the account was deleted, the domain does not answer and will not start. The recipient server returns a 5xx code, most often 5.1.1. A soft bounce is a temporary problem – a full mailbox, an overloaded server, a temporary limit on the other side. Codes from the 4xx family, and a retry a few hours later usually ends in delivery. A reputation block is something else again, which is why it pays to know how these three situations differ before you start counting them in one report.

The gate counts hard bounces above all. Soft ones go into a separate retry queue and should not stop a campaign, because they say something about the state of a server, not about the quality of your list. Throw both into a shared counter and every outage at a large provider will hand you a false alarm.

Why 3 percent exactly? It is an operational decision, not the result of any study. The threshold is picked so that it fires before filters on the recipient side start reacting, while not interrupting a send over the natural scatter of expired addresses. Lower is fine. Higher makes no sense, because past that line stopping a campaign is only damage control.

What happens to reputation when there is no gate

Without an automatic stop, bounces pile up in real time and you learn the result once the send is over. The report shows the scale of a problem that can no longer be undone. Everything went out, every error got recorded on the other side.

Recipient filters look at this completely differently than your panel does. They see a run of 5xx responses from one IP address and one domain in the Return-Path. That pattern reads simply: someone is mailing a list they do not know. The reaction comes in stages. First throttling, meaning a limit on how fast connections are accepted. Then queuing with growing delay. At the end, connections rejected from the whole address range, not just from that one IP.

And here you have to separate two things that are terribly easy to confuse. IP reputation sits in the infrastructure and can be changed by moving the sending. Domain reputation follows you everywhere. A burned sending domain works just as badly on a new server, at a new provider and after an operator change. The most expensive mistake in all of deliverability.

From our experience: getting out of a block at a large filter takes incomparably longer than earning one. Usually it means a send freeze for several weeks, then a slow restart on a narrow, active segment. Raising volume in the hope that the statistics will dilute? That deepens the problem. There is also a side effect for shared infrastructure – one sender with a dirty list ruins deliverability for every neighbour on the same IP.

How the gate works in practice: threshold mechanics

The gate needs a sample. Two bounces out of five messages sent is formally 40 percent and zero information. That is why the threshold must only switch on after a minimum number of deliveries. Without that condition, every campaign to a small segment would end in a stop at the start.

The second parameter is the measurement window. You count the percentage cumulatively from the start of the campaign, or in a rolling window of the last messages sent. The cumulative variant is more resistant to accidental clusters. A rolling window catches a problem that starts mid-send faster – for example when the queue reaches a part of the list from a different import.

Order of events when the gate fires

1. The recipient server returns a permanent 5xx error on a specific message.
2. The system parses the SMTP code and classifies the bounce as hard.
3. The address goes onto the suppression list, the hard bounce counter goes up.
4. Once the minimum number of deliveries is reached, the counter starts being compared against the threshold.
5. Crossing the threshold pauses the queue: the next batches do not go out.
6. Campaign state is saved, so it can be resumed without repeating sends.
7. The sender gets a notification with the number sent, the number bounced and a pointer to the list segment.

And one more distinction: the gate pauses the send, it does not delete the campaign. The rest of the list waits untouched, nobody has burned it yet. That is the most valuable effect of the whole mechanism.

A bounce is a symptom, not the disease: where dead addresses come from

A sudden jump in bounces almost always has a specific source. Number one: a list bought or imported from an uncertain place. Nobody knows when those addresses were created or whether anyone ever confirmed them. The second cause is old lists that nobody has mailed for a year or more. Work addresses expire along with employment, and staff turnover at companies does its work at a pace you cannot see – until you click “send”.

The third source is banal: typos from forms with no double opt-in. gmial.com, wp.p, a missing letter in a company name. Every entry like that is a guaranteed hard bounce on the first campaign.

A separate category is spam traps, meaning addresses abandoned and reactivated by the provider. They do not bounce. They accept the message and quietly lower your score at the filter. No bounce rate gate will catch them, because formally everything went through.

So treat the automatic stop as a last chance safeguard, not a replacement for list hygiene. The foundation is how you collect addresses. If addresses come in from forms on your site or from an external CRM, it is worth checking the available integrations with the sending system, so the data lands in your list without manual retyping and typos. GDPR and article 398 of the PKE, the Polish Electronic Communications Law, require consent in B2B contacts too, for named personal addresses. A list collected in line with those rules has fewer dead addresses by nature, because behind every entry stands somebody’s conscious confirmation.

What to set up on the technical side before you need the gate

Before you start measuring bounces, make sure you are measuring the right thing. With authentication missing, bounces are the smallest of your worries, because some of the messages never reach the stage where a bounce is created at all.

Minimum DNS setup before the first campaign

• SPF on the sending domain, with the servers that actually send.
• DKIM with a key signing every outgoing message.
• DMARC with a policy and a reporting address, at least in none mode to start.
• Return-Path on your own subdomain, so bounces come back to the system and not to the marketing inbox.
• PTR matching the sending host name, in both directions.
• A and MX records on the sending subdomain.

On top of that, bounce parsing. The system has to read SMTP codes and classify 5.1.1 completely differently from 4.2.2. Without it, the gate counter mixes nonexistent addresses with temporarily unavailable ones and loses its meaning. It is also worth checking where bounces actually come back to and who sets that address, because that decides whether the counter sees the full set of errors at all.

A new domain and new IP need a warmup. Small volumes at the start, growth spread over weeks, the first batches to your most engaged recipients. Filters learn your traffic pattern, and a sudden send to tens of thousands of addresses from an unknown IP looks exactly like what they block.

Tip: send a test campaign only to the segment of your most active recipients. If bounces there go above a few per mille, the problem sits in the configuration, not in the list. Those addresses work, so the error is on your side.

What to do when the gate stops a campaign

First rule: do not resume the send right away. A stop only makes sense if you use it for diagnosis. Check whether the bounces come from one import or whether they concentrate on one recipient domain.

That distinction changes the whole treatment. Bounces concentrated on one recipient domain usually mean a block, not dead addresses. Then you fix configuration and send rate, and the list is fine. Bounces scattered across many domains? There the problem is list quality.

Remove hard bounces immediately and permanently. Sending again to an address that already returned 5.1.1 deepens the problem and is the simplest way to confirm to filters that you have no control over your own list. Split the rest: active in recent months for further sending, the others for a reactivation campaign or for deletion.

Resume at lower volume and watch the first batches before you let the whole thing go. The rate is back to fractions of a percent? You can return to normal pace.

Tip: if a fresh import gives more than a few percent bounces on the very first batch, delete the whole import instead of rescuing it. The cost of cleaning and the risk to domain reputation can be higher than the value of a list like that.

How we approach this at MailCraft

We run our own fleet of sending servers instead of reselling somebody else’s API. That gives us control over IP addresses, PTR records and send rate. When a campaign has to be slowed down or spread over a longer period, we do it at the infrastructure level. We do not ask an external provider for it.

Bounce parsing and hard suppression of addresses after a hard bounce are standard here, not an add-on in a higher plan. An address that once returned a permanent error does not get another message. You will find the full list of what is in the panel in the platform feature overview.

Honestly about the limits: part of the threshold automation, including a fully configurable gate that stops a campaign on its own, is on our roadmap and not in the panel. Until we ship it, we monitor volumes and bounces on the operational side and react by hand. We would rather write that plainly than describe a feature you cannot click yet.

We treat GDPR and PKE compliance as a product feature. Data stays on our servers, and the consent requirement in B2B as well is our starting point when configuring accounts, not a problem to work around. If you are looking for an email marketing platform with its own sending infrastructure, this is exactly that model.

What we do not promise: getting around filters. No provider will guarantee you the inbox. What can be guaranteed is correct authentication setup, a predictable send rate and transparent bounce handling. The rest depends on who is on your list.

Summary: the threshold as a limit, not a target

3 percent is the line where you stop the machine. Not a target level. A healthy list stays in fractions of a percent, and any value approaching the threshold is a signal to review the list – not a reason to be pleased that you still fit under it.

The order of operations is fixed: a legally collected list, correct DNS, domain and IP warmup, bounce parsing with code classification, and only at the end the automatic stop. Reverse that order and you get a mechanism that stops campaigns which should never have been sent in the first place.

A bounce rate gate will not fix your list. It buys time for diagnosis and protects the rest of the list from a send straight into a block. That is all. And that is enough to have one.

Moving your sending and you know the list needs cleaning up? Let us start with a list audit. Write to us, we will go through the list structure, the DNS setup and the warmup plan before we settle on sending limits.