When one mail server hands a message to another, the two talk in a simple protocol called SMTP (Simple Mail Transfer Protocol, RFC 5321). The receiving server answers every step with a reply code. If it cannot or will not take the message, the sender gets a bounce: either a refusal during the conversation, or a bounce message in the sender's inbox a little later. This exercise teaches you to read those codes and to decide what to do next. Read the reference first; it has everything you need.
Reference: three kinds of bounce
Hard bounce: a permanent failure. The address or the domain does not exist, or the mailbox was closed. Sending again will not help, so the address comes off the list.
Soft bounce: a temporary failure. The mailbox is full, the server is busy or asks you to come back later. The sending server tries again by itself, often for hours or a few days.
Block or policy bounce: the receiving server refuses because of who sends or what is sent: authentication failed, the sender has a bad reputation or is on a blocklist, the content looked like spam. The address may be perfectly fine. The problem is on the sender's side.
Reference: reading a reply
Take this reply from a receiving server:
550 5.1.1 <anna.berger@northwind.example>: Recipient address rejected: User unknownIt has three parts.
The basic reply code,
550(RFC 5321). The first digit is what counts most.The enhanced status code,
5.1.1(RFC 3463). It has the form class.subject.detail and says more precisely what went wrong.The text. The receiving server's administrators write it, so it differs from server to server. Read it, but software relies on the codes.
First digit of the basic code | Meaning |
|---|---|
2 | Success: the step worked, for example 250 |
3 | Go on: the server waits for more, for example 354 "start mail input" before the message text |
4 | Temporary failure: try again later |
5 | Permanent failure: do not send this again unchanged |
The enhanced code starts with a class (2 success, 4 temporary failure, 5 permanent failure). The middle number is the subject:
Subject | What the problem is about |
|---|---|
X.1.X | The address (the mailbox name, the domain, its spelling) |
X.2.X | The mailbox (full, disabled) |
X.3.X | The receiving mail system (too busy, message too big for it) |
X.4.X | The network and routing (no answer, cannot route) |
X.5.X | The SMTP conversation itself |
X.6.X | The message content or format |
X.7.X | Security or policy (refused, authentication failed) |
The full list of codes is kept in the IANA registry of enhanced status codes. Later standards added codes such as 5.7.26, "multiple authentication checks failed" (RFC 7372).
The tasks
Teacher notes
How to run it (25 minutes). Five minutes to read the reference together; put the example reply on the board and label its three parts. Fifteen minutes for the four tasks, alone or in pairs. Five minutes to discuss the third task, because it is the one that matters most in practice.
Common mistakes.
Treating every bounce as a bad address. Codes in the 5.7.X group usually point at the sender: missing SPF or DKIM, a DMARC policy, a blocklist or a bad reputation. Deleting good addresses does not fix that.
Reading only the first digit. 550 is used both for "user unknown" and for policy refusals; the enhanced code tells them apart.
Thinking a soft bounce is harmless. A rate limit (421 4.7.0 "slow down") is temporary, but it is also a warning that the receiving side does not trust the volume.
Expecting identical texts. The same code comes with very different wording from different servers.
Notes on the answers.
Greylisting codes vary in practice: servers use 450 or 451 with 4.7.0, 4.7.1 or others.
5.3.4 and 5.2.3 are permanent for this message, but the address is fine. Sending a link instead of a large attachment solves it.
An obvious typo such as a doubled @ can be corrected if you know the right address; never guess a new address and send to it.
Follow-up questions.
Why might a receiving server accept a message during the SMTP conversation and still send a bounce later? (It accepts first and checks the mailbox or content afterwards, for example behind a gateway.)
What should a bounce policy for a sales team say? (Remove hard bounces at once, count soft bounces per address and stop after a set number, investigate 5.7.X bounces before the next send.)
Look at the guide to email verification: why can a checker not always predict a 5.1.1?