企业邮箱DNS基础检查：MX、SPF、DKIM与DMARC各看什么
收信路径与发信身份是两件事
企业邮箱接入后，网站通知能否正常发送，不能只看MX记录。MX主要描述域名的收信服务器选择；发出的邮件还涉及发送平台、信封发件域、签名域与用户看到的From域。把这些信息逐项对应，才能避免“邮箱能收信，所以发信设置也正确”的误判。
开始检查前，列出全部合法发信来源，例如办公邮箱、网站事务通知和客户支持系统。每个平台记录使用的域名、用途和负责人。遗漏一个低频发送系统，可能直到它发出重要通知时才暴露认证问题。不要为了未知来源随意扩大授权，先确认它是否仍由业务使用。
SPF检查发送来源是否获得授权
SPF通过DNS记录表达某个域名允许的发送来源，验证时使用的是协议定义的发件身份，不应直接等同于邮件界面显示的From名称。配置应以实际邮件平台提供的值为基础，并核对多平台是否需要合并进同一份有效策略。RFC 7208
常见错误是为每个平台新建一条独立的SPF策略，或者不断叠加include却不检查查询限制。修改前应确认已有记录的用途，避免覆盖仍在发信的平台。授权值也不能从收到邮件的服务器地址反推，因为收信节点和发信出口未必相同。
假设网站通知由独立服务发送，办公邮件由另一平台发送。应分别验证它们的实际信封域和授权关系，而不是认为主域名的一条记录必然覆盖所有子域。测试结果应来自各平台真正发出的一封邮件。
DKIM需要DNS公钥与实际签名配合
DKIM由发送系统给邮件添加签名，接收方根据签名中的域和选择器查找对应公钥。DNS中存在一条公钥记录，只能证明记录已经发布；如果发送系统尚未启用签名，或使用了另一个选择器，真实邮件仍可能验证失败。
应按照平台提供的选择器和完整记录名部署，注意DNS界面是否自动补全域名。完成后查看测试邮件的认证结果，确认签名由预期域名产生。密钥轮换时保留新旧记录的过渡关系，遵循邮件平台的切换流程，不要仅因新记录已出现就立即删除旧记录。
Google的发件人指南将SPF、DKIM与DMARC纳入邮件身份验证要求，并说明这些配置与投递结果的关系；具体要求仍应按照收件方与发送规模核对。Google官方指南
DMARC重点在验证与域名对齐
DMARC把用户可见From域与经过验证的SPF或DKIM身份建立对齐关系。满足对齐要求的SPF或DKIM路径至少有一条通过，才符合相应的通过条件；不能把某处单独出现一个pass就当作整体已通过。RFC 7489
对于尚未梳理完整发信来源的组织，可以按平台指导先观察报告，再逐步实施更强策略。直接启用严格处理而没有验证旧系统，可能让合法通知受到影响。报告地址也需要有人维护，不能只创建一条记录后长期无人阅读。
用收发两端证据结束验收
从每个合法平台向受控的外部邮箱发送测试邮件，记录发送时间、用途和接收结果，并检查认证摘要。收信测试还应覆盖公开邮箱地址是否进入正确账号、备用路由是否符合平台方案。不要把包含私人正文、完整客户地址和访问令牌的原始邮件公开上传。
认证通过有助于建立身份可信度，但不能保证进入收件箱；收件方仍会结合内容、信誉和用户反馈处理邮件。因此，验收应写成“指定平台的测试邮件通过预期认证并成功接收”，而不是承诺所有邮件必达。
保存配置与测试结果后，把新增发信平台纳入变更流程。以后网站搬家、通知系统替换或办公邮箱迁移，都需要重新核对这份来源清单。