SMS

为什么我的 SMS 消息会被运营商过滤?

当消息、发件人或流量模式未通过网络检查时,运营商的过滤机制可能阻止消息送达。

SMS 即使已被接受,也可能因号码无效、手机无法接通或网络问题而投递失败。消息记录、投递事件和返回的错误有助于区分这些情况与过滤。

如何排查疑似过滤问题?

你将消息记录与其 SMS 事件进行比较。事件描述结果;错误和提供商详情有助于解释结果。

事件事件说明
sms.rejected已接受的消息在处理阶段被拒绝,或被下游服务提供商拒绝。
sms.failed收到了永久性失败报告。
sms.undelivered收到了可恢复的失败报告,例如无法联系到接收者或网络出现问题。
sms.expired服务提供商报告消息已过期。

单凭任何一个事件都无法证明消息被过滤。在 Bird 的投递回执映射中,服务提供商给出的原因 carrier_rejected 会映射为 content_rejected。没有对应映射的原因会变成 unknown,需要进一步排查,也可能与过滤无关。回执状态与原因分别用于判断,事件类型由状态决定,因此运营商拒绝可能伴随不同的失败事件。

错误目录定义了 blocked_by_carriersender_unregistered。没有这些代码也不能排除过滤:Bird 将 carrier_rejected 映射为 content_rejected,将未映射的原因归为 unknown。检查实际返回的代码,保留不熟悉的值和提供商详情。

应该保存哪些详情?

保存消息 ID、发件人、接收号码、提交时间、事件类型、标准化的 error.code、错误描述和 carrier_error_code。按接收地、发件人和消息类型对失败进行分组;与影响同一类发送的变化相比,单次失败能提供的证据较少。

标准化代码是供应用程序处理错误的稳定字段。错误描述用于诊断,不应将其当作固定接口约定来解析。服务提供商提供更详细的代码时,carrier_error_code 会携带该值;它不一定是移动运营商自己的代码。如果服务提供商未提供代码,或失败发生在向服务提供商移交消息之前,该字段可能为空。

例如,content_rejected 表示应检查报告的拒绝结果,invalid_destination 表示应检查接收号码,provider_unavailable 则指向网络或容量方面的结果。unknown 表示原因仍未查明。如果这些详情不足以解释失败,请向支持团队提供消息 ID 和可用的服务提供商代码。

注册发件人能防止消息被过滤吗?

注册可以满足相应发件人计划的要求,但无法保证投递成功。发件人还必须具备向该接收地发送消息的资格,消息内容和流量也必须符合相关要求。

使用本地号码向美国发送 A2P 消息时,应检查完整的 10DLC 注册流程:品牌、活动及号码关联。品牌或活动获批,并不会自动关联你拥有的每个号码。免费呼叫号码和短码适用不同的计划要求。其他接收地可能要求注册发件人名称。

通过 SMS 接收地规划发件人类型,并在上线前确认适用要求及工作区的注册状态。国家指南提供参考信息,不能证明你的发件人已获批准。

遇到退订导致的失败应该怎么办?

保留接收者的偏好。如果 Bird 已屏蔽某个发件人与接收者的组合,向该组合发送消息会在 API 层被拒绝,并返回 E12077;这次拒绝不会创建消息或消息事件。下游报告 recipient_opted_out 是另一种情况:它是已接受消息的处理结果,会使 Bird 记录对该组合的发送屏蔽。

支持的退订关键词可以为发送者和接收者配对建立发送限制。配对层级的限制事件并不涵盖工作区的所有偏好或通过客户支持收到的所有请求。选择受众时,应纳入这些更广泛的偏好。不要通过更换发送者来规避退订。

重试之前应检查什么?

  1. 发件人是否准备就绪。 确认此类流量所需的发件人类型、注册状态和接收地访问权限。
  2. 授权与相关性。 确认接收者已同意接收此用途的消息,且尚未撤回授权。
  3. 内容与链接。 清晰标明企业身份,使用合适的链接,并检查接收地对内容的要求。仅更换链接不能证明消息具备投递资格。
  4. 流量与时间。 将失败的发送与正常流量模式、排队情况及路由限制进行比较。反复提交同样被拒绝的内容,可能增加费用,却无法解决原因。
  5. 报告的失败原因。 再次发送前先排查永久性拒绝。对于结果不明确的 API 响应,在重放窗口内复用原有的幂等键;不要因结果不确定就自动发起第二个请求。

SMS 路由在交给运营商之前应用目的地控制。SMS 集成通过消息记录和投递事件跟踪每个已接受的请求。

简而言之

  1. 投递失败是排查的起点。

    事件、标准化错误和提供商详情共同描述失败情况。原因未知并不能证明消息遭到了运营商过滤。

  2. 注册是一项要求,无法保证消息送达。

    先检查发件人、接收地、内容、接收者授权和流量模式,再决定如何调整。

  3. 退订是需要保留的接收偏好。

    区分 API 对已被屏蔽的发件人与接收者组合的拒绝,以及下游报告的退订结果,并遵守接收者请求的完整范围。

  4. 将证据与消息一同保存。

    保存消息 ID、接收号码、发件人、时间、事件和错误详情,以便排查异常模式,或向支持团队提供有效的信息。

基于同一网络构建。

测试 API 密钥即刻获取。添加付款方式并验证发送者身份后,即可解锁生产环境。

你的下一个创意。
随时连接。