Hard bounce, soft bounce, reputation block – three different problems

The sending report shows one number: bounces. Except that number covers three completely different things. A hard bounce is an address problem. A soft bounce is a moment-in-time problem. A reputation block is a sender problem, which means yours. Drop them all into one bucket and you start making bad decisions: deleting good contacts, or resending in a way that only deepens the damage. We write from the perspective of our own fleet of sending servers and daily digging through SMTP logs, so we will show these differences the way they look in server responses.

Three refusals, three different causes

The “bounce rate” in a campaign panel is a sum. For comparing one send against another, fine, it does the job. For diagnosis, no. Diagnosis happens at the level of a single response from the recipient’s server, because only there can you see whether the refusal concerns the mailbox, its state, or you as the sender.

Separating the categories has a direct operational effect. An address with a permanent refusal comes off the list immediately, because every further contact with it damages your reputation. An address with a temporary refusal stays in the database, because in three hours it will accept the message without any trouble. And with a reputation block? You do not touch the list at all. You pause the send and look for the cause on your side.

The most common mistake we see when taking over a client from another platform is automatic cleaning based purely on the “bounced” flag. The database shrinks, the metrics look nicer for a moment, and in reality you lose recipients whose server simply had a full disk at that moment. The opposite extreme costs just as much: stubbornly retrying everything in a loop until the filter on the other side stops accepting anything from your IP. That is why it pays to have a hard threshold at which the campaign stops by itself – we described how to set up an automatic stop at three percent bounces.

Hard bounce: an address that does not exist

A hard bounce is a permanent refusal from the recipient’s server. In the logs you will see a code from the 5xx family, most often 550 with a message about an unknown user, sometimes 550 about a non-existent domain, or 553 about invalid recipient syntax. The answer is final. The server will not change its mind next week, so retrying is a waste of time.

Where do such addresses come from? Usually from four places:

• A typo in the form – the classic “gmial.com” or a missing letter in the user name.
• Staff turnover – a company mailbox shut down after someone left the organisation.
• A dead domain – the company changed its name, the registration expired, the MX stopped answering.
• A made-up address – somebody wanted the lead magnet without giving a real mailbox.

The reaction is unambiguous: remove the address from the list at once and record the reason in the contact history. That reason matters more than it seems – a few months later it lets you reconstruct whether the problem was isolated or systemic. A high share of permanent refusals in a first send almost always says something about the source of the database, not about the content of the email. A purchased file, an old CRM export, a list from three years ago. Every one of those sources produces the same pattern.

Tip: syntax validation and an MX record check at the form stage removes a good part of the problem before anything leaves the server. A few milliseconds on the sign-up side, and much less damage on the reputation side. If you keep your sign-up forms in a CRM or on your website, check whether the data reaches the sending system through a ready-made integration, because manual export and import is the main source of typos in a database.

Soft bounce: a temporary obstacle

A soft bounce returns 4xx codes. The messages talk about a full mailbox, an overloaded server, a domain temporarily unavailable, or an exceeded hourly message limit. The address exists, the recipient is alive, delivery just is not possible right now. That kind of refusal is an invitation to retry, not a verdict.

Greylisting is a case of its own. The recipient’s server deliberately rejects the first attempt from an unknown sender, betting that a spammer will not come back. A correct queue returns after a few minutes and gets through without trouble. But if your tool marks such a refusal as an error and never tries again, you lose deliveries for nothing.

A well configured queue handles this on its own, retrying at growing intervals across a few dozen hours. You do not have to click anything. What you do have to set is an unsubscribe threshold: an address that returns a temporary refusal across several consecutive campaigns should be treated as dead. A mailbox that has been full for six months is an abandoned mailbox, even if it technically answers with a 4xx code.

A single temporary refusal says nothing about your reputation. But a run of such refusals from one domain says quite a lot, especially when it appears suddenly. Large operators can slow down accepting mail from a sender who has crossed their internal limit, and they signal it with exactly this kind of temporary code. It is an early warning before a harder reaction.

Reputation block: this is not a bounce

The third phenomenon only looks like a bounce. The refusal concerns the sender, not the recipient. The address exists, the mailbox works, the owner is waiting for the message. The filter simply does not want to accept mail from you.

In the logs you can see it in the text of the message. References to server policy appear, names of blocking lists, sometimes a ready link to an appeal form. The code can be misleadingly similar to an ordinary address rejection, which is why reading the digits alone leads you astray.

There is also a quieter and much nastier variant. You get no refusal at all, and the message lands in spam. The bounce statistic stays flat, opens and clicks fall. Without putting those two charts side by side, it is easy to conclude that the subject line was simply weaker.

