Email bounce back: causes and how to fix them

An email bounces back when the receiving mail server refuses it, or cannot accept it, and sends a failure report to the sender. A hard bounce is permanent, such as an address that does not exist: stop sending to it. A soft bounce is temporary, such as a full mailbox or a server that is briefly refusing mail: wait, and let the sender retry. The SMTP code in the report tells you which one you have and what to fix before you send again.

A mistyped address, a full mailbox, and a receiving server rejecting your domain need different responses. Repeatedly clicking send can leave the original problem untouched and create duplicate emails if an earlier attempt is still being retried.

Find the failure report first

Open the bounce notice or the failed email's delivery details. Save the recipient address, sending time, message identifier, and complete error response. If several people received the same email, check which recipient failed; one bounce does not tell you what happened to the others.

A bounce notice can have a subject such as “Delivery Status Notification” or “Undelivered Mail Returned to Sender.” The useful part is usually beneath the introductory text: the failed recipient and the receiving server's response. In an email API, look for the subsequent delivery event as well as the original send response. An accepted send request alone does not establish delivery.

Start by distinguishing these cases:

A message in the spam folder has a different diagnosis from a rejected delivery. A receiving server can also reject email because of a spam policy, so the word “spam” in an error report does not mean the email reached that folder.

Read the code and the explanation together

An illustrative response might look like this:

550 5.1.1 Recipient address rejected: user unknown

Here, 550 is the SMTP reply, 5.1.1 is an enhanced status code, and the remaining text explains the rejection. Keep all three when asking for help.

The first digit provides a broad distinction: 4xx SMTP replies indicate a temporary failure, while 5xx replies indicate a permanent failure for that attempt. Enhanced codes use a dotted form: 4.x.x describes a transient condition and 5.x.x a failure unlikely to resolve by resending the email unchanged. RFC 5321 defines SMTP replies; RFC 3463 defines enhanced status codes.

“Permanent” does not necessarily mean the recipient address is invalid forever. A policy rejection can require a sender configuration change. Read the full diagnostic and the receiving provider's explanation of the exact code before choosing a fix.

Hard bounces and soft bounces

Email platforms use hard bounce for a permanent failure and soft bounce for a temporary one. The labels are shorthand for the SMTP reply class, and they decide what your sender should do next.

A soft bounce can turn into a final failure. A sending service queues a temporarily refused email and retries it; if the condition lasts until the service gives up, you receive a failure report for something that began as temporary. Check the final state rather than assuming “soft” means another attempt is still scheduled.

Do not build a resend rule around the word “bounce” alone. Keep the original event type and error details in your application's delivery record so you can tell an invalid address from a policy block or exhausted retries.

Common bounce codes and what to do

These are the replies you will meet most often. The text after the code varies by provider, so read it as well. RFC 3463 defines the enhanced status codes, and RFC 7372 adds the authentication ones.

Choose a fix from the reported cause

The address does not exist

If the response says the mailbox or user is unknown, compare the destination with the address the customer supplied. Check for spelling errors, copied spaces, and a mistyped domain. Ask the customer to confirm a correction through an existing contact path.

Stop sending to a confirmed invalid address. Avoid guessing replacements: a plausible spelling can belong to someone else, which matters especially for invoices and account links. Update the address only after confirming it, then send the email the customer still needs.

The recipient's mailbox is full or unavailable

Read whether the service is still retrying and whether the report describes a temporary condition or a final failure. A full mailbox may need the recipient to clear space or their administrator to adjust storage.

If the original attempt is still active, let the sending service finish its retry process. If it has ended, wait for evidence that the mailbox can receive email before considering a new send. For urgent account access, give the customer a way to correct their address or contact support.

The recipient domain cannot receive mail

Check the spelling of the domain after @. If multiple addresses at the same domain fail, ask its mail administrator to investigate the domain's mail routing and availability. Save the exact DNS or routing error for them.

