大规模的投递邮件是一件困难的事情，妥善处理弹回邮件同样具有挑战性，一个准确的邮件弹回处理，能够更有效的管理邮件列表，减少错误地址和无效地址。著名的两种分类是“硬弹”和“软弹”，其中许多人使用不同的定义，这是一个模糊的，泛化的概念。所有邮件服务器当它遇到一个开始为’4XX’代码，表明临时故障的错误时，都会重试投递。电子邮件弹回时，它已经试了很多次，所以并没有什么业务流程上的“软”弹回。所谓的“硬弹”和“软弹”，更多是从逻辑上来描述，硬弹回一般是指邮件地址不存在或者无效，不需要再进行投递，软弹回则更多的是一些临时性或未知的错误，下次可以再尝试投递。
为了解析和分类不同的弹回邮件消息格式，是一项复杂的任务。您可能会遇到什么呢，下面是一些反弹的例子：
421 4.7.1 Intrusion prevention active for [X.X.X.X]
451 qq read error (#4.3.0)
452 Message for would exceed mailbox quota
530 Authentication required
550 5.1.1 Not our Customer
550 Mailbox unavailable or access denied –
550 Administrative prohibition
550 Envelope blocked – User Entry
550 no such address here
550 5.7.1 e-mail address access denied
550 not valid
550 failed_address_router router forced verify failure
553 sorry, that domain isn’t in my list of allowed rcpthosts (#5.7.1)
554 5.7.1 UBE Not Welcome Here!
554 5.3.0 rewrite: map parse not found
为了以正确的方式处理邮件弹回，首先需要进行分类处理，分类后，我们可以应用弹回规则来处理这些邮件地址。 一个很好的规则对于无效的电子邮件地址，能够立即停用，并排除再次发送邮件。其他类型的弹回，如果是明确的原因，则应该尽快移除。如果是检测和垃圾邮件相关的弹回，则需要来自该发件人的行动来解决这些问题。
如果你认为反弹的三位数代码，可用于分类，那你就错了。即使在增强的RFC3463规范中描述的状态码，往往也是含糊不清的或被误用。此外，在其他的RFC规范中所描述的通常也是状态分类，而不是邮件列表管理的角度真正有用的分类。例如，5.7.1 “relay access denied” 可能不是真的是一个安全问题，而往往是一个无效的电子邮件域名解析造成的。
那么，什么是一个很好的分类呢？ 我们思考了很长一段时间，并分析许多弹回，得出了以下规则：
收件人相关
用户未知
邮箱无效
超出配额
域名相关
无效域
无邮件主机
中继/访问被拒绝
垃圾邮件相关
发件人受阻
内容受阻
政策问题
系统相关
系统问题
协议问题
连接问题
有了这四个主要类别，我们就更清楚问题的根源。同时，通过使用子分类，可以让你的弹回规则从严或放松。例如改变邮箱无效或超出配额的反弹回处理行为。我们的邮件营销平台在积累大量的弹回分析经验之后，使用一些巧妙的文本模式匹配，能够有效解析和分类成千上万的邮件弹回到上述类别。但是，有些甚至大型ISP将弹回消息描述混淆到一些简单的描述，如“未知的错误”，“不可路由的地址”，“没有这样的定义”等，这使得无需频繁适应新遇到的反馈消息，自动分类反弹，几乎不可能。试问这些ISP是希望发件人正确地维护自己的数据库吗？