如何部署 DMARC，避免拦截企业发票与系统邮件
发布策略不代表所有发信流程都正常
企业邮件不仅来自员工邮箱，也来自会计软件、网站表单、销售平台和通讯服务。若未盘点这些来源便启用 DMARC reject，部分真实业务邮件可能遭拒，而员工主邮箱仍正常运行。
目标是有依据地确认获授权的来源并识别未经授权的来源，而不是一天内把 DNS 参数设得最严格。下述流程适用于受控部署，具体操作应按企业邮箱与 DNS 服务商调整。
SPF 通过后仍需确认对应哪个域名
DMARC 以收件人可见的 From 域名为基准，依靠通过验证且满足对齐条件的 SPF 或 DKIM。SPF 涉及发信来源及信封发件人域名，DKIM 涉及数字签名和签名域名。服务商域名验证通过，若未与 From 对齐，并不等于 DMARC 通过。
应检查真实测试邮件中的 Authentication-Results 及被验证域名，不能只看一个 pass 字样。none 不要求额外的 DMARC 处置，quarantine 与 reject 则请求更严格处理。收件方仍执行自身过滤规则，因此任何策略都不保证每封邮件进入收件箱。
修改 DNS 前建立发信来源清单
每个来源记录业务负责人、From 域名、服务商、支持的 DKIM 或 SPF 设置、约略发送量及月末开票等关键周期，并保存外部实际收到的样本。找不到负责人的来源应列为待核实，不能因为出现在报告里就自动放行。
应同时检查主域名和子域名，特别是通过外部服务使用公司 From 地址的旧系统。独立子域名有助于划分责任和测试，但必须确认父域名策略的继承关系，不能假定子域名总是独立。
按证据推进，而不只按天数推进
Microsoft 建议先监测、解决合法来源的问题，再逐步收紧。实际执行时应指定汇总报告接收者、审核者及升级前必须解决的问题。观察期应覆盖关键业务周期，不能在两天没有发票发送的情况下就判断准备就绪。
企业可自行设定门槛，例如关键来源均已测试、合法失败项已有整改负责人、支持团队掌握回退流程。这些是流程管理建议，不是服务商认证标准，也不是所有企业适用的固定天数。
示例：员工邮件通过，发票邮件却失败
假设 Microsoft 365 邮件通过，但会计平台使用与 From 不对齐的服务商 DKIM 域名签发票邮件。若 SPF 也未通过并对齐，这些邮件便无法通过 DMARC。应检查平台支持的发信域名或 DKIM 配置，而非为全部邮件设置宽泛例外。
修复后，将不含真实客户数据的发票样本发送至适合该流程的多个外部测试邮箱，检查验证结果、接收及回复。转发邮件需单独分析，因为转发可能改变 SPF 等结果，验证失败不自动等于伪造。
准备回退方案与长期责任人
变更前保存原 DNS 值、批准人、变更时间，并建立未收到发票或验证码的反馈渠道，明确 DNS 修改人与服务商联系人。缓存可能使回退无法立即影响所有收件方，仍需持续验证实际投递。
DMARC 针对邮件中的域名使用，不能替代 MFA、供应商收款账户变更核验或防账户被盗措施。新增发信服务时也应重新检查。Chawinnix 网站列有 IT 与安全服务，可携发信清单、测试证据和变更计划咨询。
