Hard bounce
A permanent failure where the address does not exist or will never accept mail. Suppress it at once, because repeats erode sender reputation.
A hard bounce means the address does not exist or will never accept mail. Suppress it immediately; repeated hard bounces damage sender reputation.
A hard bounce means the address does not exist or will never accept mail. Suppress it immediately; repeated hard bounces damage sender reputation.
Related
The short version
- A hard bounce is a permanent delivery failure: the receiving server has decided this address will not accept mail, now or on any retry.
- The signal is an SMTP 5xx reply, usually with an enhanced code such as 5.1.1 for an unknown mailbox. A 4xx reply is a soft bounce and is not the same thing.
- Suppress a genuine hard bounce immediately and never retry it. Retrying a permanent failure is how a clean list turns into a blocked IP.
- Not every 5xx means a dead address. A 5.7.1 policy block, a greylist misconfiguration or a full mailbox reported as 5.2.2 all need investigation, not deletion.
- Under DPDP, a suppressed address is still personal data. Keep the minimum needed for suppression and document the retention window.
- Watch the rate per source, not just overall. A sudden cluster almost always means a purchased list, a scraped domain or a form that accepts typos.
The definition: permanent means no retry will help
A hard bounce is a delivery failure that the receiving mail system declares permanent. The message was refused during the SMTP conversation, or accepted and then returned in a delivery status notification, with a status that begins with five. The address does not exist, the domain does not resolve, the mailbox has been disabled, or the receiving organisation has a policy that will not change because you try again in an hour. The defining test is not the wording of the error. It is whether a retry has any chance of succeeding.
That test matters because it is operational rather than semantic. A mailbox that is full returns a temporary error today and may accept mail tomorrow, so it is a soft bounce even though the address is real and the person is real. A corporate gateway that blocks your sending IP returns a permanent-looking 5.7.1 today and may accept you next month after the block is lifted, so it is technically a hard bounce that should not lead to suppression of the recipient. The classification exists to drive one decision, which is whether to try again, and a second decision, which is whether to keep the address.
What it is not: a hard bounce is not a complaint, an unsubscribe or a spam placement. Those are three different events with three different remedies. It is not a measure of whether the recipient wanted your mail, because a dead mailbox has no opinion. And it is not a verdict on your content. A high hard-bounce rate is almost always a list-acquisition problem, and no subject line fixes a list-acquisition problem.
Hard bounce and soft bounce: the line that matters
A soft bounce is temporary. The mailbox is full, the receiving server is busy, the connection timed out, the message was greylisted and will be accepted on a later attempt, or the receiving system asked you to try again later. The reply starts with four, and the correct response is a bounded retry schedule rather than deletion. Most sending platforms retry for somewhere between twenty-four and seventy-two hours, with backoff, and then give up and record a final failure.
The practical difference is what you do with the address. A hard bounce is suppressed on the first occurrence, because a second attempt costs reputation and gains nothing. A soft bounce is retried a few times and suppressed only after repeated failures across separate campaigns, because a single full mailbox is a person on holiday, not a dead contact. Confusing the two produces one of two failures: a list that keeps mailing dead addresses, or a list that deletes real customers because their inbox was full on a Tuesday.
There is a third category that teams rarely name and badly need: the ambiguous bounce. A message accepted by the receiving server and then bounced asynchronously with a generic 5.0.0, a relay error that does not identify the recipient, or a gateway rejection that quotes a policy rather than an address. These should go to a review queue rather than straight to suppression, because the address may be perfectly good and the problem may be your infrastructure. Treating every returned message as a dead address is how a sender loses ten percent of a legitimate list in a week.
Reading the conversation, not the dashboard
A bounce begins as an SMTP conversation. Your sending infrastructure connects to the receiving host, announces itself, gives a sender, gives a recipient with RCPT TO, and waits. If the recipient is rejected at that point, you get a synchronous reply, often a 550 with a human sentence and an enhanced code. If the recipient is accepted and the message is later undeliverable, the receiving system generates a delivery status notification and sends it back to the envelope sender, which is where a non-delivery report comes from.
Those two paths produce different data. A synchronous rejection arrives with the exact code and text, in real time, tied to the campaign you are sending. An asynchronous DSN arrives minutes or hours later, may be batched, and carries the original headers so you can match it back to a recipient. Systems that only parse synchronous replies will miss a large share of async bounces, and systems that only parse DSNs will miss gateway rejections that never became a message. You need both, joined on the recipient and the message id.
The header that makes this tractable is the envelope sender, which should be a dedicated return path on your own domain rather than a no-reply address that discards what arrives. RFC 5321 defines the envelope model, and RFC 3464 defines the report format that carries the status. If your platform hides the return path or rewrites it to a black hole, you have given up the ability to see the failure, and no dashboard will reconstruct it for you.
The codes worth memorising
Enhanced status codes follow RFC 3463 and give you a structured way to classify a failure without reading prose. The first digit is the class: two for success, four for a persistent transient failure, five for a permanent failure. The second digit is the subject: one for addressing, two for mailbox, three for mail system, four for network, five for mail delivery protocol, seven for security or policy. The third digit narrows it further. A 5.1.1 is a bad destination mailbox, a 5.1.2 is a bad destination system, a 5.1.3 is bad destination mailbox syntax.
The mailbox group is where most genuine hard bounces live. 5.2.1 means the mailbox is disabled, which is permanent for that address even if the person still works there. 5.2.2 is officially mailbox full, which is temporary, but some servers return it as a five, so it belongs in the review queue rather than the suppression table. 5.2.3 is a message too large for the mailbox, which is a content problem and not a dead address. 5.3.1 and 5.3.2 are system-level problems on the receiving side, and 5.4.x is a network or routing failure.
The policy group is the one that causes the most damage when misread. A 5.7.1 means delivery not authorised, which is a block, a relay refusal or a reputation decision, and the address may be perfectly valid. A 5.7.2 is a policy block from a mailing list expansion. 5.7.26 often indicates that authentication failed, which is your SPF, DKIM or DMARC problem rather than the recipient problem. Suppressing on a 5.7.x is the single most common way a team deletes its most engaged corporate contacts, because large gateways return policy blocks for senders they have not yet learned to trust.
Suppress, investigate or retry
The decision tree has three exits and most teams use only one. Genuine unknown-recipient failures, a 5.1.1 on a domain that resolves and accepts mail, go to suppression immediately and stay there. Ambiguous failures, including policy blocks, authentication errors and mailbox-full codes returned as fives, go to a review queue where an operator or a rule can inspect the domain and the history. Transient failures, all 4xx, go to the retry scheduler with a cap and a final classification when the cap is reached.
A suppression table needs a reason and a date, not just an address. The reason tells the next person whether this was a dead mailbox, a complaint, an unsubscribe or a manual block, and the date tells them when it can be reviewed. Suppression without a reason is indistinguishable from a data loss bug, and in a migration it is the field that gets dropped first. The safest design is an append-only suppression log with the address hashed or encrypted where you do not need the plaintext, plus a small operational view for support.
Re-permissioning deserves its own path. If a contact was suppressed for a hard bounce two years ago and the person later signs up with the same address, a new consent record should be able to lift the suppression, with the reason and the new timestamp recorded. Some teams never allow this and lose legitimate customers; others allow any new form submission to override a complaint, which is far worse. Split the policy by reason: a complaint needs a genuine new opt-in, a hard bounce can be lifted by a verified new signup, a manual block needs an owner.
What a bounce record should contain
A bounce record that cannot be reconciled with a campaign is a log line, not a record. The minimum fields are the recipient, the campaign or message id, the sending domain and IP, the timestamp of the attempt and of the report, the SMTP reply, the enhanced code, the parsed classification and the action taken. Add the source of the address, because a bounce rate that is fine overall can be catastrophic for one imported list, and the source is the only field that separates them.
Store the raw reply text, at least for a sample, because the prose is where the real explanation lives. A reply that says the user is unknown in one line and a reply that says the domain does not exist look the same after you reduce them to a category, and they call for different responses: one is an address problem, the other is a typo in the domain or a dead company. Store the reply, then classify, then act, in that order.
Keep retention proportionate. A suppressed address is personal data under the DPDP Act, and the purpose for keeping it is narrow: do not mail this person again. You do not need the full name, the phone number and the campaign history to achieve that. A hash of the address plus the reason and the date is usually enough, and it reduces the harm if the suppression table is ever exposed. Document the window and make sure the retention sweep actually covers this table, because suppression is the one dataset teams forget to include in deletion workflows.
How a hard bounce turns into a deliverability problem
Receivers treat unknown-recipient volume as a signal about list quality. A sender that repeatedly hits addresses that do not exist is either buying lists, scraping them or never cleaning its own form data, and none of those behaviours predict good mail. The penalty is not usually an immediate block. It is a reputation score that drifts, a higher share of mail filtered to spam, and eventually a 5.7.1 that you then misread as a dead address and suppress, which completes the loop.
The rate matters less than the pattern. A steady one percent hard bounce from organic signups that include typos is normal and manageable. A sudden eight percent on a single imported segment is a data quality incident, and it should stop the send rather than continue to the rest of the list. The rule that works is a per-segment threshold with an automatic hold, not a global monthly average that hides the spike until the damage is done. Many teams use two percent as an operational warning line for a cold segment, which is a house rule rather than a published requirement.
Volume compounds the effect. Sending fifty thousand messages to a list where four thousand addresses are dead produces four thousand failures in a short window, and the receiving gateways see the pattern before your dashboard does. The safest sequence is to validate and suppress before the send, not after, which means running the list against a verification service and your own suppression table as a pre-flight step. Verification is imperfect, but it is much cheaper than repairing a reputation.
The Indian delivery landscape
India is not one mail environment. A large share of business mail sits on Google Workspace or Microsoft 365, where unknown-recipient replies are clean and fast. A meaningful share sits on Zoho Mail, Rediffmail and a long tail of shared hosting providers, where the response to an unknown recipient can be a generic 550, a catch-all acceptance or silence followed by a DSN. And a segment sits behind government and enterprise gateways on domains such as gov.in and nic.in, where policy blocks are common and the address is usually valid.
Catch-all domains are a specific trap. A company that accepts all mail for its domain will never return an unknown-user bounce, so your list looks clean while a large share of the addresses are typos that reach a human who never reads them. There is no reliable way to detect a catch-all from the outside without probing, which is intrusive and often blocked. The practical response is to treat very high acceptance on a small domain as a data quality question rather than a success, and to prefer verified signups over scraped addresses.
Role addresses are a second Indian pattern. info@, sales@, support@ and accounts@ are common on small business domains, and many of them are monitored by a person even though they are not personal mailboxes. They are legitimate for business correspondence and poor for marketing, because the person who reads them did not personally opt in. If a form only asks for a work email, a large share of what arrives will be a role address, so ask for a name and treat role addresses as a separate, lower-frequency stream.
Migration is where lists die
The most common hard-bounce incident in an Indian company is not a bad campaign. It is a platform migration. A team moves from one ESP to another, exports contacts, imports them into the new tool, and discovers that the suppression list was stored in the old platform as a flag on the contact rather than as a separate object. The flag does not survive the export, so every previously suppressed address is now mailable, and the first campaign reintroduces hundreds of dead addresses and a handful of complaints.
The migration checklist is short and rarely followed. Export the suppression list separately, with reasons and dates. Export the consent ledger separately, with notice versions. Reconcile the counts before and after the import, and refuse to proceed if the suppressed count does not match. Run a test send to your own seed addresses and confirm that a known suppressed address is actually blocked in the new system. Do this before the domain and the IP are switched, not after.
Re-permissioning is the other half. An old list that has not been mailed in two years will contain a large share of dead addresses, and importing it as-is guarantees a bounce spike. A re-permission campaign to the most recently engaged slice, with a clear statement of what the person is signing up for, produces a smaller list that performs far better. The smaller list is not a failure. It is the only list that will survive the next deliverability review.
Worked example: the imported list that looked fine
A Bengaluru B2B team imports sixty thousand contacts from a CRM export into a new sending platform. The export includes a column called email status with values such as active, unsubscribed and bounced, but the import mapping ignores it because the new platform expects a suppression object, not a status column. The first campaign goes to all sixty thousand, and within an hour the dashboard shows three thousand five hundred hard bounces, a little under six percent of the send.
The correct response is not to resend to the failures. It is to stop the campaign, export the bounce records, and sort them by code. In this case most are 5.1.1 on domains that resolve, which is a genuine unknown user, but around four hundred are 5.7.1 from two corporate gateways. The first group is suppressed with the reason unknown mailbox. The second group is held, the sending domain is checked for SPF alignment and DMARC, and a small test is sent after the authentication record is fixed. Most of those addresses accept mail on the retry.
The retrospective finds three fixes. The import template gains a required suppression step and a reconciliation count. The pre-flight check rejects any import where the bounce-prone status column is unmapped. And the campaign tool gets a per-segment hold at two percent hard bounce, so the next bad import stops at twelve hundred failures instead of thirty-five hundred. None of the fixes is clever. They are the difference between a team that learns and a team that repeats.
Frequently asked questions
Should a hard bounce be retried at all?
No, not for a genuine unknown-recipient failure. Retrying a 5.1.1 achieves nothing except another rejection, and a pattern of retries to dead addresses is a signal receivers use against senders. The exception is a 5xx that is really a policy or authentication block, where the address is valid and the fix is on your side. Those go to review, not to the retry scheduler.
How quickly should a hard bounce be suppressed?
Immediately, within the same processing cycle that records the failure. If the suppression write is queued behind a nightly job, any campaign launched in between can mail the address again. The write should be idempotent and should carry the reason and the timestamp. The one case for a delay is an ambiguous code that needs a human look, and that should be routed to review rather than suppressed.
Is a full mailbox a hard bounce?
Officially no. Mailbox full is a temporary condition with the enhanced code 4.2.2, and the correct action is to retry with backoff. Some receiving servers return it as 5.2.2, which looks permanent. Treat any mailbox-full code as a soft bounce regardless of the class, retry a few times over several days, and only suppress after repeated failures across separate campaigns.
What does 5.7.1 mean and why does it matter?
5.7.1 means delivery not authorised, which is a policy decision by the receiving system rather than a statement that the address does not exist. It is common at corporate and government gateways, and it often reflects your sender reputation, authentication or an unlearned sending IP. Suppressing every 5.7.1 will delete valid contacts, so route those to review and check SPF, DKIM, DMARC and the reputation dashboards first.
Does a hard bounce affect sender reputation?
Yes, in aggregate. A single bounce is unremarkable, but a sustained rate of unknown recipients tells receivers that the list is poorly sourced, and reputation models weigh that alongside complaints and engagement. The effect is usually gradual rather than an instant block, which makes it easy to miss until placement has already fallen. Per-segment thresholds catch the spike before the monthly average does.
What bounce rate is acceptable?
There is no universal published number, and anyone quoting one is describing a house rule. Many teams use two percent as a warning line for a cold or imported segment and treat anything above five percent as an incident. Organic signup lists typically sit well below one percent. The more useful practice is a per-source baseline, so you notice when one segment moves rather than waiting for the blended number to react.
Can a suppressed address be un-suppressed?
It depends on the reason. A hard bounce can usually be lifted by a verified new signup at the same address, because the mailbox may have been recreated. A complaint should require a genuine new opt-in with a clear notice, not an automatic override. A manual block should need an owner decision. Store the reason so the policy can branch, and never let a bulk import override suppression.
How does DPDP apply to a bounce list?
A suppressed address is still personal data. You keep it for the narrow purpose of not mailing the person again, so keep the minimum: a hash or the address, the reason, the date and the source. Document a retention window, include the table in erasure workflows, and restrict access. A suppression table that quietly holds full names, phone numbers and purchase history is a liability rather than a control.
Why did our bounce rate jump after a domain change?
A new sending domain has no reputation and no authentication history, so gateways are more likely to return policy blocks, and some recipients see the new domain as unfamiliar and report it. Warm the domain alongside the IP, publish SPF, DKIM and DMARC before the first send, keep the visible from-name stable, and ramp volume rather than switching the whole list in a day.