By Samuyl Joshi
在国际短信业务中，发送接口返回成功，并不意味着短信已经送达用户手机。验证码是否成功投递、订单通知是否到达、批量短信为何出现失败，都需要通过短信回执获取进一步的状态信息。
短信回执推送（Delivery Receipt Push）是指云通信平台接收上游运营商或短信通道返回的投递状态报告，完成解析和消息匹配后，将状态变化主动通知客户业务系统的技术机制。
在国际短信场景中，这类投递状态报告通常称为 DLR（Delivery Receipt）。
对于跨境电商、海外金融、游戏出海和跨境物流等企业，国际短信回执不仅用于展示发送结果，也直接影响送达率统计、通道质量评估、异常消息排查和业务流程自动化。
那么，短信回执推送为什么能够较快返回状态？它依赖哪些底层技术？当回执延迟、丢失或者状态不一致时，又应该从哪些环节排查？
短信回执推送的核心，是将短信在后续投递过程中产生的状态信息传递给最初的发送方。
在国际短信系统中，需要区分三个容易混淆的概念。
| 概念 | 技术含义 | 是否代表短信已送达 |
|---|---|---|
| API 发送响应 | 短信发送请求被接口接受或拒绝 | 不一定 |
| SMPP 提交响应 | 上游短信中心对提交请求返回响应 | 不一定 |
| DLR 投递回执 | 上游返回的短信投递状态报告 | 取决于具体回执状态 |
例如，在 SMPP 协议中，submit_sm_resp 用于响应短信提交请求，而投递回执通常通过后续的 deliver_sm 或 data_sm 等操作返回。
短信提交成功与短信投递成功是两个不同的阶段，不能仅凭发送接口的成功响应判断终端投递结果。
还需要注意，本文所说的「上行回执推送」，是指投递状态从运营商或上游通道回传云通信平台，再推送到客户业务系统。它与用户通过手机向业务号码发送内容的上行短信（MO）不是同一概念。
一套可靠的国际短信回执系统，通常包含发送 API、消息队列、通道连接服务、回执解析服务、状态存储和 HTTP 回调服务。
典型处理流程如下：
客户业务系统
│
│ 发送短信请求
▼
云通信平台 API
│
▼
消息队列与发送调度
│
▼
上游短信通道 / 短信中心
│
│ 返回提交响应
│
│ 后续产生投递回执
▼
通道接收服务
│
▼
回执解析与消息 ID 匹配
│
▼
状态归一化与持久化
│
▼
异步回调队列
│
│ HTTP POST
▼
客户回调接口
│
▼
订单状态更新 / 业务统计 / 异常处理这条链路可以拆分为四个核心环节：回执产生、协议接收、状态处理和回调推送。
客户提交短信后，云通信平台会为消息生成内部标识，并记录必要的业务信息，例如客户账号、目标号码、提交时间、使用通道和业务请求标识。
如果通过 SMPP 接入上游，平台可以根据需求在 submit_sm 请求中设置 registered_delivery，申请相应的投递回执。
上游接受短信提交请求后，通常会通过 submit_sm_resp 返回消息标识。平台需要妥善保存内部消息 ID 与上游消息 ID 的映射关系，以便后续准确定位原始短信。
在国际短信业务中，不同国家、运营商和中间通道可能使用不同的消息 ID。如果经过多级转发，标识还可能发生映射。
因此，回执处理不能单纯依赖手机号和发送时间进行匹配。
可靠的消息 ID 关联机制，是保证短信回执准确性和避免状态串单的基础。
短信提交后，短信中心会根据实际投递情况和自身支持的机制，产生对应的状态报告。
在 SMPP 场景下，回执通常通过 deliver_sm 或 data_sm 等协议操作返回。平台接收到消息后，需要判断其属于普通上行短信、投递回执还是其他消息类型，并进入对应的处理逻辑。
常见的回执解析信息包括：
esm_class：辅助识别消息类型，包括投递回执相关标识。receipted_message_id：在相应协议实现中用于关联原始消息的消息标识。message_state：在相应实现中承载投递状态。具体字段及编码方式取决于协议版本、上游实现和通道约定。生产系统需要兼容实际接入通道的回执格式，而不能假设所有通道都采用完全相同的结构。
国际短信平台通常需要接入不同国家和地区的上游通道。即使代表相同结果，各通道返回的状态名称、状态码及错误信息也可能不同。
例如，成功状态可能使用 DELIVRD、DELIVERED 或其他定义；失败状态则可能需要结合错误码判断原因。
因此，平台需要建立统一的短信状态映射机制，将不同上游返回的数据转换为内部标准状态，同时保留必要的原始回执信息。
在处理过程中，需要重点关注三个问题：
经过这些处理，客户系统才能以较为一致的规则查询和使用国际短信送达状态。
平台完成回执解析后，通常会将状态事件写入独立的回调队列，再由回调服务向客户预先配置的接口发送 HTTP POST 请求。
回调数据可以根据接口设计包含以下信息：
{
"message_id": "msg_202610220001",
"status": "DELIVERED",
"error_code": "0",
"event_time": "2026-10-22T10:30:15+08:00"
}以上为示例结构，实际字段、状态值与时间格式应以平台 API 定义为准。
客户系统收到回调后，可以更新订单通知状态、记录验证码投递情况、分析通道表现，或者触发后续业务操作。
将通道接收、状态处理和 HTTP 回调拆分，可以避免客户系统响应缓慢时影响上游回执的正常接收。
短信回执之所以可以较快返回，关键在于上游状态报告机制与平台内部的事件驱动架构，而不是单纯增加一个 HTTP 回调接口。
传统主动查询方式需要客户系统按照固定间隔调用接口检查短信状态。如果每隔 10 秒查询一次，即使状态在查询间隔内已经发生变化，也可能需要等到下一轮查询才能获取结果。
回执推送则采用事件驱动模式：当平台收到上游状态报告后，即可进入解析和推送流程，不必等待客户发起下一次查询。
这种机制减少了轮询造成的额外延迟，也降低了频繁查询带来的系统开销。
但需要明确，事件驱动只能缩短平台内部发现和传递状态的时间，并不能让运营商提前生成回执。
在 SMPP 集成场景中，平台通常与上游短信中心保持持久连接。上游可以利用既有会话返回相关协议消息，无须为每条回执单独重新建立连接。
在平台内部，回执接收、状态更新和客户回调可以分别由独立服务处理。
这种异步解耦架构能够降低各环节之间的直接依赖。当客户接口响应变慢时，回调队列可以暂存待处理事件，从而减少对通道接收服务的影响。
短信发送量较大时，回执可能在短时间内集中到达。如果由单个处理进程同步执行消息解析、数据库写入和客户回调，很容易出现队列积压。
通过持久化消息队列、并发消费者、合理的数据库写入策略和独立的回调工作进程，平台可以根据实际负载分配处理资源。
不过，并发能力需要与数据库连接池、上游速率限制、客户接口限流和系统资源相匹配。仅提高线程数量，未必能够改善整体回执延迟。
短信回执的端到端响应时间通常由上游生成回执、跨境网络传输、平台处理和客户接口响应等环节共同决定。
1. 运营商的回执支持与生成策略
不同国家和地区的运营商，对短信状态报告的支持范围和返回策略可能存在差异。有些通道能够提供较及时的状态报告，有些通道则可能仅支持部分状态，或存在特定的返回规则。
如果上游尚未生成或返回回执，云通信平台就无法获得真实的投递结果。
2. 终端状态与短信重试机制
当目标手机关机、暂时无法接入网络或出现漫游异常时，短信可能进入等待或重试流程。
在存储转发机制下，短信中心可能会在有效期内继续尝试投递。此时，平台尚未收到终态回执，并不必然意味着短信已经失败。
3. 国际通道的传输与排队延迟
国际短信可能经过多个转发节点。上游系统拥塞、路由切换、连接异常和队列积压，都可能延迟回执回传。
因此，评估国际短信通道的质量时，不应只关注短信提交速度，还应观察状态回执的覆盖情况、返回延迟及异常比例。
4. 平台内部处理与客户接口响应
数据库慢查询、回调任务积压、网络超时、客户接口限流等因素，也可能拖慢最终状态通知。
建议平台分别记录回执接收时间、解析完成时间、状态落库时间、回调发送时间和客户响应时间，以便识别延迟究竟发生在哪个环节。
对于高并发国际短信业务，回执系统需要同时考虑及时性、准确性和异常恢复能力。
第一，建立幂等机制
网络超时后，平台可能重试同一事件。客户系统应通过事件标识或业务唯一键避免重复处理，防止重复记账和重复触发业务动作。
第二，管理状态流转
应明确中间状态与终态的转换规则，避免过期或乱序的回执覆盖最终结果。
第三，设置可靠的回调重试
对于临时网络异常、HTTP 5xx 或限流，可采用有限次数的重试和退避策略；多次失败后，应进入异常队列等待排查或恢复。
第四，保留完整的链路日志
保存平台消息 ID、上游消息 ID、通道信息、原始回执、状态变化、回调响应和重试记录，可以帮助技术团队准确定位问题。
第五，建立回执监控指标
可根据业务实际监控回执覆盖率、回执延迟分布、回调成功率、队列积压量、重复回执比例及长期未完成消息数量。
这些措施能够让回执系统在流量波动或局部故障时保持更好的可观测性和可恢复性。
短信回执推送是指云通信平台接收上游运营商或短信通道返回的投递状态报告，完成解析和消息匹配后，通过回调接口主动通知客户系统。它主要用于跟踪短信投递状态、分析发送结果和排查异常。
发送成功通常表示接口或上游已接受提交请求，不一定代表短信已经送达。没有收到回执，可能与运营商未返回状态报告、短信仍处于投递或重试阶段、回执传输延迟、消息 ID 匹配异常或客户回调失败有关。
在 SMPP 场景下，平台可以根据业务需要申请投递回执。短信提交响应通常通过 submit_sm_resp 返回，而后续投递回执通常通过 deliver_sm 或 data_sm 等协议操作传递。具体字段和状态格式取决于上游通道实现。
不能保证所有国际短信都在固定时间内返回最终状态。回执的支持范围和返回时间受到目的地运营商、上游通道、终端状态及平台处理能力等因素影响。平台可以优化自身处理链路，但无法控制运营商何时产生回执。
应综合观察回执覆盖情况、回执延迟分布、状态准确性、回调成功率、重复事件处理能力和异常恢复机制。对于长期未收到回执的消息，还需要结合通道规则与主动查询机制进行补充核验。
短信回执推送并非简单的接口通知，而是一条贯穿运营商、上游通道、云通信平台与客户业务系统的技术链路。
从 SMPP 协议接收、消息 ID 匹配，到统一状态处理、异步队列和 HTTP 回调，每个环节都会影响回执的准确性、及时性和可靠性。
对于国际短信业务，完善的回执体系能够帮助企业更准确地掌握消息状态，为送达率分析、通道质量评估和业务流程优化提供数据依据。
YaningAI 云通讯平台面向企业国际通信场景，关注国际短信接入、消息状态追踪和 API 集成效率，帮助企业构建更清晰、可观测的消息触达体系。
如需了解国际短信 API、SMPP 接入或短信回执推送方案，可联系 YaningAI 技术团队，结合目标国家、业务规模与现有系统架构评估合适的接入方式。
国际短信发送量增长后，仅依赖接口提交结果，往往难以满足企业对消息状态、通道表现和异常排查的需求。
YaningAI 云通讯平台支持面向企业国际通信场景的短信接入方案，可结合业务需求评估 API 或 SMPP 集成方式，并围绕回执处理、状态追踪和业务系统对接设计合适的技术架构。
适用场景：
联系我们，了解国际短信 API 与回执推送接入方案。
提交目标国家、预估短信量和技术接入方式，便于技术团队评估适合的国际短信方案。
咨询国际短信接入方案
