为什么事务性邮件的送达完全是另一回事
营销邮件和事务性邮件之间有一个关键区别，很多开发者在第一次认真思考送达率时会忽略它。营销邮件——新闻通讯、促销活动、公告——发给的是主动订阅的用户。它们能容忍偶尔的延迟，甚至偶尔落进垃圾箱。如果一封新闻通讯对 2% 的名单进了垃圾箱，虽然可惜，但你的业务照常运转。
事务性邮件完全不同。验证链接、密码重置、购买确认、双因素验证码、账户安全提醒——它们出现在用户旅程的关键时刻。密码重置邮件进了垃圾箱，意味着用户被锁在自己的账户之外，很可能会提交客服工单，或者更糟——再也不回来了。验证邮件进了垃圾箱，意味着新用户无法完成注册，你的获客漏斗上多了一个安静而看不见的缺口。
然而事务性邮件的配置往往还不如营销活动来得用心。很多开发者不去认真搭建验证邮件系统，而是直接用框架自带的发信代码，配一个共享 SMTP 服务器，部署上线，用自己的收件箱测一次——而自己的收件箱垃圾判定阈值往往很宽松——然后就不再管了。问题只有在使用 Gmail、Outlook 或 Yahoo 的真实用户报告收不到邮件时才会暴露。到那时，这个故障已经在生产环境里静默失败了好几周。
SPF：邮件身份验证的地基
发件人策略框架（SPF）是你发信域名上的一条 DNS TXT 记录，它向全世界声明哪些邮件服务器有权代表你发信。当 Gmail 收到一封声称来自 [email protected] 的邮件时，它会对你域名的 SPF 记录做一次 DNS 查询。如果实际发信服务器的 IP 地址列在你的 SPF 记录里，这封邮件就通过 SPF 校验。如果根本没有 SPF 记录——或者发信服务器没有被列入——那么在任何内容评估开始之前，这封邮件就已经被当作可疑对象了。
一旦知道该怎么做，配置 SPF 其实很简单。在域名的 DNS 里添加一条 TXT 记录。取值取决于你的发信服务商。用 SendGrid：v=spf1 include:sendgrid.net ~all。用 AWS SES：v=spf1 include:amazonses.com ~all。用 Mailgun：v=spf1 include:mailgun.org ~all。服务商的文档会给出确切的 include 值。后缀 ~all 是"软失败"——来自未列出服务器的邮件会被打标记，但不会被直接拒收。等你确信 SPF 记录完整无误后，可以升级为 -all（硬失败），它会要求接收服务器彻底拒收未授权邮件。
一个常见陷阱：10 次 DNS 查询的上限。串联多条 include: 指令的 SPF 记录可能超过这个上限，导致即使所有服务器技术上都已列出，SPF 依然失败。用 MXToolbox 检查你的 SPF 记录，它会清楚地标出查询次数问题。关于 SPF、DKIM 和 DMARC 如何相互配合，SendGrid 关于邮件身份验证的文档讲得很清楚。
DKIM：证明邮件未被篡改的密码学凭据
域名密钥识别邮件（DKIM）会为你发出的每一封邮件附加一个密码学签名。签名由你的发信服务商持有的私钥生成，接收方邮件服务器则用你以 DNS TXT 记录形式发布的公钥来验证它。如果签名校验通过，就证明了两件事：这封邮件确实来自你的发信基础设施，而且内容在发送和接收之间没有被修改。
没有配置 DKIM，恶意行为者伪造你的域名就容易得多——他们可以发出看起来来自 [email protected]、实际却由别人发送的邮件。钓鱼活动正是这样运作的。垃圾邮件过滤器也清楚这一点，因此一封本该带 DKIM 签名的域名邮件却缺少有效签名时，会被以更高的怀疑度对待。Spamhaus 等信誉服务同样会把 DKIM 签名历史纳入域名信誉评分。
DKIM 的配置通过你的发信服务商完成。服务商生成一对密钥，私钥保存在自己的基础设施上，并把公钥交给你，让你以 TXT 记录的形式加进 DNS。等这条 DNS 记录发布并生效后，他们代你发送的每一封邮件都会自动带上有效的 DKIM 签名。SendGrid、Mailgun、Amazon SES、Postmark 等主流服务商都会在初始设置阶段引导你完成这一步。如果你当初跳过了，现在就回去把它配好。
DMARC：把一切串联起来的策略层
DMARC（基于域名的邮件身份验证、报告与一致性）建立在 SPF 和 DKIM 之上，定义了当邮件未通过这些校验时接收服务器该如何处理。它还引入了"对齐"概念——要求邮件 From 头中的域名必须与实际通过 SPF 或 DKIM 校验的域名一致。这样就能防止攻击者用一个域名通过 SPF 校验，同时在可见的 From 地址里伪造另一个域名。
部署 DMARC 的正确方式是循序渐进。先从只做监控的策略开始：v=DMARC1; p=none; rua=mailto:[email protected]。p=none 告诉接收服务器在校验失败时不要采取措施，只需把报告发给你。这些汇总报告会告诉你有哪些服务器在代表你发信，以及它们是否通过了 SPF 和 DKIM。在修改策略之前，先看几周报告。
当你确信所有合法邮件都能通过后，再切换到 p=quarantine（校验失败的邮件进垃圾箱），最终过渡到 p=reject（校验失败的邮件直接被拒收）。这种渐进式推进既能保护域名信誉免受伪造，也给你留出时间去发现可能遗漏的合法发信来源。p=reject 的 DMARC 策略配合通过校验的 SPF 和 DKIM，几乎让攻击者无法有效冒充你的域名。
IP 信誉：为什么发信服务器很关键
即使 SPF、DKIM 和 DMARC 都完美无缺，如果发信 IP 地址信誉不佳，邮件仍然可能进垃圾箱。接收方邮件服务器会自行维护——或查询第三方服务维护的——发信 IP 黑名单和信誉评分。一个有垃圾邮件历史的 IP，或者出现在 Spamhaus 这类服务黑名单上的 IP，不管你的身份验证配置多完善，它发出的邮件都会被区别对待。
如果你用的是共享主机商或廉价 SMTP 服务提供的共享 IP，你的信誉就和所有使用同一个 IP 的人绑在一起。同一共享池里的一个垃圾邮件发送者，就可能拖垮该 IP 上所有发件人的送达率。这是应当使用专业事务性邮件服务商——SendGrid、Amazon SES、Postmark、Mailgun——而不是直接从应用服务器或通过共享 SMTP 发信的最有力理由之一。
使用新的发信 IP 时，你还需要逐步给 IP"预热"。从一个全新 IP 突然爆发大量邮件，在接收服务器看来就是垃圾邮件行为。先从较低的发送量开始，在数天到数周内逐步提升。如果你在共享发信池里，大多数专业邮件服务商会自动处理 IP 预热；如果你用的是独立 IP，它们会提供预热计划。
正文与主题行：什么会触发过滤器
除了身份验证和 IP 信誉，邮件本身的内容也会被垃圾邮件过滤器评估。某些模式会稳定地触发垃圾判定。主题行里的触发词——"免费"、"保证"、"立即行动"、过多的感叹号、全大写——都是显而易见的，大多数开发者都会避开。不那么明显的是：过于含糊的主题（"给你的重要通知"）、过于紧迫的主题（"你的账户即将被关闭"），或者对一封本该是事务性邮件而言过于营销化的主题。
文本与图片的比例同样重要。一封几乎全是图片、文字极少的邮件是典型的垃圾邮件特征——群发者会用图片把关键词藏起来，躲开基于文本的过滤器。事务性邮件应当以文本为主，图片尽量少。损坏的 HTML——未闭合的标签、格式错误的属性——是另一个危险信号。始终在 HTML 版本之外同时发送纯文本版本。垃圾邮件过滤器对只有 HTML 的邮件格外警惕，而企业邮件系统常常会把 HTML 完全剥离。
正确测试邮件送达的方法
测试邮件送达最快、最实用的方法是：把测试邮件发到一个新建的临时邮箱，然后同时检查收件箱和垃圾箱。这能立刻给出明确无误的反馈，告诉你邮件是进了收件箱还是被过滤了。用自己的 Gmail 账户测试则不同——你可能早已被列入白名单，因为你是常见发件人；而一个全新的临时地址与你的域名毫无历史往来，能更真实地模拟新用户的首次接触。
每当你改动任何可能影响送达的东西，都应该测试一次验证邮件是否真的送到：更换邮件服务商、大幅修改 HTML 模板、更换发信域名、新增发信子域名，或者部署到新环境（预发布、生产）。这只需两分钟，就能拿到确凿证据。反过来说，等用户来报告问题，意味着你的送达故障已经静默地持续了一段不知多长的时间。
除了收件箱／垃圾箱检查之外，还可以用 MXToolbox 的邮件健康检查工具来体检域名整体状况：SPF、DKIM、DMARC、黑名单状态和 MX 记录配置一次看全。把它写进每个新应用、新发信域名的上线前检查清单。另外也可以参考 OWASP 关于安全相关邮件最佳实践的指南。
退信率与垃圾举报率：真正重要的指标
有两个指标对长期送达率的影响格外大：退信率和垃圾举报率。退信率超过 2% 会向接收服务器和你的发信服务商传递一个信号：你在向大量无效或不存在的地址发信——而这正是购买邮件名单和垃圾邮件团伙的典型特征。即使其他方面都做对了，高退信率照样会带来送达问题。硬退信必须立刻、永久地从发信名单中剔除。
垃圾举报率超过 0.1%（每千封邮件一次举报）是大多数发信服务商开始限制你账户的临界点。如果你配置了 Gmail Postmaster Tools，它会直接报告举报率。通过发信服务商的控制台监控这些指标。如果举报率在上升，就去查明原因——你是不是在给没有明确同意的用户发信？发信频率是不是太高？用户预期收到的东西和实际收到的是否存在落差？
完整的送达率检查清单
- SPF 记录：在发信域名上设置 DNS TXT 记录，列出所有获授权的发信服务器。用 MXToolbox 验证。
- DKIM：通过发信服务商配置密码学签名，并把公钥发布到 DNS。
- DMARC：先用
p=none做监控，审阅汇总报告后再推进到p=quarantine，最后到p=reject。 - 专业发信服务商：使用 SendGrid、SES、Postmark 或 Mailgun——不要用应用服务器或共享 SMTP。
- 干净的主题行：具体、切题，不用触发词，不用过多标点或全大写。
- HTML + 纯文本：永远同时提供两种版本。绝不要只发 HTML 邮件。
- 不要用短链接：正文和验证链接都使用完整的直接 URL。
- 退订链接：在合适的场景下即使是事务性邮件也应包含——有些服务商强制要求。
- 实际办公地址：CAN-SPAM 及许多司法辖区的类似法规都有此要求。
- 硬退信处理：立即移除；绝不对硬退信重试。
- 举报监控：配置 Gmail Postmaster Tools；在控制台监控举报率。
- 收件箱测试：每次部署前、以及每次修改模板或配置后，都向新建的临时邮箱发送测试邮件。
- MXToolbox 健康检查：为每个新域名和新环境都纳入上线前检查清单。
什么时候该用专业的事务性邮件服务
只要你的应用会发出任何用户必须收到才能继续使用的邮件——验证链接、密码重置，以及为完整的注册与支付流程收尾的购买确认——你就应该从第一天起使用专业的事务性邮件服务商。成本很低（每月几万封以内往往免费），可靠性远胜自建 SMTP，而送达基础设施——带信誉管理的共享 IP 池、自动 DKIM 签名、退信与举报处理——由专门以"把邮件送进收件箱"为工作内容的团队维护。
最常见的自建错误，是把邮件服务器跑在与 Web 应用相同的 IP 上，或者使用廉价主机商捆绑的 SMTP 服务。这类 IP 会被 Spamhaus 等服务例行加入黑名单，因为这些托管环境和不良行为者共享。迁移到专业事务性服务商通常只需一个下午的工作量，对送达率的正面影响立竿见影。这是小团队能做的最高杠杆的基础设施改进之一。注重隐私的团队还应参考电子前沿基金会关于在涉及邮件时如何负责任地处理用户数据的建议。此外，在创建新账户时通过 Have I Been Pwned 对照已知泄露数据库核查地址，也能补强你的反欺诈手段。