How do I troubleshoot email bounce messages?
Published 2 Jun 2025
Updated 9 Aug 2026
11 min read
Summarize with
Updated on 9 Aug 2026: We added a clearer path for decoding NDRs and isolating authentication, message-size, content, and routing failures.
Troubleshoot email bounce messages by saving the full non-delivery report (NDR), also called a delivery status notification (DSN) or bounceback message, reading the SMTP reply code, identifying the server that rejected the message, and then testing the recipient, DNS, authentication, and reputation path one at a time. Send a fresh message through the email tester after saving the bounce text, because a live sample confirms what the receiving system actually saw.
A common mistake is treating a bounce as a generic delivery failure. It is not generic. A useful bounce has a status code, a remote mail server, a diagnostic line, and often a provider-specific reason. Those fields tell you whether the fix belongs in the mailing list, DNS, SPF, DKIM, DMARC, sending IP reputation, content, or retry timing.
- Keep the complete NDR or bounceback text, including headers, remote server lines, timestamps, and the diagnostic code.
- Check whether one address, one mailbox provider, or all recipients are affected.
- Compare the bounce against DNS, authentication, sender reputation, and recent sending changes.
- Make one fix, send a clean test, and only then change the next variable.
Start with the complete bounce message
The full bounce message is the starting point. A screenshot of the subject line or a rewritten error is rarely enough. Keep the original delivery status notification, because the useful line is often buried under several human-readable explanations.
Look for the final recipient, action, status, remote MTA, and diagnostic code. The diagnostic code is usually the most useful line because it contains the SMTP reply returned by the receiving mail server. In a wrapped NDR, the administrator or diagnostic section can preserve the original remote response even when the user-facing explanation is generic.
Useful bounce fieldstext
Reporting-MTA: dns; mail.sender.example Final-Recipient: rfc822; user@example.net Action: failed Status: 5.7.26 Remote-MTA: dns; gmail-smtp-in.l.google.com Diagnostic-Code: smtp; 550 5.7.26 unauthenticated mail
Do not over-redact the evidence
Remove personal message content if needed, but keep the technical fields intact. The domain, recipient domain, remote server, SMTP status, and diagnostic line are the evidence needed to diagnose the failure.
- Keep the status, diagnostic code, remote MTA, timestamps, and message ID.
- Remove private message body content or personal notes that do not affect routing.
- Preserve the exact wording from the receiving server, including provider hints.
If the bounce is unavailable, recreate the failure with a controlled test. Use the same sender domain, sending platform, envelope sender path, and recipient provider where possible. Changing the sender or platform too early creates a different test and hides the original problem.
Separate hard bounces from soft bounces
The first decision is whether the receiving system rejected the message permanently or temporarily. An SMTP 5yz reply means permanent failure for that delivery attempt, while a 4yz reply asks the sending system to retry. The enhanced status code and surrounding text still matter because some providers use broad or inconsistent codes for mailbox and policy conditions. Do not keep retrying a 5yz reply simply because its text says the mailbox is full.
|
|
|
|---|---|---|
5.1.1 | Bad address | List hygiene |
5.2.2 | Mailbox full | Provider text |
4.4.1 | Network issue | Queue and route |
5.7.1 | Policy block | Auth and IP |
5.7.26 | Auth fail | SPF and DKIM |
554 | Rejected | Policy text |
Common bounce code patterns and first checks.
For deeper code reading, keep a separate reference for bounce error codes. When a 4xx failure repeats for hours or days, treat it as a delivery issue, not just a temporary delay, and work through the soft bounces path with the same discipline.
Bounce urgency by pattern
Use the pattern, not only the first digit, to decide the next action.
Single 4xx
Watch
A short retry delay is normal.
Repeated 4xx
Investigate
A repeated temporary failure needs investigation.
5xx policy
Fix
Authentication, content, reputation, or routing needs review.
5.1.1
Clean
Suppress or verify the recipient address.
Hard bounces should not all be handled the same way. A dead mailbox needs suppression. A 5.7.1 policy block needs authentication and reputation checks. A 554 with a blocklist (blacklist) hint needs sender reputation evidence. A message-size rejection needs a smaller message. The code narrows the search, but the diagnostic text points to the fix.
Decode the SMTP reply
Flowchart showing a bounce troubleshooting path from full bounce text to retesting.
Read the bounce from the technical fields first, then the human text. The receiving server is the authority for why it refused the message. Intermediate systems can add confusing wording, especially when another application or sending platform wraps the original SMTP response.
The remote MTA tells you who made the decision. If the rejecting server belongs to the recipient provider, the sender has to satisfy that provider's policy. If the rejection happens inside your own outbound system, the issue can be local routing, account limits, malformed headers, or an invalid recipient before the message ever reaches the internet.
Evidence to trust first
- The remote MTA shows the system that refused the message.
- The SMTP status separates permanent failures from retryable failures.
- The diagnostic line often names authentication, policy, recipient, or routing causes.
Signals to treat carefully
- The subject line usually hides the exact SMTP reason.
- A user summary can paraphrase the error and lose the useful detail.
- An old sample can point to a problem that has already changed.
Triage note formattext
Provider: Gmail SMTP: 550 5.7.26 Remote MTA: gmail-smtp-in.l.google.com Scope: marketing stream only Next check: SPF and DKIM on the same sample
Keep triage notes short and factual. Provider, SMTP reply, remote MTA, scope, and next check are enough to prevent random fixes. If several teams touch email, this format also makes handoffs cleaner because everyone sees the same evidence.
Check authentication and domain setup
When the bounce mentions authentication, policy, unauthenticated mail, SPF, DKIM, DMARC, sender identity, or suspicious mail, move from the bounce text to domain checks. A domain health check gives you a fast view of DNS and authentication problems, while DMARC monitoring shows whether real mail streams are passing or failing over time.
The important detail is that the test has to match the bounced stream. A domain can pass SPF for one platform and fail for another. DKIM can pass for a newsletter system and fail for a support desk. DMARC can pass through aligned DKIM even when SPF fails. Diagnose the stream that produced the bounce.
DNS records to verifydns
example.com. TXT "v=spf1 include:_spf.sender.example -all" selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIB..." _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
Authentication evidence to collect
- Confirm the envelope sender belongs to the domain and platform you are testing.
- Check whether SPF authorizes the sending IP without exceeding its DNS lookup limit.
- Confirm the DKIM selector exists and the signature validates on the received message.
- Confirm at least one authenticated identifier passes DMARC alignment with the visible From domain.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's product helps here because it connects the bounce workflow to DMARC, SPF, DKIM, rDNS, and DNS diagnostics in one place. That matters when a bounce says only "policy" but the cause is a missing DKIM selector, an SPF include that no longer authorizes the sender, or a DMARC policy that is stricter than the sending setup can support.
When reputation or policy causes the bounce
If authentication passes and the recipient address is valid, look for reputation and policy signals. These bounces often use wording such as blocked, refused, rejected, suspicious, temporarily deferred, or poor sender reputation. This is where blocklist monitoring becomes useful, because a blacklist listing can explain why unrelated recipient domains start rejecting the same IP or domain.
|
|
|
|---|---|---|
Bad address | 5.1.1 | Suppress |
Auth failure | 5.7.26 | Fix DNS |
Rate limit | 4xx deferral | Slow sending |
Blacklist | Listed IP | Remediate |
Content | URL reject | Revise |
Policy and reputation causes that often look similar.
Do not request removal before fixing the cause
If a blocklist or blacklist listing is involved, fix the sending behavior first. Removal requests fail or relapse when the same spam complaints, invalid recipients, compromised traffic, or authentication gaps continue.
- Check volume for sudden sending spikes or new automated mail sources.
- Suppress confirmed invalid addresses and review stale or unengaged contacts against your consent policy.
- Separate different mail streams when possible, especially transactional and marketing mail.
Policy bounces also cluster by provider. If one provider rejects and others accept, compare that provider's wording against recent authentication results and engagement patterns. If many unrelated domains reject at once, reputation, DNS, routing, or a shared infrastructure issue is more likely. Track bounce rate by recipient provider and mail stream, because one blended rate can hide a concentrated failure.
Check message size, content, and routing
If the bounce follows one message rather than every message in the stream, isolate message size, attachments, content, formatting, and routing. Large files can exceed the recipient's limit after transfer encoding increases the message size. Nested attachments, blocked file types, malformed content, or a URL policy can also trigger a permanent rejection even when authentication passes.
|
|
|
|---|---|---|
5.2.3 or 5.3.4 | Message too large | Reduce total size |
5.6.x or named attachment | Format or file policy | Remove named element |
5.4.6 or 5.4.14 | Routing or forwarding loop | Check mail-flow rules |
4.4.x or 5.4.4 | Destination DNS or MX | Verify domain and MX |
Message and routing signals that need separate checks.
Run a plain-message isolation test
Send a short plain-text message through the same sender and route to the same recipient provider. If it succeeds, add the original elements back one at a time until the rejection returns.
- Start without attachments, embedded files, complex HTML, or a long signature.
- Keep the sender domain, envelope path, platform, and recipient provider unchanged.
- Add one link, attachment, or formatting change per test.
- Ask the recipient administrator to inspect destination MX, forwarding rules, inbound policy, and mail-loop history when the evidence points to their system.
A forwarding address can accept the message at the first mailbox and fail at the final destination, so the NDR can name a server or policy you did not expect. Use the message hops and final recipient fields to trace that path. If the destination domain has missing or broken MX records, only the recipient domain owner can correct them.
Use a repeatable troubleshooting workflow
A repeatable workflow keeps bounce troubleshooting from turning into guesswork. Use the same sequence each time: collect the bounce, classify the failure, identify the rejecting system, verify DNS and authentication, check reputation or message-specific causes, apply one fix, then retest.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A controlled test is useful after each fix because it gives you fresh headers and fresh authentication results. It also prevents a common false conclusion: assuming a fix worked because retries stopped, when the recipient system simply stopped retrying an old message.
- Save the full bounce and the original sending context.
- Classify the failure as hard, soft, recipient, policy, authentication, reputation, content, or routing related.
- Compare patterns for one recipient, one provider, and all providers.
- Check DNS and sender reputation evidence, including SPF, DKIM, and DMARC results.
- Apply one fix at a time and record exactly what changed.
- Send a fresh message and compare the new result with the old bounce.
One-off bounce
A single failed recipient usually starts with address validity, mailbox status, and provider-specific policy wording.
- Suppress confirmed invalid addresses.
- Let the sending system retry a 4.2.2 mailbox-full reply, but do not manually retry a 5yz response.
Campaign-wide bounce
A broad failure across many recipients points to authentication, DNS, reputation, routing, or sending behavior.
- Pause the affected stream while you verify the cause.
- Send plain, low-volume samples after each fix.
Changing several things at once makes the result hard to trust. If you rotate IPs, edit SPF, change content, and suppress recipients in the same hour, you will not know which action affected the next bounce. A slower method produces clearer evidence and fewer repeat incidents.
Views from the trenches
Best practices
Keep the full bounce text intact, including enhanced status codes and remote server lines.
Confirm whether one recipient, one provider, or every destination has the same failure.
Retest with a plain message after each DNS, list hygiene, or reputation fix is applied.
Common pitfalls
Reading only the subject line hides the SMTP code and the server that refused the mail.
Treating every 550 as a dead address misses policy, authentication, and content blocks.
Enforcing DMARC before legitimate streams pass alignment can cause avoidable rejections.
Expert tips
Save bounce samples by provider so repeated Microsoft, Gmail, and Apple patterns emerge.
Use DMARC reports to confirm whether the bounced stream authenticated before delivery.
Check blocklist and blacklist status when many unrelated domains reject the same IP.
Marketer from Email Geeks says the full, unedited bounce message is required before anyone can diagnose the failure with confidence.
2024-01-09 - Email Geeks
Marketer from Email Geeks says missing bounce details force people to guess, which leads to unnecessary DNS and sender changes.
2024-01-10 - Email Geeks
Confirm the fix and prevent repeat bounces
A bounce is solved when the next controlled test succeeds and the same failure pattern stops appearing in live mail. Do not treat a DNS edit, blacklist removal request, recipient suppression, or routing change as the end of the work until a fresh message proves the result.
Suped's product supports the authentication part of this workflow by connecting DMARC monitoring and DNS diagnostics with issue alerts. After you identify the bounced mail stream, use Suped to compare SPF and DKIM authentication with the resulting DMARC status, then track the result after a DNS fix. Recipient typos, mailbox quotas, attachment limits, and destination routing still need separate checks.
- Small teams can use Suped to see authentication failures without reading raw XML reports.
- Larger teams can use alerts and issue steps to route fixes to the right owner.
- MSPs can use multi-tenancy to separate client domains while keeping one operating view.
