How to Troubleshoot Email Bounce Backs

Author: nathacof
Published: Sunday 12th of August 2007

Non-Delivery Reports

Bounce back emails, or Non-Delivery Reports, can be a large cause of concern for many businesses. In the event that a user receives a bounce back message they typically do not understand what this bounce back is indicating to them, and my guess is they will be asking you to interpret. In this tutorial I try and make clear how to troubleshoot and diagnose SMTP bounce back messages.

A bounce back message can be generated for a very large number of reasons. Therefore it is important that you familiarize yourself with SMTP status codes. Here's a useful link that goes to the trouble of providing a handy description of each status code and the meaning behind it. The most common status code I've seen recently is '421' service unavailable. The most common case for this is abuse of the mail server. Typically if you are being blocked or rate limited by a particular mail server you will get this message. Fortunately it's a temporary error so your mail server should reattempt delivery, but you'll want to ensure that you've read the documentation provided by the email provider to make sure you are following their guidelines when it comes to mail delivery.

Here are some useful links if you're getting a '421' bounce:

• Postmasters at AOL
• Postmasters at MSN/Hotmail
• Postmasters at Yahoo!

Sometimes the status code does not give a clear definition of the problem at hand. To gain a more detailed understanding of how your messages are being delivered we can investigate the SMTP headers of an email message to determine where it has been. More information on retrieving SMTP headers can be found here.

Lets look at a sample header:

Return-Path: 
Received: from compute1.internal (compute1.internal [10.202.2.41])
         by store21m.internal (Cyrus v2.3.9-fmsvn12891) with LMTPA;
         Tue, 09 Oct 2007 23:18:08 -0400
X-Sieve: CMU Sieve 2.3
X-Resolved-to: da_imac_daddy [at] mailforce.net
X-Delivered-to: da_imac_daddy [at] mailforce.net
X-Mail-from: slashdot@slashdot.org
Received: from mx3.messagingengine.com ([10.202.2.202])
  by compute1.internal (LMTPProxy); Tue, 09 Oct 2007 23:18:08 -0400
Received: from mail.osdn.net (sshgate.ostg.com [66.35.250.15])
        by mx3.messagingengine.com (Postfix) with ESMTP id 210831976AA
        for ; Tue,  9 Oct 2007 23:18:08 -0400 (EDT)
Received: from [10.2.37.201] (helo=slashdot-nfs-1.osdn.net)
        by mail.osdn.net with esmtp (Exim 4.41)
        id 1IfS5G-0004Uw-MP
        for da_imac_daddy [at] mailforce.net; Tue, 09 Oct 2007 20:18:06 -0700
Received: from localhost ([127.0.0.1] helo=slashdot.org)
        by slashdot-nfs-1.osdn.net with smtp (Exim 4.41)
        id 1IfS5G-0003Nk-J8
        for da_imac_daddy [at] mailforce.net; Tue, 09 Oct 2007 20:18:06 -0700
Date: Wed, 10 Oct 2007 03:18:06 +0000
From: slashdot@slashdot.org
Subject: [Slashdot] Headlines for 2007-10-10
To: da_imac_daddy@mailforce.net
Precedence: list
Content-transfer-encoding: 8bit
Content-type: text/plain; charset="us-ascii"
Message-Id: 
X-Bulkmail: 2.051

Headers are read from bottom up. The first IP listed is the server from which the mail has originated:

Received: from localhost ([127.0.0.1] helo=slashdot.org)
        by slashdot-nfs-1.osdn.net with smtp (Exim 4.41)
        id 1IfS5G-0003Nk-J8
        for da_imac_daddy@mailforce.net; Tue, 09 Oct 2007 20:18:06 -0700

We can see this message was sent from the host 'slashdot-nfs-1.osdn.net'. It's important to know where your emails are coming from, especially with all the new fangled SPF filtering and all.

If this all still seems like Greek to you try my email header analyzer.

Advanced

You want to know more don't you? I knew you would; you can find more information in the SMTP RFC.

From the article:

2yz Positive Completion reply
The requested action has been successfully completed. A new request may be initiated.

3yz Positive Intermediate reply
The command has been accepted, but the requested action is being held in abeyance, pending receipt of further information. The SMTP client should send another command specifying this information. This reply is used in command sequence groups (i.e., in DATA).

4yz Transient Negative Completion reply
The command was not accepted, and the requested action did not occur. However, the error condition is temporary, and the action may be requested again. The sender should return to the beginning of the command sequence (if any). It is difficult to assign a meaning to "transient" when two different sites (receiver- and sender-SMTP agents) must agree on the interpretation. Each reply in this category might have a different time value, but the SMTP client SHOULD try again. A rule of thumb to determine whether a reply fits into the 4yz or the 5yz category (see below) is that replies are 4yz if they can be successful if repeated without any change in command form or in properties of the sender or receiver (that is, the command is repeated identically and the receiver does not put up a new implementation).

5yz Permanent Negative Completion reply
The command was not accepted and the requested action did not occur. The SMTP client SHOULD NOT repeat the exact request (in the same sequence). Even some "permanent" error conditions can be corrected, so the human user may want to direct the SMTP client to reinitiate the command sequence by direct action at some point in the future (e.g., after the spelling has been changed, or the user has altered the account status)

Basically any 4xx type error is Temporary, and any 5xx type error is permanent. To further analyze the reply code you can analyze the second digit of the code:

The second digit encodes responses in specific categories:

x0z Syntax: These replies refer to syntax errors, syntactically correct commands that do not fit any functional category, and unimplemented or superfluous commands.

x1z Information: These are replies to requests for information, such as status or help.

x2z Connections: These are replies referring to the transmission channel.

x3z Unspecified

x4z Unspecified

x5z Mail system: These replies indicate the status of the receiver mail system vis-a-vis the requested transfer or other mail system action.

With this information you should be able to analyze any email bounce backs you may receive.