如何在 Make 中验证邮箱
Make 场景在支撑营销的表单、CRM 和邮件工具之间传递联系人，因此是在坏地址扩散前将其拦截的理想位置。借助 HTTP 模块，可以在场景中途调用 VeriMails API，实时验证每个联系人，并用 Router 将每个结果送到对应的位置。本指南将逐步演示这一搭建过程。
要点速览
Make 场景搭建清单
把场景设计成一道关卡：触发器数据进入，VeriMails 检查邮箱地址，Router 筛选器决定哪些数据可以继续流转。
| 决策项 | Make 设置 | 操作说明 |
|---|---|---|
| 触发范围 | 从最先接收联系人数据包的模块开始：表单监听、自定义 webhook、CRM 记录或表格行。 | 在格式化或数据补全模块改变数据结构之前，先映射原始邮箱值。 |
| HTTP 请求 | 在触发器之后添加 HTTP 模块，将邮箱发送到 VeriMails 端点，并把 API 密钥保存在模块连接或账户中可用的安全凭据设置里。 | 让 API 验证调用位于任何创建订阅者、线索或受众成员的模块之前。 |
| Router 设计 | 为可送达联系人建一条路由，为被拒联系人建一条路由，再为意外或空状态建一条回退路由。 | Make 的各条路由独立筛选，因此要按结果为每条路由命名，并在测试期间保持回退路由可见。 |
| 暂存记录日志 | 将无效、一次性邮箱和 Catch-all 联系人写入表格、数据存储或通知，并附上来源和原因字段。 | 一份简单的日志能让低质量的线索来源一目了然，也为操作人员提供回滚依据。 |
| 启用测试 | 在排期或启用场景前，先用能覆盖每条路由的示例数据包运行一次。 | 查看场景历史记录，确认解析后的 VeriMails 响应以及处理它的路由。 |
为什么要验证 Make 中的联系人
Make 连接着采集和使用联系人数据的各个应用，正处于验证步骤最能发挥作用的位置。在场景内检查地址，可以避免下游每个连接的应用继承坏数据。
场景会把联系人推送到负责发送和计费的系统
典型的 Make 场景会把新的表单提交或 CRM 记录推送到邮件平台、广告受众或销售工具。如果联系人无效，这个坏地址就会进入一个要为它收费或会尝试向它发信的系统。在创建步骤之前放置 VeriMails HTTP 模块，可以让每个连接的应用保持干净。
表单和 webhook 触发器带来的错误最多
最常见的场景触发器，例如新表单提交、webhook 数据和新表格行，也是邮箱数据中最杂乱的来源。拼写错误、废弃地址和虚假填写源源不断。在触发器输出端加一个验证模块，就能在自动化入口处把它们拦下。
实时验证让列表始终保持干净
在场景内验证，意味着每个联系人流经时就立即检查，而不是几周后才在批量导出中处理。列表持续保持干净，退信率没有机会上升，也不会给一开始就错误的地址发信。
坏地址仍会退信并损害发件人信誉
无论表单和收件箱之间有多少个模块，无效地址最终都会退信。退信率超过 5% 会让整个列表的活动更容易进入垃圾箱。在场景中加入 VeriMails 步骤，能从源头消除这一风险，而不是让邮件平台来承担后果。
VeriMails 检查哪些内容
当 HTTP 模块为某个联系人调用 VeriMails API 时，VeriMails 会执行一整套检查，并返回 Router 可直接分支的结构化结果。每个地址的检测方式如下：
语法验证确认地址格式正确。 MX 和 DNS 记录会被查询，以确认域名存在且能够接收邮件。实时 SMTP 握手连接收件邮件服务器，确认该邮箱确实接收邮件，全程不发送任何内容。 Catch-all 检测识别接收所有地址邮件的域名。一次性邮箱检测标记临时邮箱域名。角色邮箱检测识别 info@、sales@、support@ 等通用地址。
VeriMails 返回清晰的验证结果，响应速度快，足以内嵌在实时场景中。Catch-all 域名会作为明确的检测结果返回，方便 Router 筛选器有针对性地处理，绝不是模糊的评分。
Make 用户价格
实时验证场景会随着新联系人流经而扣减 VeriMails 积分，只为实际验证的地址付费。积分包低至每个邮箱 $0.0019，10,000 积分售价 $19。更大的积分包最高可达 500 万个地址，售价 $1,499，适合高流量场景。
如果联系人流量稳定、希望费用可预期，年付套餐低至 $12.50/月（按年计费）。每个新账户注册即享 100 免费积分，无需信用卡，积分永不过期，可以先搭建并测试场景，再决定是否付费。
流程图示
按此流程将 VeriMails 作为质量关卡加入 Make 场景。
- 触发范围：在表单、表格、webhook 或 CRM 模块生成联系人数据包后，立即映射邮箱字段。
- API 步骤：安全保存 VeriMails 密钥，并将 API 响应字段映射到场景中用于路由。
- 结果处理：将可送达联系人送入创建/更新路由，并记录无效或一次性邮箱联系人以供复核。
分步操作
为新联系人设置触发模块
新建场景并添加引入联系人的触发模块，例如监听表单提交的模块、自定义 webhook、新 CRM 记录或新表格行。该触发器输出的邮箱地址将在场景后续步骤中被验证和路由。
添加 HTTP 模块调用 VeriMails API
添加 HTTP 模块，配置其向 VeriMails 验证端点发送请求。将触发器中的邮箱字段映射到请求中，附上 VeriMails API 密钥用于身份验证，并启用响应解析，让 Make 映射 JSON 验证字段供后续模块使用。
添加 Router 按结果分支
在 HTTP 模块后放置一个 Router。Router 会把场景拆分成多条路由，每条都有自己的筛选器。设置一条路由仅在 VeriMails 结果为可送达时运行，再为不可送达、一次性邮箱或 Catch-all 结果添加另一条路由。也可以为所有不匹配的情况配置一条回退路由。
将可送达联系人送到目标应用
在可送达路由上，添加在邮件平台、CRM 或广告受众中创建或更新联系人的模块。只有经过验证、可送达的地址会走这条路由，连接应用中的列表和受众因此自动保持干净。
处理坏地址并启用场景
在不可送达路由上，添加一个模块，把不可送达和一次性邮箱地址记录到表格，或发送通知以便复核。先用示例数据运行一次场景，确认每条路由都正常工作，然后排期或启用，让每个新联系人都得到实时验证。
每种结果的处理方式
当每种验证状态都有明确的路由时，Make 场景最容易运维。不要让缺失或有风险的结果落入与已验证联系人相同的模块。
- 可送达：发送到 CRM、邮件工具或广告受众的创建/更新模块，可选写入验证日期字段。
- 不可送达：终止干净路由，将记录写入屏蔽表或清理表。
- Catch-all：送入谨慎复核路由。这些联系人可能适合高价值的销售跟进，但不应混入常规活动的发送量。
- 一次性邮箱：不放入生命周期活动，并标记线索来源以便排查。
- 角色邮箱：根据工作流目标决定路由。共享邮箱可能适合运营类消息，但不适合个性化外联。
- 回退或错误：通知操作人员，并在请求或映射问题修复前停止向下游写入。