# Email bounce back: hard bounce or soft bounce URL: https://samva.dev/blog/email-bounce-back > A hard bounce is permanent and a soft bounce is temporary. Read the SMTP code, stop sending to dead addresses, and see how Samva suppresses them. - Published: 2026-09-08 - Author: [Saatvik Arya](https://samva.dev/authors/saatvik-arya) 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 [#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: | What you can verify | What to investigate | | ------------------------------------------------------------------------- | -------------------------------------------------------------- | | The send request itself was rejected | The API error, credentials, sender setup, or request contents | | Delivery is delayed and retries are still active | The temporary response and your sending service's retry policy | | Delivery ended in a bounce or failure | The final error and affected recipient | | The receiving server accepted the email, but the recipient cannot find it | Spam, quarantine, mailbox rules, or forwarding | A message in the [spam folder](/blog/emails-going-to-spam) 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 [#read-the-code-and-the-explanation-together] An illustrative response might look like this: ```text 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](https://www.rfc-editor.org/rfc/rfc5321#section-4.2.1) defines SMTP replies; [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463#section-2) 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 [#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. | | Hard bounce | Soft bounce | | -------------- | ----------------------------------------------------------------------- | ------------------------------------------------------- | | SMTP reply | `5xx`, with a `5.x.x` status | `4xx`, with a `4.x.x` status | | What it means | The server will not accept this email as sent | The server could not take it right now | | Typical causes | Unknown address, nonexistent domain, authentication or policy rejection | Full mailbox, server outage, rate limiting, greylisting | | What to do | Fix the cause or the address; do not resend the same email unchanged | Let the sender retry; stop only if retries run out | | Address status | Stop emailing it until it is corrected | Safe to try again later | 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 [#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](https://www.rfc-editor.org/rfc/rfc3463) defines the enhanced status codes, and [RFC 7372](https://www.rfc-editor.org/rfc/rfc7372) adds the authentication ones. | Reply | Meaning | Type | What to do | | ----------------------------------- | -------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------ | | `550 5.1.1` | The mailbox does not exist | Hard | Check the spelling, confirm the address with the customer, and stop sending to the old one | | `550 5.1.2` | The recipient's domain cannot be found | Hard | Check the part after `@`, then the domain's mail records | | `552 5.2.2` or `452 4.2.2` | The mailbox is over quota | Servers differ | Wait while the sender retries; tell the customer if it is urgent | | `552 5.3.4` | The message is too large | Hard | Shrink the attachment or send a download link | | `550 5.7.1` | The server refused the message on policy or reputation grounds | Hard | Read the full text; check blocklists, content, and authentication | | `550 5.7.26` | The message failed SPF or DKIM checks, or carries no authentication | Hard | Fix the sending domain's records before resending | | `421`, `450`, or `451` with `4.x.x` | The server is deferring the email: rate limiting, greylisting, or a brief outage | Soft | Do nothing for now; slow down if it repeats | ## Choose a fix from the reported cause [#choose-a-fix-from-the-reported-cause] ### The address does not exist [#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 [#the-recipients-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 [#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 [#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](/guides/email-authentication) explains the records and domain alignment to check. For example, [Gmail's SMTP error reference](https://support.google.com/mail/answer/3726730?hl=en) 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 [#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? [#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 [#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: ```ts title="webhooks/samva.ts" 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](/docs/api-reference/email/listSuppressions). The [suppression list article](/blog/what-is-an-email-suppression-list) covers when removing an entry is safe, and the [webhook events](/docs/platform/webhook-events) page lists every field above. ## Investigate a sudden rise in bounces [#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](/blog/warm-up-a-new-sending-domain) 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](/docs/channels/email/deliverability) 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.