mail-deliverability-audit

“客户说没收到邮件”这句话背后是四种完全不同的故障：① 根本没发出去（认证失败，SMTP 硬拒）② 发出去了但进了垃圾箱（声誉 / 内容 / 互动率）③ 发到了但被转走了（转发链路断了 SPF）④ 地址根本不存在（名单质量，与你无关）。只有 ① 和 ③ 跟 DNS 有关。上来就改 SPF 记录，是这类问题里代价最高的误判 —— 改错一次，整域邮件直接停发。所以这个技能先归因、再动手，按六层往下走，上一层出现 FAIL 就不许往下：1. 解析器层：本机 DNS 通不通、递归是否被劫持 2. SPF 层：语法、查询数上限 10、void 查询上限 2、include 链、~all 与 -all 的区别 3. DKIM 层：selector 是否真实存在、密钥长度、body hash 与 canonicalization 4. DMARC 层：p / sp / np 三段策略、rua 授权、对齐模式（relaxed / strict）5. 基础设施层：PTR 与 HELO 是否双向一致（FCrDNS）、发信 IP 是否在 Spamhaus 等名单 6. 扩展记录层：MTA-STS、TLS-RPT、BIMI、_report._dmarc 的第三方授权包里三件事：- references/auth-playbook.md —— 从零配好一条发信域，顺序与不可越过的判据- references/triage-tree.md —— 症状 → 归属层 → 第一条要跑的命令- references/failure-library.md —— 真实故障：带原话报错、真病因、验证命令- scripts/ 三个只读脚本：auth_audit.py（六层体检）、bounce_triage.py（一封退信为什么被拒）、dmarc_report.py（谁在用你的域发信）边界（这一条请先读）：不发信、不测试投递、不查实时黑名单、不改任何 DNS 记录、不登录你的邮件服务商后台。全程只读。所有结论都带一条你可以自己重跑的复现命令 —— 你不必相信它，你可以验证它。

存档时间线

版本索引永久保留；内容副本只保留最新 1 份，更早版本仅留索引与哈希（存档时间线的证据链不会因此断裂）。

下载存档内容副本

相关资产