An email bounces when delivery fails and the sending system receives a failure report. The report might arrive in your inbox as an “undeliverable” notice or appear in your email platform's delivery events. To fix it, read the reason for the failed delivery before sending 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:
| 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 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 unknownHere, 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 commonly use hard bounce for a permanent failure and soft bounce for a temporary delivery problem. The labels are useful shorthand, but your next action depends on the underlying reason and whether delivery attempts have ended.
A temporary deferral can remain in the sending service's queue while it retries. If the problem persists until that service gives up, you can receive a final failure report for a condition that was initially temporary. Check the final state rather than assuming “soft” means another attempt is already 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 distinguish an invalid address from a policy block or exhausted retries.
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:
- The original delivery attempt has finished. Your application and sending service should not run competing retry loops.
- The reported cause has cleared or the necessary correction has been verified.
- The recipient is eligible to receive the email. Review any suppression or unsubscribe restriction rather than clearing it just to force a retry.
- 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.
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.
