Examining Bounce Reclassification for Optimized Delivery | Port25 Solutions, Inc.
Fred Tabsharani

By port25admin

Examining Bounce Reclassification for Optimized Delivery

While most (or all) mature ESPs in the industry practice bounce reclassification, I don’t think it’s used often enough and I hope to help delivery professionals understand its importance for successful sends.  Bounce strings/logs are the key to understanding what is really going on with your deliverability and paying close attention to them will go a long way in your success.  A close colleague told me, “If there’s any one maintenance item that should be a recurring task, that’s probably it.”

Most of us know that it’s critical that any sender take action on bounces (especially hard bounces) by extracting the addresses from your database.  In this example, however our client, Dynunderscores the importance of actively listening to your feedback loops and understanding that not “all” 5.x.x bounces should be extracted.  For instance, a gateway  related 5.x.x bounce error might not get extracted from the database, but if the error is a 5.x.x which is recipient based, than the removal may be warranted.

Dyn has a global suppression list that is unique by customer and that accounts for all bounced, complaints and unsubscribed recipients. Because they take such quick action on bounces as all demanding senders really should, it’s important they absolutely have the most recent and accurate data.  Thus, by reclassifying a hard bounce and analyzing the diagnostic code, their system removes the need for unwarranted extractions.

Here are examples and applicable guidelines that you may apply in different layers within your sending environment:

  • A hard bounce that should be soft
  • A soft bounce that should be hard
  • A soft bounce where the recipient should eventually be suppressed
  • A soft bounce where the recipient should never be suppressed

Below are some examples that are similar to what you might find in your log files:

Example 1:

  • Final-Recipient: rfc822;xxxxxx@darkuncle.com
  • Action: failed
  • Status: 5.0.0 (undefined status)
  • Remote-MTA: dns;darkuncle.com
  • Diagnostic-Code: smtp; 550 Mailbox quota exceeded
  • X-PowerMTA-BounceCategory: quota-issues

In Example 1, you’ll notice the ISP explanation within the bounce message.  The “true” meaning of these bounces does not indicate that these bounces should never be mailed again, which a 5.X.X, being a hard bounce, usually represents. Further in this example, smtp; 550 5.7.1 “Mailbox quota exceeded” should mean that you could try again later.  If you encounter it often enough, perhaps the recipient has become inactive and doesn’t use this email address anymore.  Again, these are assumptions and your internal policies might suggest otherwise. This is why I think still think the major ISPs should put extra effort into comprehensively classifying bounces and recognizing that the current inefficiencies hinder legitimate deliverability practices for the current “bounce category” ecosystem.

Example 2:

In example 2, smtp 550 5.7.1 <xxxxxxx@grandecom.net>… Denied by Grande Block List.  Being on the blocklist has nothing to do with the unique recipient looking to receive this message, so after being delisted from the block list, you could try to send to this recipient again.  Again, a 5.x.x here does not mean you have to extract the subscriber from your list.  As cited in the first paragraph, the devil is in the details and better reclassification of these types of bounces will mitigate true bounces and optimize deliverability.

Example 3:
  • Final-Recipient: rfc822;XXXXXX@jameshotels.com
  • Action: failed
  • Status: 5.7.1 (delivery not authorized)
  • Remote-MTA: dns;mailserv1.jameshotels.com
  • Diagnostic-Code: smtp;550 5.7.1 E-mail too large to accept by mail system
  • X-PowerMTA-BounceCategory: policy-related

Finally in example 3, the diagnostic code smtp; 550 5.7.1,  “email is too large to accept by mail system”  X-PowerMTA BounceCategory: policy-related.   Once again, having an email that is too large has nothing to do with the recipient. This is a perfect example of a subscriber that should not be placed on a suppression list. PowerMTA has almost 20 different built-in ISP diagnostic feedback codes that delivery professionals can run internal policies against.  This tool is merely one way to optimize delivery.

This blog post was inspired by our friends at Dyn, who opted to share their exceptional delivery expertise with us. We hope these tactics will help you become a better sender.

9160 Guilford Rd // Columbia, MD 21046 // (410) 750-SMTP