A public DNS lookup can help reveal a routing problem, but it cannot confirm that an individual mailbox exists. Do not treat a successful domain lookup as validation of every address at that domain.

Authentication or sender policy caused a rejection

When the response names SPF, DKIM, DMARC, or a sender policy, investigate your sending configuration. Confirm the domain used in the actual send and follow the receiving provider's error guidance. Our email authentication guide explains the records and domain alignment to check.

For example, Gmail's SMTP error reference distinguishes authentication, rate, and policy errors. Use the precise response instead of applying one fix to every 550 rejection.

Correct the cause before resending. Changing the recipient address or moving the same traffic to another domain does not repair a broken authentication setup.

The message is too large or its contents are rejected

Look for an explicit size, attachment, or content restriction in the error. Reduce the relevant attachment or correct the rejected content, then verify the receiving system's limit. Avoid repeatedly resending the same payload.

For a large document, a secure download link may suit the customer better than an attachment. Preserve the access controls the document needs when making that change.

When should you retry a bounced email?

Retry only after checking both delivery state and the cause. Waiting can help a temporary outage; it will not correct a misspelled address or failed authentication.

Before creating another send, confirm:

1. The original delivery attempt has finished. Your application and sending service should not run competing retry loops.
2. The reported cause has cleared or the necessary correction has been verified.
3. The recipient is eligible to receive the email. Review any suppression or unsubscribe restriction rather than clearing it just to force a retry.
4. The email is still useful. An expired password-reset link needs a fresh customer-requested reset, not a replay of yesterday's email.

Keep the original failure and the new attempt linked in your support record. That makes it possible to see whether the correction worked without losing the evidence that prompted it.

How Samva handles bounces

Samva reads the receiving server's verdict for you and acts on it, so one dead address cannot keep costing you reputation.

• A hard bounce sends a signed message.bounced webhook. Its errorCode names the bounce kind, such as NoEmail. Samva suppresses the address permanently.
• A soft bounce that outlasts the delivery attempts arrives as message.failed with failureReason set to Transient. Samva suppresses the address for 30 days, so it can be tried again once the receiving server recovers. A soft bounce does not count toward the bounce rate that can pause sending.
• A send to a suppressed address is not attempted. It fails with the error code SUPPRESSED.
• A complaint works like a hard bounce: message.complained, and the address stays suppressed.

Subscribe to the bounce event and mark the address in your own records, so your app stops asking for email to it:

import { verifyRequest } from "samva/webhooks";

import { markUndeliverable } from "./contacts"; // your own storage

export async function POST(request: Request) {
  const verified = await verifyRequest(request, process.env.SAMVA_WEBHOOK_SECRET!);

  if (verified.event.type === "message.bounced") {
    const { toEmails = [], errorCode } = verified.event.data as {
      toEmails?: string[];
      errorCode?: string;
    };
    for (const address of toEmails) await markUndeliverable(address, errorCode);
  }

  return new Response(null, { status: 204 });
}

To see why an address is blocked, open Blocks in the dashboard or call List suppressed addresses. The suppression list article covers when removing an entry is safe, and the webhook events page lists every field above.

Investigate a sudden rise in bounces

Group failures by receiving domain, error response, and sending time. A cluster at one destination suggests a different investigation from invalid-address errors scattered through an old contact list.

Compare the affected sends with your recent changes: imported addresses, a new sender domain, larger attachments, or a jump in volume. Hold the affected batch while you inspect the pattern. The domain warmup guide explains how to increase volume based on observed delivery results.

In Samva, review delivery events alongside the recipient's suppression record when investigating a failure. A suppression can prevent a later send even after the original bounce has been recorded. The deliverability documentation covers those controls.

For an escalation, provide the message identifier, timestamp with timezone, affected recipient domain, and complete diagnostic through a private support channel. Those details give your email provider or the receiving administrator something concrete to investigate.