Email Bounce Decoder

A hard bounce (5xx codes) is permanent — the email will never be delivered to that address. Common causes: the mailbox does not exist, the domain is invalid, or the address has been blocked. You should remove hard-bounced addresses from your list immediately. A soft bounce (4xx codes) is temporary — the receiving server is acknowledging the issue is transient and your mail server should retry. Common causes: full mailbox, server temporarily down, rate limiting. Most email systems retry soft bounces automatically for 24–72 hours before giving up.

An NDR — also called a bounce message, DSN (Delivery Status Notification), or "mailer-daemon" message — is an automated email sent back to the original sender when delivery fails. It contains a structured RFC 3464 message/delivery-status MIME part with machine-readable fields like Status: 5.1.1 and Diagnostic-Code: smtp; 550 5.1.1 …, as well as a human-readable explanation. This tool parses both formats.

Enhanced status codes (RFC 3463) have three parts: the class (2=success, 4=temporary failure, 5=permanent failure), the subject (1=addressing, 2=mailbox, 4=routing, 7=security/policy), and the detail (specific sub-condition). For example, 5.7.26 means: permanent failure (5), security/policy issue (7), DMARC violation (26). These codes are standardised across mail servers, making them more reliable than the free-text portion of the bounce message.

Several things can cause this: (1) The account existed but was deleted or deactivated. (2) Your sending IP or domain is on a blocklist — check with our Blacklist Checker. (3) Your SPF, DKIM, or DMARC authentication failed — check with our Domain Checker. (4) The recipient server is rate-limiting you (try again after a delay). (5) Your email content triggered a spam filter.

Remove them from your list immediately and permanently. Continuing to send to invalid addresses hurts your sender reputation with every major email provider. If you use an email marketing platform, it should suppress hard bounces automatically. If you manage your own sending, maintain a suppression list and never retry addresses that returned a 5.1.1 or 5.1.0 code. For DMARC/authentication bounces (5.7.26, 5.7.23), fix the underlying configuration issue first — these are not caused by bad addresses.

A 5.7.26 bounce means the receiving server's DMARC policy (p=reject) blocked your email because neither SPF nor DKIM passed with domain alignment. Common causes: (1) Sending through a third-party service that signs DKIM under their domain, not yours. (2) SPF passes but the envelope sender domain doesn't align with your From: header. (3) No DKIM signature at all. To fix this: configure your sending service to sign DKIM with your domain (aligned DKIM), and ensure your SPF record includes all sending IPs. Use our Domain Checker to verify alignment.