A block can be applied to an IP address, to the sending domain, or to both at once. The distinction matters when you fix it: moving traffic to another IP does nothing if the filter remembered the domain from the From header.

From getting out of blocks at the big filters we have one repeatable lesson: the order of actions decides how fast you come back. First you stop sending to the affected operator. Then you remove the cause. Only at the end do you file an appeal. Retrying a send while blocked makes things worse and extends the quarantine, because every rejected attempt is one more data point in the filter’s statistics.

How to tell them apart in the logs

The basic divider is the first digit of the SMTP code. A five means a permanent refusal, a four a temporary one. That is a first approximation and it is enough for sorting the queue, but not for deciding whether to remove a contact.

The text of the message weighs more than the code itself. A 550 refusal with information about an unknown user is a hard bounce and the address goes off the list. A 550 refusal referring to sender policy is a reputation block and you do not touch the address, because there is nothing wrong with it. The same number, two opposite actions.

A checklist for quick diagnosis

1. What is the response code and what exactly does the message text say?
2. Does the problem concern one recipient domain or several at once?
3. Did it start suddenly in one send, or build up across several campaigns?
4. Did opens at that operator fall at the same time?
5. Did anything change on the sender side: a new IP, a new domain, a jump in volume?

A separate matter is the Return-Path, the return address that is not visible in the message. Without a correct return address, bounce reports never come back to the system and the statistics lie in the worst possible way – by showing zero problems. So before you start analysing the distribution of refusals, make sure you are collecting them at all.

The distribution over time also tells you a lot. A sudden spike at one large operator points to the sender. Refusals spread evenly across many domains point to the quality of the database.

What to do in each of the three cases

1. Hard bounce – remove the address immediately, record the reason, check where the contact came from. If a whole batch from one source throws permanent refusals, it is the source that has to go, not the individual records.
2. Soft bounce – leave the retries to the queue and set an unsubscribe threshold after several campaigns in a row. Do not delete after the first refusal.
3. Reputation block – pause sending to that operator and move on to authentication diagnosis.

With a block, stick to the order. First SPF, DKIM and DMARC: do the records exist, does the signature pass verification, does the domain from the signature match the sender domain. Then PTR for the sending address, because a missing reverse record throws you out at some filters before they even look at the content. And only at the end the content of the message and the sending frequency.

Reputation is rebuilt on the most active segment. Send to the people who open and click regularly, at low volume, and let the filter see positive signals. The same principle governs warming up a new IP: gradually growing volume instead of a full campaign on day one. A fresh IP with no history that suddenly spits out tens of thousands of messages is a textbook spammer pattern as far as the filter is concerned.

It is also worth separating transactional traffic from marketing traffic onto different domains or subdomains. An order confirmation and a newsletter have different engagement metrics, so let them have different reputations too. If you are planning that kind of architecture, we walk through it during rollouts on our email marketing platform with its own fleet of sending servers.

Tip: before you send an appeal to a filter, fix the cause. An appeal with no change on the sender side usually comes back refused, and a second attempt is treated less kindly than the first.

List hygiene and consent as part of deliverability

Addresses collected without consent generate more permanent refusals, more spam complaints, and lead to a block faster. This is not a moral question, it is a technical one. A recipient who does not remember signing up clicks “this is spam” instead of unsubscribing, and that signal goes straight to the filter.

The legal side closes the same loop from the other direction. GDPR requires a legal basis for processing data, and article 398 of the Polish Electronic Communications Law (PKE) requires consent for commercial communication – including in B2B relationships, contrary to the widespread belief that a company address is free of those limits. The consent has to be freely given, specific and possible to demonstrate.

Double opt-in settles both matters at once. Confirming the sign-up gives you proof of consent and at the same time filters out typos and disposable addresses, because nobody goes back to a mailbox they never intended to use. The cost? A list a few percent smaller and clearly healthier. Recommended.

On top of that, clean out inactive contacts regularly. Lower volume means better metrics, calmer filters and cheaper sending. To be honest: some of the automatic cleaning rules are on our roadmap, and today some thresholds are set by hand. We would rather say that plainly than promise a button that is not in the panel yet. What exactly works today on the queue, retry and bounce handling side, you can check in the platform feature list.

Summary

Three phenomena, three reactions. Hard bounce – remove. Soft bounce – retry with a threshold. Reputation block – stop and diagnose on your own side. Without that separation, a campaign report tells you nothing useful, because one number mixes a database problem with a sender problem.

Reputation is built over months of regular, properly authenticated sending. It is lost in a single campaign to a purchased list. That asymmetry is the most important thing to remember.

Preparing your first campaign from a new domain? Let us talk about the authentication setup and the warmup plan before anything goes out. Repairing reputation after the start costs far more work than setting up the records before it.