Google Workspace DMARC 设置有四个相互关联的阶段：确认谁发送该域，发布适用的 SPF 和 DKIM 记录、启动所选域的DKIM签名并在依赖DMARC策略之前验证生成的消息。
DNS发布和签名是单独的观察。当服务尚未签名时， DKIM密钥可以是可见的，并且当网站或计费应用程序使用不同的提供商时，员工邮件可以正确进行身份验证。遵循每项重要服务的完整路线。
检查所选域和现有配置
确认所选域、其权威DNS主机、当前记录以及任务所需的 Google 管理权限。保存现有配置。
检查是否已存在有效的SPF策略和工作自定义域DKIM签名。不要仅仅为了从第一步遵循新指南而重新生成工作密钥或替换既定策略。
为员工邮件、别名或辅助域、网关和外部应用程序创建路由列表。对于每个重要身份，计划单独的接收消息测试。
包括发送到 Workspace 外部的服务
Google Workspace可能会处理员工邮件，而网站、会计系统和支持平台则使用其他提供商。工作区设置无法自动建立所有权或 结盟 对于那些服务。
要求团队说出每个面向客户的发件人及其企业主的名称。包括少量但重要的邮件，例如登录链接和付款收据。然后要求实际应用程序提供验证结果，而不是假设成功的Gmail测试涵盖了该结果。
确保某人拥有该域的DNS帐户和报告目标。当前承包商控制到达无人阅读的邮箱中的记录或报告时，身份验证变得难以维护。
发布适当的SPF政策
Google 当前记录的域发送**仅通过Google Workspace ** 的示例是：
v=spf1 include:_spf.google.com ~all仅当假设符合时才使用它。对于混合服务域，请在更改其单一SPF策略之前检查现有权限和实际信封标识。使用其提供商自己的信封域的单独应用程序可能需要不同的支持对齐方法。
这 ~all 限定符会为其他不匹配的源生成SPF softfail 。 Softfail 不是DMARC的通过SPF结果，并且它不会强制每个接收者将邮件放入垃圾邮件中。接收器处理和单独的DMARC决策仍然相关。
检查SPF评估路径，包括嵌套依赖项。对顶级记录中可见的包含进行计数是不够的。
生成并发布所选域的DKIM密钥
在 Google 管理控制台中，导航至“应用”、 Google Workspace ”、 Gmail ，然后导航至“验证电子邮件”。选择正确的域。如果是新的签名设置，请使用生成新记录和支持的密钥设置。
谷歌提供了一个 2048 位密钥 DNS提供商支持的地方。默认 选择器 是 谷歌;现有的选择器冲突需要受支持的不同选择器而不是覆盖。
从控制台复制生成的DNS主机名和公钥值。在权威DNS区域中发布该 ** TXT ** 记录。常见的相对所有者名称是 谷歌。 _domainkey，但使用所选域的生成值和DNS编辑器的命名模型。
私钥未在DNS中发布。不要粘贴文章中缩短的示例密钥、重复使用另一个域的密钥或默默地替换另一个服务的选择器。
检查公共答案中的全名：
dig TXT google._domainkey.example.com +short此命令是说明性的：替换域以及选择器（如果适用）。公开TXT答案表明密钥已发布，而不是 Workspace 已开始签名。
开始签名并检查收到的消息
发布并检查密钥后，返回到所选域的身份验证电子邮件设置并开始身份验证。查看结果状态。
Google 的说明描述了与其他Gmail或Google Workspace收件人进行的测试，而不是向自己发送消息。在收件人处打开原始消息并检查受信任的身份验证结果并 DKIM-Signature.
验证签名域、选择器以及与可见的发件人域的对齐情况。不同域的通行证不会建立您域的对齐路径。对相关别名、辅助域、网关和应用程序路由重复测试。
- 层： DNS ；要回答的问题：生成的公钥是否以预期名称发布？
- 层：工作区；要回答的问题：是否为所选域启用了签名？
- 层：收到邮件；要回答的问题：相关签名是否在完整路线之后进行验证和对齐？
- 层：业务工作流程；回答问题：服务用户发送的消息实际上依赖于什么？
- ovider 设置和DNS缓存可能需要一些时间。 Google 还记录了新启用的Gmail服务在生成密钥之前的准备延迟。使用实际状态和当前指导；不要承诺统一的完成时间。
发布并验证DMARC策略
对于新监控的域，同域上报示例为：
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com发布在适用的 _dmarc 姓名、使用经批准的工作收集地址并确认报告到达和处理。 Google 目前建议在DMARC设置步骤之前允许至少 48 小时的SPF / DKIM操作。该准备期本身并不意味着准备好执行更强有力的政策。
如果域已经有策略，请对其进行评估，而不是自动用监控替换它。这 DMARC记录 工作流程解释了如何将DNS验证加入到真实消息证据中。
随着服务的变化保持覆盖范围
根据发送者清单及其关键流程测试检查实施情况。一个域的设置并不能证明每个辅助域或外部通知服务的状态。
需要明确访问工作区和DNS管理帐户， 一个记录 批准的变更、维护的选择者名单和负责任的报告审查流程。定义团队如何处理新引入的应用程序或废弃的服务。
保留域认证和帐户安全之间的区别。受损的授权帐户可以发送经过身份验证的消息。 DMARC通行证也不能保证收件箱的放置或确定业务请求是否合法。
实用的外卖
将DNS证据、签名状态和接收消息结果保留在同一接受记录中。这使得可以将发布问题与签名问题或仍需要配置的单独应用程序区分开来。
保持项目的部分成功
在书面案例 GW-01 中，假设user@example.com具有传递签名d=example.com和s=google.该规定的消息具有对齐的DKIM路径。使用相同发件人域的发票应用程序尚无可信的接收消息证据。其DKIM和SPF结果仍未知。将员工邮件标记为仅在假设的情况下有条件地证明，并让发票路由未与其应用程序所有者解决。本指南未测试任何 Google 租户、消息、 DNS记录或签名操作。
保留执行边界
RFC 9989 第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。