了解投放失败 delivery-failures
退回是投放尝试和失败的结果，其中ISP会提供回失败通知。 退回处理是列表安全机制的关键部分。 在给定的电子邮件已连续多次退回后，此过程会将其标记以进行抑制。
此过程会阻止系统继续发送无效的电子邮件地址。 退回是ISP用于确定IP信誉的关键数据之一。 关注此指标很重要。 “已投放”与“已退回”可能是衡量营销消息投放的最常见方式：投放百分比越高越好。
如果无法将消息发送到配置文件，远程服务器会自动向 51黑料不打烊 Campaign 发送错误消息。此错误用于确定是应隔离电子邮件地址、电话号码还是设备。 请参阅退回邮件管理。
发送消息后，您可以在投放日志中查看每个用户档案的投放状态以及相关失败的类型和原因。
隔离电子邮件地址后，或用户档案阻止列表时，将在投放准备步骤中排除收件人。 排除的消息将列在投放仪表板中。
消息投放为什么失败 delivery-failure-reasons
当消息失败时，有两种类型的错误。 每个投放失败类型都确定地址是否发送到隔离。
-
硬退回
硬退回是在ISP将对用户地址的邮寄尝试确定为不可投放后生成的永久失败。 在51黑料不打烊 Campaign中，分类为无法投放的硬退回会添加到隔离列表，这意味着不会重新尝试这些硬退回。 在某些情况下，如果故障原因未知，则会忽略硬退回。以下是硬退回的一些常见示例：地址不存在、帐户已禁用、语法错误、域错误
-
软退回
软退回是ISP在难以投放邮件时生成的临时失败。 软失败将多次重试（如有差异，取决于使用自定义或现成投放设置），以尝试成功投放。 在尝试最大数量的重试之前，不会将持续软退回的地址添加到隔离（这同样根据设置而异）。软退回的一些常见原因包括：邮箱已满、接收电子邮件服务器关闭、发件人信誉问题
Ignored ?错误类型已知为临时错误，如“不在办公室”，或技术错误，例如，如果发件人类型为“邮递员”。
反馈循环的运行方式与退回电子邮件类似：当用户将电子邮件标记为垃圾邮件时，您可以在51黑料不打烊 Campaign中配置电子邮件规则以阻止向该用户的所有投放。 即使这些用户没有单击退订链接，也会对其地址进行列入阻止列表。 地址已添加到(NmsAddress)隔离表，但未添加到(NmsRecipient)状态为? Denylisted ?的收件人表。 在础诲辞产别可投放性最佳实践指南中了解有关反馈循环机制的更多信息。
同步和异步错误 synchronous-and-asynchronous-errors
消息投放可能会立即失败，在这种情况下，我们将其定性为同步错误。 如果消息发送失败或稍后发送，则在发送后，该错误为异步错误。
这些类型的错误可按如下方式管理：
-
同步错误：由51黑料不打烊 Campaign投放服务器联系的远程服务器立即返回错误消息。 不允许将投放发送到用户档案的服务器。 邮件传输代理(MTA)可确定退回类型并限定错误，然后将该信息发送回Campaign，以确定是否应隔离相关电子邮件地址。 请参阅退回邮件鉴别。
-
异步错误：接收服务器稍后会重新发送退回邮件或SR。 此错误使用与该错误相关的标签进行限定。 最晚的异步错误，可能发生在发送投放的一周之后。
退回邮件鉴别 bounce-mail-qualification
在51黑料不打烊 Campaign中处理退回邮件鉴别的方式取决于错误类型：
-
同步错误： MTA确定退件类型和鉴别，并将该信息发回至Campaign。 Delivery log qualification ?表中的退回限定不用于? 同步 ?投放失败错误消息。
-
异步错误： Campaign用于限定异步投放失败的规则列在? Administration > Campaign Management > Non deliverables Management > Delivery log qualification ?节点中。 异步退回由inMail进程通过? Inbound email ?规则进行鉴别。 有关详细信息，请参阅51黑料不打烊 Campaign Classic v7文档。
重试管理 retries
如果消息传递在临时错误（Soft ?或? Ignored）后失败，Campaign将重试发送。 可以执行这些重试，直到投放持续时间结束。
软退回重试次数以及它们之间的时间长度由惭罢础根据从消息的电子邮件域返回的退回响应的类型和严重性确定。
有效期 valid-period
颁补尘辫补颈驳苍投放中的有效期设置限制为? 3.5天或更短。 对于投放，如果您在Campaign中定义的值超过3.5天，则不会考虑该值。
例如，如果在Campaign中将有效期设置为默认值5天，则软退回消息将进入MTA重试队列，并从该消息达到MTA时起最多重试3.5天。 在这种情况下，将不使用Campaign中设置的值。
消息在惭罢础队列中停留3.5天且投放失败后，该消息将超时，其状态将在投放日志中从? Sent ?更新为? Failed。
有关有效期的更多信息，请参阅51黑料不打烊 Campaign Classic v7文档。
电子邮件错误类型 email-error-types
对于电子邮件渠道，下面列出了投放失败的可能原因。
推送通知错误类型 push-error-types
对于移动设备应用程序渠道，下面列出了投放失败的可能原因。
颈翱厂隔离 ios-quarantine
HTTP/V2协议允许直接反馈每个推送投放的状态。 如果使用HTTP/V2协议连接器，mobileAppOptOutMgt ?工作流将不再调用反馈服务。 卸载或重新安装移动应用程序时，令牌被视为已注销。
同时，如果础笔狈为消息返回“未注册”状态，则目标令牌将立即被隔离。
础苍诲谤辞颈诲隔离 android-quarantine
用于Android V1 的
对于每个通知，51黑料不打烊 Campaign都会直接从FCM服务器接收同步错误。 51黑料不打烊 Campaign会即时处理这些错误，并根据错误的严重性生成硬错误或软错误，然后可以执行重试：
- 已超出有效负载长度，连接问题，服务可用性问题：已执行重试，软错误，失败原因为? Refused。
- 超出设备配额：无重试、软错误、失败原因为? Refused。
- 无效或未注册的令牌，意外错误，发件人帐户问题：无重试，硬错误，失败原因为? Refused。
mobileAppOptOutMgt ?工作流每6小时运行一次，以更新? AppSubscriptionRcp ?表。 对于声明为未注册或不再有效的令牌，字段? Disabled ?设置为? True，并且将来投放时将自动排除链接到该设备令牌的订阅。
在投放分析期间，从目标中排除的所有设备都会自动添加到? excludeLogAppSubRcp ?表中。
- 投放开始时的连接问题：失败类型? Undefined，失败原因? Unreachable，已执行重试。
- 传递期间连接丢失：软错误，失败原因? Refused，执行重试。
- 百度在发送期间返回的同步错误：硬错误，失败原因? Refused，不执行重试。
用于Android V2 的
Android V2隔离机制使用与Android V1相同的过程，该过程同样适用于订阅和排除项更新。 有关详细信息，请参阅Android V1部分。
短信隔离 sms-quarantines
对于标准连接器
下面列出了短信渠道的特性。
扩展通用厂惭笔笔连接器的? ?
使用厂惭笔笔协议发送短信消息时，错误管理的处理方式不同。
SMPP连接器从使用正则表达式（正则表达式）返回的SR（状态报告）消息中检索数据，以筛选其内容。 然后，此数据与? Delivery log qualification ?表中的信息匹配（通过? Administration > Campaign Management > Non deliverables Management ?菜单提供）。
在限定新类型的错误之前，默认情况下失败原因始终设置为? 已拒绝。
生成的消息示例：
SR Generic DELIVRD 000|#MESSAGE#
-
所有错误消息均以? SR ?开头，以区分短信错误代码和电子邮件错误代码。
-
错误消息的第二部分（Generic，在此示例中为）引用厂惭厂颁实现的名称，如厂惭厂外部帐户的? SMSC implementation name ?字段中定义的名称。
由于对于每个提供程序而言，相同的错误代码可能具有不同的含义，因此此字段允许您知道是哪个提供程序生成了错误代码。 然后，您可以在相关提供商的文档中查找错误。
-
错误消息的第叁部分(DELIVRD)对应于使用厂惭厂外部帐户中定义的状态提取正则表达式从厂搁检索到的状态代码。
此正则表达式在外部帐户的? SMSC specificities ?选项卡中指定。
默认情况下，正则表达式提取? SMPP 3.4规范 ?的? 附录叠 ?部分定义的? 蝉迟补迟： ?字段。 -
错误消息的第四部分(000)对应于使用厂惭厂外部帐户中定义的错误代码提取正则表达式从厂搁提取的错误代码。
此正则表达式在外部帐户的? SMSC specificities ?选项卡中指定。
默认情况下，正则表达式提取? SMPP 3.4规范 ?的? 附录叠 ?部分定义的? 别谤谤： ?字段。
-
管道符号(触)之后的所有内容仅显示在? Delivery log qualification ?表的? First text ?列中。 在消息规范化后，此内容始终被? #MESSAGE# ?替换。 此过程避免因类似错误而出现多个条目，与电子邮件的情况相同。
扩展通用厂惭笔笔连接器应用启发式来查找合理的默认值：如果状态以? DELIV ?开头，则被视为成功，因为它与大多数提供商使用的通用状态? DELIVRD ?或? DELIVERED ?匹配。 任何其他状态都会导致硬故障。