Free private diagnostic tool

Email Bounce Error Decoder

Paste an email delivery failure notice or SMTP code. Understand what was reported, why it matters and what to check next. Analysis stays in your browser.

Decode a bounce notice

Paste the relevant text from a delivery failure notification, or just a code such as 550 5.1.1. Structured reports may describe multiple recipients. Limit: 100,000 characters and 30 structured recipients per analysis.

Private by design: Analysis happens locally in browser memory, without sending the text to our server, DNS Worker or an AI service. This tool does not store the input. Notices may contain private addresses, message details or server identifiers.

Try a fictional example: These samples contain no real recipient details.

How to read SMTP bounce error codes

A basic SMTP reply such as 550 describes the server's reply class. An enhanced status code such as 5.7.1 provides additional context. A provider's diagnostic text can be more important than the code itself. A permanent rejection does not automatically mean the recipient address is invalid.

Common bounce examples

  • 550 5.1.1 commonly reports a bad destination mailbox address. Confirm the address before trying again.
  • 552 5.2.2 commonly reports that a mailbox is full. The recipient or administrator may need to resolve storage limits.
  • 550 5.7.26 reports authentication trouble. Examine provider wording before attributing the problem to a specific check.
  • 451 4.7.0 is a temporary reply that may reflect provider policy or rate limiting. Check the full reason and retry state.
  • 550 5.4.1 in Microsoft 365 can describe recipient blocking or relay problems depending on the detailed error text.

What should I do with a decoded result?

Keep the original notice in your email system and compare its information with the sending service's delivery logs. If the response names SPF, DKIM, DMARC or DNS, investigate the actual sending route instead of changing DNS records blindly. If the problem appears to concern a recipient, verify the intended address. Avoid repeated manual resends when the provider is already retrying a temporary error.

Public technical references

We use RFC 3464, the IANA enhanced-status registry, Gmail's SMTP error reference and Microsoft's Exchange Online NDR guidance. Providers can reuse codes or change wording. The decoder reports uncertainty instead of guessing.