如何监控 MX 记录和邮件服务器健康状况
邮件基础设施是典型 Web 服务中最脆弱且最少被监控的部分之一。MX 记录在供应商迁移时被更改，之后再也没有人检查。SPF 记录持续增长，直到超过 10 次查询的限制后无声失败。DKIM 密钥轮换了，但 DNS 中的公钥从未更新。结果就是间歇性或彻底的投递失败，而任何应用层监控都无法捕捉到这些问题。本指南介绍在 DNS 和 SMTP 层应监控哪些内容，以便在客户察觉之前发现故障。
MX 记录可能出现的问题
MX 记录将发件方指向接收您域邮件的邮件服务器。错误的 MX 记录意味着邮件无法送达。
常见的故障模式：在更换供应商期间更新了 MX 记录，但旧记录未被删除，导致多台服务器相互竞争。MX 主机名拼写错误（如 mailserver.example.com 而非 mailservers.example.com）会悄悄地将所有邮件路由到不存在的服务器。MX 记录指向的主机名没有 A 记录。这些问题都会导致部分或完全的投递失败，收件箱端的测试能捕捉到，但仅依赖 DNS 的检查则无法发现。
值得监控的四种 DNS 记录
以下四种 DNS 记录共同覆盖了邮件健康状况的配置层面。请对每个发件域都监控这四项。
- MX：邮件服务器本身。当记录意外变更，或解析出的主机名没有 A 记录时发出告警。
- SPF（根域上的 TXT）：哪些服务器被授权发送邮件。在记录变更或嵌套 DNS 查询超过 10 次时发出告警（这是送达率的杀手）。
- DKIM（
._domainkey 上的 TXT） ：用于验证出站签名的公钥。在记录变更时发出告警；缺失 DKIM 会导致大多数服务商降低信任度。 - DMARC（_dmarc 上的 TXT）：处理 SPF 和 DKIM 失败的策略。在记录变更或策略过于宽松（生产环境中 p=none）时发出告警。
DNS 之外的 SMTP 层检查
DNS 层监控能捕捉配置错误。SMTP 层监控则能捕捉到配置正确但实际未运行的邮件服务器。两者缺一不可。
检查方法：在 25 或 587 端口与邮件服务器建立 TCP 连接。读取 SMTP 横幅（220 mail.example.com ESMTP）。干净地关闭连接。每小时执行一次。该检查轻量级，能捕捉服务器已崩溃但 DNS 仍指向它的情形。如果您使用 STARTTLS，请在 587 端口加上 TLS 验证；大多数现代邮件服务器都支持。
端到端的投递监控
DNS 和 SMTP 检查能告诉您基础设施是否在运行。端到端检查则告诉您邮件是否真的被投递。以下两种模式覆盖了常见场景。
- 往返测试：从您的应用向您可控的邮箱（例如 Gmail 地址、Mailosaur 收件箱或内部地址）发送一封测试邮件。验证它在几分钟内送达。
- 外部工具：GlockApps、MXToolbox Inbox Insight 和 Mail-Tester 等服务可针对各大邮箱服务商对送达率进行评分。如果邮件是重要的流量来源，值得每月运行一次。
- 客户反馈环路：将一个专用地址订阅到您自己的营销列表中。如果该测试地址不再收到您的邮件，那么客户也一样收不到。
捕捉 SPF 10 次查询失败
包含超过 10 次 DNS 查询（计入所有 includes、redirects 以及 a/mx 机制）的 SPF 记录会被接收邮件服务器悄悄拒绝。经典的故障模式：每个您授权代发邮件的新 SaaS（Mailchimp、Customer.io、Sendgrid）都会被加入 SPF includes。在加入第 11 个之后，送达率就会无声下降。
请监控 SPF 查询次数，而不仅是记录内容。dmarcian 和 Postmark 的 SPF 测试工具都会报告该次数。在 8 次时就发出告警，以留出余量。如果接近上限，请将记录扁平化（用 include: 指令解析出的 IP 替换它）。使用自动化维护扁平化版本；手动扁平化容易随时间漂移。
邮件基础设施的监控配置
最低限度有用的配置：apex 域上的 MX 监控、SPF 监控（TXT 记录内容 + 查询次数）、您实际使用的选择器上的 DKIM 监控、_dmarc 上的 DMARC 监控，以及主邮件服务器 587 端口上的 SMTP 横幅监控。每天再增加一次到您实际查看的邮箱的端到端往返测试。总计：六个监控。总覆盖范围：邮件故障面的大部分内容。Pro 套餐下每月总成本：远低于您喝咖啡的开销。
