Email bounces: what they mean and how to fix them

A bounce email, also called a bounced email or a bounce-back, is a message the recipient's mail server refused or could not deliver, so it came back to the sender with an error instead of reaching an inbox. Every bounce falls into one of two groups: a hard bounce is a permanent failure for that message, and a soft bounce is temporary and may succeed on a later attempt. A permanent failure does not always mean the address is bad, so what you do next depends on the reason given.

Read the diagnostic code before deciding whether to retry, correct the message or remove the address.

What does it mean when an email bounces?

Sending an email is a conversation between your provider and the recipient's mail server. The receiving server can accept the message, or it can answer with an error. A bounce is that error, reported back to you. It is different from a message that was accepted and then landed in spam: a spam-folder message was delivered, while a bounced message never was.

A bounce can happen straight away, when the receiving server refuses the message during the exchange, or later, when a server first accepts it and then sends a failure notice back (an asynchronous bounce). Either way the useful part is the reason it gives.

Hard bounce vs soft bounce

• Hard bounce: a permanent failure for the message as sent. Usually the address or domain does not exist, in which case retrying will not help and repeated sends damage your reputation. A hard bounce can also be a policy, authentication or content rejection, which is about the message or your sending setup rather than the address.
• Soft bounce: a temporary failure. The mailbox is full, the server is down or busy, or the server is rate limiting you. A later attempt can succeed, so a well-run sender retries for a while and then gives up.
• Block bounce: a rejection about you rather than the address, such as a poor sender reputation, a missing authentication record or a blocklisted IP address. Providers may report these as permanent, soft or undetermined, but they will not clear until you fix the cause, and the address itself is usually fine.

Common bounce codes and what they mean

A bounce message carries a three-digit reply code and usually an enhanced status code in the form class.subject.detail, defined in RFC 3463. The first digit is the part to read first: 4 means a temporary failure, 5 means a permanent one.

• 5.1.1 (user unknown): the mailbox does not exist. Usually a typo or a deleted account. Hard bounce; remove the address.
• 5.1.2 (bad destination system): the domain does not exist or cannot receive mail. Hard bounce; check the spelling of the domain.
• 5.2.1 (mailbox disabled): the account exists but is not accepting mail. Treat it as a hard bounce if it repeats.
• 4.2.2 (mailbox full): the recipient is over quota. Soft bounce; retry later.
• 5.3.4 (message too big): the message or its attachments exceed the recipient's limit. Retrying the same message will fail again; shrink it or link to the file instead.
• 4.4.1 and 4.4.7 (connection or delivery timeout): the server could not be reached or kept deferring. Soft bounce.
• 5.7.1 (delivery not authorised): the recipient's server rejected the message by policy. This is the one that points back at you: failed SPF, DKIM or DMARC checks, a blocklisted address, or content the server treats as spam.

Receiving servers word their own messages differently, so use the code to pick the category and the text to find the cause. When a message says the problem is your domain or IP address, that is a reputation or authentication problem, not an address problem.

Why emails bounce, and how to fix each cause

• The address is wrong. A typo at sign-up, a retired address or a fake one. Fix it by confirming the address before you rely on it: send a confirmation email, and reject obvious typos in the form.
• The mailbox is full or the server is down. Nothing to fix on your side. Retry, and stop after a sensible window.
• Your domain fails authentication. Publish SPF and DKIM records for your sending domain and a DMARC policy, and check they pass. Strict receivers reject mail that fails these checks.
• Your sending address or domain has a poor reputation. Stop sending to addresses that have bounced, send only mail people expect, and keep transactional and marketing mail on separate subdomains to reduce the risk of marketing mail affecting transactional delivery.
• The message looks like spam. Remove misleading subject lines, broken links and image-only bodies.
• The message is too big. Link to large files rather than attaching them.

How bounces affect your sender reputation

Mailbox providers watch how often a sender's mail bounces. A high rate of hard bounces tells them you are sending to addresses you have not checked, which is what spammers do, and they respond by filtering more of your mail or rejecting it. There is no single published threshold that every provider uses, so act on every hard bounce rather than aiming for a rate you can live with. Read the reason first: when it says the address or mailbox doesn't exist, remove it from your list at once; when it is a policy, authentication or content rejection, the address may be fine, so fix the cause (your DNS records, the content, or the sending domain) instead of dropping the recipient.

What to do when an email bounces

• Read the bounce class first: hard, soft or unknown.
• For a bounce that says the address or domain is invalid (5.1.1, 5.1.2), stop sending to that address and mark it in your own data, so no other part of your app emails it.
• For other permanent failures such as authentication, policy, content or size rejections, the address is probably fine. Correct the cause before you resend.
• For a soft bounce, let the retries finish. Only treat the address as dead if it keeps soft bouncing over several days.
• For a block bounce, read the message for the reason, fix your authentication or reputation, and check one test message before resuming volume.
• Tell the person. If a user's password reset bounced, show them in your app that the address may be wrong rather than leaving them waiting.

How Boundry handles bounces

When a recipient server rejects a message, Boundry records an email.bounced event with a bounce classification of Permanent, Transient or Undetermined. Boundry automatically suppresses addresses that bounce permanently, so a hard-bounced address is not tried again. A transient bounce such as a full mailbox is not a reason to stop sending, so check the classification before you act. When a server defers a message and retries continue, you get email.delivery_delayed instead.

You receive these events through a signed webhook. Name email.bounced and email.complained when you create it, and your app decides what to do with each.

POST /webhooks
{
  "endpoint": "https://hooks.example.com/boundry",
  "events": ["email.delivered", "email.bounced", "email.complained"]
}

Deliveries are signed. Verify each one with the current Boundry SDK, and deduplicate by event.id (also sent as the boundry-event-id header), which stays the same across retries. The webhook documentation has the verification code. Because a Boundry project belongs to one region, the bounce record and the suppression entry are stored in that project's region.

Verify signatures and handle retries with the current SDK, as described in the webhook documentation. Read the webhook documentation

The full list of delivery events is in the guide to how transactional email works. Read what transactional email is

Confirming an address when people sign up is the simplest way to stop invalid addresses bouncing later. The confirmation emails guide has examples and a sending flow. Confirmation emails, with examples

If you are comparing providers, bounce events and automatic suppression belong on the checklist. Choosing a transactional email API