关于本视频

视频中的地址均为示例。文件验证需要付费账号。

视频文字稿

1. 00:00你在搭建什么

   冷邮件靠三样东西运转：你拥有的域名、你能控制的邮箱，以及一个仍然有效的发信登录。预算表里常把三样东西混为一谈。账号是一个邮箱身份，名单是联系人数据，开通（provisioning）则是在你控制的域名上建立发信能力。只有最后一项才是基础设施。有个简单的测试：你能说出每个邮箱是谁创建的吗？今天由谁在运营？谁拥有管理权限？三个问题都答得上来，这份发信能力才算是你的。

2. 00:34域名与邮箱

   先从你拥有的域名开始。条件合适时，用与主品牌分开的域名发信。这样你对信誉的控制更清晰，也能把风险挡在核心域名之外。然后给每个域名加几个邮箱。每个收件箱都需要一位负责人、一份书面的用途说明和一项访问策略，否则安全团队接手的就是没人能解释的凭据。接下来，为每个发信域名做认证。SPF 指明哪些服务器可以代表这个域名发信。DKIM 附上一个收件方可以验证的签名。DMARC 把这些结果与可见的 From 域名关联起来，并为验证失败设定处理策略。然后放慢节奏。新邮箱需要循序渐进地提升发信量。如果一下子塞进大量邮件，再干净的设置也白费了。

3. 01:18SMTP 健康

   接下来是大多数团队会跳过的部分。邮件投递要回答两个不同的问题：这个应用能不能通过这台服务器提交邮件？收件方应不应该信任这个域名？SMTP 认证回答第一个问题，SPF、DKIM 和 DMARC 回答第二个。可以想成员工工牌和公司信笺：工牌让你进门，信笺向外界表明你是谁，有了一个不等于有了另一个。登录有固定的顺序。你的应用连接后发送 EHLO，服务器列出它支持的方式，应用选择一种并发送 AUTH。代码 235 表示接受，535 表示拒绝。而 535 并不总是密码错误，也可能是账号被封锁、登录方式被禁用，或者服务商拒绝传统的登录方式。密码正确并不能说明问题已经解决。端口也很重要。25 端口主要用于服务器之间的中继，587 端口用于邮件提交，通常配合 STARTTLS，465 端口从一开始就是加密的。如果客户端和服务器预期的不一致，在登录之前就会失败。这里有一条规矩：永远不要靠关闭 TLS 来解决登录失败，那样可能暴露凭据，而真正的问题依然存在。密码不变，也可能失效，因为服务商正在从基本登录转向 OAuth。微软计划在 2026 年 12 月之后，对现有的 Exchange Online 租户默认停用基本 SMTP 认证。所以要把它们都记下来：每个提交邮件的 CRM 工作流、表单、账单应用和脚本。对每一个，记录账号、端口与加密方式、登录方式和负责人。

4. 03:03逐一测试故障

   然后有意识地测试四种故障。提交：应用能通过 TLS 登录吗？域名：你的记录与 From 地址一致吗？数据：新地址和导入的地址有没有检查过？信誉：退信和投诉有没有在上升？登录成功只能证明一件事：你可以提交邮件。它并不能证明对方的邮箱真的存在。验证会查询域名的 MX 记录，然后与接收方服务器进行一次 SMTP 对话，不会发送任何邮件。有些服务器对每个地址都说可以，BillionVerify 把这类地址报告为 catch-all，而未知结果不收费。单个检查可以使用每天的免费积分，验证文件则需要付费账号。拥有域名，指定负责人，测试登录，检查地址。这样的设置，你可以衡量、修复，也能长期维护。

5. 03:54免费开始

   每天使用账号可获得 20 个免费积分，每月最多 600 个，无需信用卡。访问 billionverify.com 开始使用。

本视频中展示的工具

• 批量购买邮箱账户: 风险与替代方案指南