Reading a bounce

Module 6: Bounces and troubleshooting · Reading time: 11 minutes

Learning objective: After this lesson, you'll be able to analyse an error message about an undelivered email (a bounce): which server gave the error, for which address, what the code means, and whether it's temporary or permanent.

Key concepts: bounce, Mailer-Daemon, delivery status notification (DSN, RFC 3464), Reporting-MTA, Remote-MTA, Final-Recipient, Action (failed, delayed), Status, Diagnostic-Code, Will-Retry-Until, reply code (RFC 5321), extended status code X.Y.Z (RFC 3463), delay message, backscatter

What is a bounce?

If a mail server can't deliver an email, it sends a message back to the sender. This is called a bounce (or: non-delivery report, NDR). It comes from a sender such as Mailer-Daemon@..., MAILER-DAEMON or Mail Delivery System, with a subject like:

• Mail delivery failed: returning message to sender
• Undelivered Mail Returned to Sender
• Delivery Status Notification (Failure)
• Warning: message ... delayed 24 hours (this isn't a bounce but a delay message, see below)

Many people throw this kind of message away straight away, or are put off by the English text. That's a shame, because a bounce almost always tells you exactly what's wrong. You just need to know where to look.

A bounce always has an empty envelope sender (Return-Path: <>). This is deliberate: a bounce on a bounce could otherwise create an endless loop (RFC 5321).

Who rejected the mail?

An email passes through at least two servers: your provider's and the recipient's. A bounce can arise in two situations:

1. The receiving server rejects the mail during the SMTP conversation (lesson 1.2), for example after RCPT TO (address unknown) or after the content (spam or DMARC). Your own server receives that rejection and turns it into a bounce for you. The error comes from the recipient, the bounce from your own server.
2. Your own server gives up, for example because the recipient was unreachable for days, or because you've reached a limit of your own.

The distinction matters: in the first case, you need to know what the recipient didn't like, in the second case the problem is closer to home.

The readable part

At the top is a text meant for people. It varies by mail software, but almost always contains the same things:

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pieter.devries@example.net
    host mx1.example.net [198.51.100.20]
    SMTP error from remote mail server after RCPT TO:<pieter.devries@example.net>:
    550 5.1.1 <pieter.devries@example.net>: Recipient address rejected: User unknown

Read it like this:

The machine part: the DSN

Below the text there's usually a part meant for programs, the delivery status notification (RFC 3464). It's always structured the same way, which makes it easy to read:

Reporting-MTA: dns; mail.hosting.example

Action: failed
Final-Recipient: rfc822;pieter.devries@example.net
Status: 5.1.1
Remote-MTA: dns; mx1.example.net
Diagnostic-Code: smtp; 550 5.1.1 <pieter.devries@example.net>: Recipient address rejected: User unknown

Right at the bottom is the original email or just its header lines. There you can see which email it was, and which sender address and Return-Path were used. That's sometimes the key to the solution (see the DMARC case in the exercise).

Reading the codes

There are two kinds of codes, and usually both appear in a bounce.

The reply code (RFC 5321): three digits, such as 550 or 451. The first digit is the most important:

The extended status code (RFC 3463): three numbers separated by dots, such as 5.1.1 or 4.7.500. The first number is again 2, 4 or 5. The second number says where the problem lies:

The third number is the precise reason. Large recipients use their own numbers for this, such as Gmail with 5.7.25 to 5.7.30 and Microsoft with 4.7.500 and 5.7.509. These are listed in their own documentation (lesson 6.2).

Rule of thumb: a code starting with 5 and with a 7 in the middle (5.7.x) is almost always a policy matter: authentication, reputation or spam. Resending won't help there; something needs to change.

Delayed isn't the same as failed

With a temporary error (4xx), your server keeps the mail and tries again. RFC 5321 recommends keeping at it for at least four to five days, with at least half an hour between attempts. Many servers send a delay message after a few hours or a day:

Action: delayed
Status: 4.7.500
Diagnostic-Code: smtp; 451 4.7.500 Server busy. Please try again later from [203.0.113.25].
Will-Retry-Until: Thu, 12 Nov 2026 08:58:40 +0100

This means: don't resend, the server is still trying by itself. If you resend anyway, the recipient might end up getting it twice. If it still doesn't work before Will-Retry-Until, a real bounce will follow after all, often with 4.4.7 (message expired in the queue).

Fake bounces: backscatter

Suddenly getting dozens of bounces for mail you never sent? Check the original email at the bottom. If it shows a sender from your domain, but a server and text you don't recognise, a spammer has used your address as the sender. The recipients send their bounces to you. This is called backscatter.

Your mailbox usually hasn't been hacked in this case (see lesson 3.4 for the difference). What helps: a DMARC policy that gradually becomes stricter (lesson 4.4), so recipients reject forged mail before a bounce is even created. Do check your sent mail and with your provider to make sure nothing was really sent from your mailbox.

In practice: what it looks like

At WebOké, alongside the bounce you can also see in E-mail Tracking in DirectAdmin what the server did with a message: Delivered, Deferred or Fail, along with the receiving server's reply. Other panels often have a similar mail log or "message trace"; with Microsoft 365, for example, it's called message tracing. It's a good idea to check there first if you don't have a bounce, or if someone says your email didn't arrive.

Summary

• A bounce comes from Mailer-Daemon and has an empty Return-Path. Read it, it usually tells you exactly what's wrong.
• First check who gave the error (SMTP error from remote mail server = the recipient) and for which address.
• In the machine part: Action, Status, Remote-MTA and above all Diagnostic-Code.
• First digit: 4 = temporary, 5 = permanent. Second number: 1 address, 2 mailbox, 3 system, 4 routing, 5 protocol, 6 content, 7 policy.
• Delay message (delayed): don't resend. Bounces for mail you didn't send: backscatter.

Quiz

Exercise

Exercise Z6.1: Analysing three bounces. You'll be given three example bounces (bounce-1.txt, bounce-2.txt and bounce-3.txt). For each bounce, fill in: the address that failed, the server that gave the error (Remote-MTA), the status code, whether it's temporary or permanent, and what the sender should do (choose from a list). The programme checks your answers against a fixed key and gives an explanation for each field.

Further reading

The steps in these articles apply to WebOké's panels; with other providers it works in a similar way.

• Mail delivery failed: how to read the error message and what the codes mean
• Error message: 550 5.5.0 Requested action not taken: mailbox unavailable
• Checking whether an email has arrived with Email Tracking in DirectAdmin
• DirectAdmin guide 9.3: E-mail Tracking: where did my mail go?
• RFC 3464 (structure of a DSN), RFC 3463 (extended status codes), RFC 5321 section 4.2 (reply codes) and 4.5.4.1 (retrying)