要设置 DMARC 对于Microsoft 365自定义域，建立域的发送路由，配置适当的 SPF 策略，启用自定义域 DKIM 并验证收到的邮件的一致结果。发布DMARC TXT记录 是该序列中的一个步骤。
本指南涵盖通过Microsoft 365发送自定义域。在使用示例之前，请确认 Microsoft 云环境以及任何混合、中继或出站网关安排。在Microsoft 365外部发送的应用程序需要自己支持的身份验证配置，即使它们使用相同的可见发件人域也是如此。
确认域名、 DNS主机和Microsoft环境
确认自定义域、其权威DNS主机、 Microsoft 365环境以及管理签名所需的权限。保存现有的SPF 、 DKIM和 DMARC记录 在更改它们之前。
不要将公共DNS管理与租户的域列表混淆。注册商也可以是DNS主机，但不一定是。在编辑区域之前检查委托的名称服务器。
列出使用该域的每条路由。特别是，将普通Exchange Online发送与使用中继、直接发送、其他SMTP提供程序或出站网关的应用程序区分开来。产品名称本身并不能识别最终签名者。
映射员工邮件和申请邮件
迁移到Microsoft 365不会自动迁移发票应用程序、网站联系表或招聘平台。当通过不同的提供商发送时，这些服务可能仍会显示您的域。
索取一份简单的服务地图：员工邮件、申请邮件和外包通信，每条路线旁边都有一个所有者。需要对关键流程（例如密码重置和计费通知）进行接收消息测试。可交付成果是有效的、负责任的通信，而不是已启用的租户设置的屏幕截图。
配置适用的SPF策略
Microsoft 记录的域发送**仅通过其标准Microsoft 365服务或 GCC** 的示例是：
v=spf1 include:spf.protection.outlook.com -all这是一个范围示例，不能替代现有的混合服务策略。 Microsoft 记录了不同的内容，包括 GCC High/DoD 及其由 21Vianet 运营的服务的域。请遵循适合您的环境的当前说明。
在评估的域中发布一项适用的SPF策略。如果有效的策略已存在，请查看并更新该策略，而不是添加另一个策略 SPF记录。仅包含合理的发送权限，并根据SPF限制检查完整的依赖路径。
发布两个租户生成的DKIM CNAME
Microsoft 365自定义域DKIM使用两个 CNAME 记录。从 Defender 门户的DKIM配置或Exchange Online PowerShell 获取其准确值。不要从旧的命名模板构建目标：Microsoft 记录了多种目标格式，并且生成的值可以包含特定于租户的组件。
在授权的Exchange Online PowerShell 会话中，此只读检查将检索配置的目标：
获取-DkimSigningConfig -Identity example.com |格式-列表已启用、状态、Selector1CNAME、Selector2CNAME如果域没有签名配置，请在期望这些属性存在之前使用 Microsoft 记录的初始配置过程。在 Defender 门户中，相关区域是电子邮件身份验证设置，然后是DKIM 。
发布**两个**生成的CNAME记录，验证其公开答案并通过支持的租户程序启用自定义域签名。 CNAME记录委托验证密钥管理；这不是粘贴私钥或发明的TXT密钥的请求。
仔细检查DNS编辑器的行为。附加区域名称的面板可以将完整输入的主机名转换为重复的名称。在更改记录中保留确切的已发布所有者和目标值。
添加预期的DMARC策略和报告目标
如果域正在开始受监控的部署，则说明性记录位于 _dmarc.example.com 是：
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com该示例假定工作报告目标位于同一域。将其替换为批准的地址并验证收集。外部目标可能需要额外的报告权限。不要仅仅为了匹配这个例子而削弱现有的执行政策。
使用记录创建指南进行发布和验证序列，以及 DMARCbis 查看旧版推出设置时的准备指南。
完整发送路由后验证消息
将受控消息发送给单独的外部收件人并检查那里的原始消息。记录可见的发件人、SPF 评估身份、每个相关的DKIM d= 域和可信DMARC结果。
通过关键应用程序和任何最终出站网关重复测试。如果可见的发件人是您的自定义域，但唯一传递的签名使用不相关的租户身份，请调查自定义域签名和实际路由。如果网关修改了签名内容，请验证该网关之后的结果。
- 检查： SPF策略；保留证据：权威答复和评估发送路线
- 检查： DKIM授权；要保留的证据：确切的 CNAME 和租户配置状态
- 检查：现场签名；保留证据：收到的签名和可信验证结果
- 检查： DMARC ；需要保留的证据：经过一致的路径和观察到的政策背景
- 检查：业务范围；要保留的证据：对组织实际使用的应用程序进行测试
- 记录接受度和持续所有权
批准针对指定服务清单的实施。记录变更批准者、 DNS所有权、关键流程结果和剩余异常。租户的有效签名状态并不表明每个外部应用程序都受到涵盖。
在操作文档中明确云环境。标准云示例绝不能悄然成为政府云指令。定期检查废弃的服务和委托选择器以及当前流量中的故障。
保留在更改失败时恢复先前批准状态的能力，同时保留事件证据。最终审查应解释帐户受损和经过身份验证的恶意邮件的剩余风险，而不是承诺DMARC通行证可以确保每封邮件的安全。
实用的外卖
当发布的记录、租户签名状态、接收消息身份和报告路径一致时，设置完成。保留服务清单和异常情况以及变更记录；它们是下一个应用程序或网关更改的基线。
将员工邮件证据与 CRM 异常分开
书面案例 M365-01 假设来自staff@example.org的员工邮件具有可信传递 DKIM签名 与d=example.org.计费 CRM 使用billing@example.org ，但其唯一记录的签名来自不相关的提供商域，并且其SPF结果未知。员工邮件证据不能证明 CRM 结果，并且部分 CRM 证据不能证明完整的DMARC判决是合理的。在域所有者评估实施准备情况之前，CRM 所有者必须识别其支持的一致身份并收集受控的外部消息。这些都是虚构的身份和结果；没有发生租户、 DNS更改或邮件发送。