为邮件域名设置SPF、DKIM和DMARC，防止冒充又不拦下正常邮件

## 修改邮件相关DNS前，先定好审批人和撤回方法 将电子邮件身份验证视为共享基础设施。记录变更可能影响使用同一域的事务邮件、支持系统、营销、内部工具和第三方。 - 确定范围内的发信域、子域、可见的From域和关键业务邮件流。 - 指定一名承担最终责任的域负责人和获授权的DNS操作人员。 - 明确区分每项变更的提出、审查、批准、发布、验证和监测人员。 - 记录当前DNS值、生存时间、依赖关系以及经过测试的回滚值。 - 将变更安排在关键邮件流负责人能够观察结果的时段。 - 未经明确授权且没有恢复计划，不得编辑生产环境DNS。 - 当发信方清单或责任归属证据不完整时，暂停升级。 ## 列出所有用你的域名发信的服务 编写身份验证记录之前，先建立发信方清单。遗漏一项合法服务可能导致政策执行阻止正常邮件，而保留过时的授权会扩大伪造攻击面。 - 列出使用该域发信的每个平台、应用程序、中继、设备和供应商。 - 记录其信封发件人、可见的From域、签名域、IP所有权和责任团队。 - 区分直接发信方与转发、邮件列表和网关路径。 - 注明哪些来源能够使用DKIM签名，哪些依赖SPF对齐。 - 只有在确认已停用的来源不再发送合法流量后，才能将其移除。 - 考虑将风险或责任归属不同的群组隔离到专用子域。 - 使清单与变更记录和身份验证报告保持关联。 ## 写好一条涵盖所有发信方的正确SPF记录 SPF授权允许在信封发件人中使用某个域的系统。它评估建立连接的来源；不会签署内容，也不能单独验证可见的From地址。 - 对每个需要SPF政策的主机名，只发布一项政策。 - 将所有合法发信方合并到该政策中，不能创建重复的SPF记录。 - 仅使用责任发信服务所支持的机制和include项。 - 评估期间，使会查询DNS的机制保持在SPF的10次查询限制内。 - 在接近限制之前，移除冗余include项和未使用的发信方。 - 审慎选择最终的all机制，只有在证明覆盖完整后才收紧该机制。 - 使用代表性发信方验证语法、展开路径、查询次数和结果。 ## 为每个发信服务启用DKIM签名 DKIM允许发信方用私钥对选定的邮件内容签名，接收方则从DNS获取匹配的公钥。签名验证通过，表示已签名内容在传输过程中保持不变，并能标识签名域。 - 按照每个发信方支持的方法，分别生成选择器和密钥对。 - 当发信方和DNS服务均支持时，优先使用强密钥，例如2048位密钥。 - 在发信方指定的选择器位置发布准确的公钥记录。 - 保护私钥，绝不能将其放入DNS、工单、共享文档或日志。 - 只有在公钥记录能够正确解析后，才启用签名。 - 发送一封真实测试邮件，并验证选择器、签名域、签名结果和邮件头覆盖范围。 - 规划基于选择器的密钥轮换，以便在停用旧密钥前验证新密钥。 ## 先用只监测的方式启用DMARC，并阅读它的报告 DMARC评估可见的From域是否与验证通过的SPF或DKIM身份对齐，然后应用域负责人发布的政策。身份验证成功但没有对齐时，DMARC仍可能失败。 - 确认每个合法邮件流通过SPF、DKIM或两者实现对齐。 - 了解宽松或严格对齐哪一种适合域结构和风险。 - 在规定的政策主机名发布DMARC记录，并使用获授权的报告接收位置。 - 先采用监测政策，同时识别合法和未授权的来源。 - 保护报告邮箱并限制访问，因为报告可能暴露基础设施细节。 - 按来源、身份验证结果、对齐情况、邮件量和业务负责人对失败进行分类。 - 在所有重要合法邮件流都得到核对之前，不得进入执行阶段。 ## 逐步收紧DMARC，同时不拦下正常邮件 只有当证据表明合法邮件持续保持对齐时，才能从观察转向隔离和拒收。执行是一项风险控制决策，不是一次性的DNS格式设置任务。 - 为每个阶段定义通过率、未知来源和业务影响标准。 - 提高政策严格程度之前，先修复合法邮件的失败。 - 在支持且有助于降低风险时，采用有限的执行百分比。 - 每次变更后，监测汇总报告、送达错误、支持事件和关键邮件流的健康状况。 - 在整个过渡期间，准备好有文档记录的回滚政策。 - 提高执行力度或更改对齐模式之前，获得责任人的批准。 - 如果合法邮件被拒收、隔离或意外地未通过身份验证，应停止并调查。 ## 每次修改后，检查DNS记录和真实测试邮件 既要确认记录已发布，也要确认邮件的实际行为。DNS记录语法有效，并不能证明每个发信方都在使用该记录，也不能证明DMARC对齐成功。 - 传播完成后，向权威DNS查询SPF、DKIM选择器和DMARC。 - 检查重复记录、被截断的值、错误的主机名和意外继承的政策。 - 通过每条具有代表性的生产路径向多个接收环境发送测试邮件。 - 检查邮件头中的SPF、DKIM、DMARC、域、选择器和对齐结果。 - 既测试普通邮件，也测试转发或中继邮件等重要变体。 - 记录测试路径、时间戳、结果、证据和审查者。 - 发信方、DNS、路由或签名发生任何变更后，都应重复验证。 ## 根据邮件头等证据，查明SPF、DKIM或DMARC失败的原因 依据身份验证结果、DNS响应、邮件头和变更历史进行诊断。不能持续编辑记录，直到测试偶然通过。 - 对于SPF永久错误，检查重复政策、语法、递归include项和10次查询限制。 - 对于DKIM失败，检查选择器名称、复制的密钥材料、签名状态、规范化方式和邮件修改。 - 对于DMARC失败，将可见的From域与SPF和DKIM身份进行比较。 - 对于被阻止的合法邮件，应先确定确切来源，再放宽政策。 - 当生产邮件流受损时，回滚造成影响的最小范围变更。 - 每次修正后，重新测试失败路径和一条未受影响的对照路径。 - 保存原因和修复措施的证据，供未来变更使用。 ## 不只看验证结果，还要关注退信和进入垃圾邮件的情况 SPF、DKIM和DMARC能够减少身份冒用并满足重要的接收方检查，但不能保证邮件进入收件箱。信誉和收件人响应仍是相互独立的信号。 - 监测身份验证通过率，同时监测拒收、延迟、进入垃圾邮件、投诉和退信。 - 维护准确的收件人列表，移除无效或持续投递失败的地址。 - 使邮件量和发信模式与该域已经建立的信誉保持一致。 - 使用真实的发信方身份、相关内容，并提供停止接收非必要邮件的明确方式。 - 按域、邮件流、接收方、内容和部署事件调查突发变化。 - 不要把预热活动或身份验证检查通过视为信誉良好的证明。 - 当证据表明损害仍在持续时，暂停高风险邮件流。 ## 定期检查发信方清单并更换DKIM密钥 服务变更、密钥老化、负责人离职或新发信方绕过审查时，身份验证会逐渐失效。应将其作为周期性控制措施维护，而不是视为已经完成的设置项目。 - 按照明确的周期审查发信方清单、DNS记录、DMARC报告和责任归属。 - 使用能够保留有效签名的重叠期轮换DKIM选择器和密钥。 - 每当include项或发信服务发生变化时，重新验证SPF查询次数。 - 跟踪政策变更、批准情况、已发布值、验证证据和回滚结果。 - 对新来源、通过率下降、报告缺失和突然发生的对齐失败发出警报。 - 在确认相关邮件流已停止活动后，移除过时的授权。 - 随着风险、邮件量或业务用途变化，重新评估子域边界和执行政策。