“模板提交了，等了两天，被拒了。改了再交，又被拒了。”
这是许多刚接触印度短信业务的企业最常遇到的场景。在印度的DLT(分布式账本技术)体系下，内容模板(Content Template)的审核是整个备案流程中最容易出错的环节——不是因为内容本身有问题，而是因为格式、分类或变量使用上的细微偏差。
DLT模板审核的本质，是TRAI要求企业**在发送印度短信之前，先把“要发什么”提前备案**。运营商根据备案的模板逐条比对实际发送的内容——完全匹配才放行，任何细微差异都会被拦截。
模板报备分为**两步走**：
- **Consent Template(同意模板)** ：向用户获取同意接收短信的标准文案
- **Content Template(内容模板)** ：实际发送的短信正文格式
只有**Content Template审核通过并关联到已批准的Header(Sender ID)** 后，短信才能合规发送。
原因1：变量格式错误——占所有被拒原因的一半以上
变量问题是DLT模板审核被拒的“头号杀手”。
**常见错误**：
- 使用`{name}`或`${var}`等编程语法——DLT平台只认`{#...#}`格式
- 变量未标注数据类型——2026年1月14日后创建的新模板，**必须使用带类型标签的变量**(如`{#numeric#}`)，旧版`{#var#}`已不再被接受
- 变量紧挨着变量(如`{#numeric#}{#alphanumeric#}`)
- 变量作为整条短信的**唯一内容**——模板必须有固定文本
**正确示例**：
```
Dear {#alphanumeric#}, your OTP is {#numeric#}. Visit {#url#} for details.
```
**允许的变量标签**：
- `{#numeric#}` — OTP、金额、数字
- `{#alphanumeric#}` — 订单号、工单号
- `{#url#}` — 网页链接
- `{#urlott#}` — App下载链接
- `{#cbn#}` — 回拨号码
- `{#email#}` — 邮箱地址
原因2：模板分类与Header不匹配——最常见的分类错误
这是导致模板被拒的**单次最常见原因**。
每一条模板在提交时都必须声明类别：
- **Transactional(交易类)** ：OTP、支付确认
- **Service(服务类)** ：订单通知、物流提醒
- **Promotional(促销类)** ：营销推广
**核心规则**：
- **营销内容不能通过Transactional或Service类模板发送**——促销内容用错模板类别会直接导致模板被拉黑
- **模板必须与Header的类别一致**——Transactional Header只能绑定Transactional模板
2026年3月10日起，**Service Explicit模板已整体迁移至Promotional类别**。原本属于“明确服务类”的模板现在按促销类管理，发送时段、DND限制均需遵守促销规则。
原因3：模板正文与已存在模板重复
DLT平台**不允许注册内容完全相同的重复模板**。
如果某个模板已被同一Principal Entity注册过(即使是被拒绝的版本也可能占用)，再次提交相同内容会被系统判定为重复。
**解决方案**：提交前查询已注册的模板列表，确认没有相同内容的模板存在。如果确实需要多个相似的模板，必须确保每个模板的**内容、类别或用途有实质性差异**。
原因4：模板中缺少品牌名称
DLT平台审核时会检查模板中是否包含**品牌/实体/商号名称**。如果模板正文中没有品牌标识，审核会被拒绝。
**正确做法**：在模板的固定文本中明确包含品牌名称，例如：
```
YourBrand: Your OTP is {#numeric#}
```
原因5：URL和回拨号码未白名单化
在Service Implicit类模板中，如果包含**URL或回拨电话号码**，这些内容必须在DLT平台**预先注册(白名单化)**，否则模板会被拒绝。
**解决方案**：提交模板前，确保模板中所有URL和电话号码已在DLT平台完成白名单注册。对于Promotional类别，URL和电话号码的审核规则更为严格。
这是最容易被混淆的两个概念。
| 类型 | 发生阶段 | 表现 | 影响范围 |
|---|---|---|---|
| 注册拒绝 | 模板提交审核时 | 平台返回“Rejected” | 模板无法使用，需修改重交 |
| 发送时失配 | 模板已通过，但发送时内容与备案模板不一致 | 状态码188 / template mismatch | 短信被拦截，但已产生费用 |
**注册拒绝可以重交，没有次数限制**。但发送时失配更隐蔽——模板已通过审核，但发送的内容与备案模板在**标点、空格、大小写**等细节上不一致，运营商清洗引擎逐字符比对后拦截。
**预防方法**：在发送前用真实内容替换变量，逐字符比对是否与备案模板完全一致。
| 新规 | 生效时间 | 要求 |
|---|---|---|
| 变量必须带类型标签 | 2026年1月14日 | 新模板必须用{#numeric#}等标签，不能用{#var#} |
| Service Explicit→Promotional | 2026年3月10日 | 原明确服务类模板按促销类管理 |
| 模板审核周期 | — | PE注册24-72小时，模板审批2-24小时 |
DLT模板审核被拒的核心原因可以归结为**三个不匹配**：
1. **格式不匹配**：变量没用对标签
2. **类别不匹配**：模板类别与Header类别不一致
3. **内容不匹配**：发送时的内容与备案模板不一致
**行动清单**：
1. **提交前用模板验证工具检查**：很多服务商提供免费DLT模板格式验证工具，提交前跑一遍可节省大量时间
2. **变量必须带类型标签**：2026年新模板强制要求
3. **确认模板类别与Header一致**：Transactional用Transactional Header，Promotional用Promotional Header
4. **模板正文必须包含品牌名**
5. **URL和回拨号码提前白名单化**
6. **发送前做“逐字符比对”**：防止通过审核的模板在发送时因细节失配被拦截
