本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 遵守 Amazon SES 中的 DMARC 身份验证协议 基于域名的邮件认证、报告和一致性 (DMARC) 是一种电子邮件认证协议，它使用发件人策略框架 (SPF) 和 DomainKeys 识别邮件 (DKIM) 来检测电子邮件欺骗和网络钓鱼。为了符合 DMARC 的要求，消息必须通过 SPF 或 DKIM 进行身份验证，但理想情况下，当两者都与 DMARC 结合使用时，您将确保您的电子邮件发送获得尽可能高级别的保护。 让我们简要回顾一下每种方法的作用，以及 DMARC 是如何将它们联系在一起的： + **SPF** – 标识哪些邮件服务器可以代表您的自定义 MAIL FROM 域，通过 DNS 使用的 DNS TXT 记录发送邮件。收件人邮件系统参考 SPF TXT 记录，以确定来自您自定义域的消息是否来自授权的消息发送服务器。基本上，SPF 的设计初衷是帮助防止欺骗，但实际上存在 SPF 容易遭受的欺骗技术，这就是为什么您还需要结合 DMARC 使用 DKIM 的原因。 + **DKIM** – 在电子邮件标头中为您的出站消息添加数字签名。接收电子邮件系统可以使用此数字签名来协助验证传入的电子邮件是否由该域拥有的密钥签名。但是，当接收电子邮件系统转发消息时，消息的信封会被更改，从而使 SPF 身份验证失效。由于数字签名是电子邮件标头的一部分，会随电子邮件消息一同保留，因此即使在邮件服务器之间转发消息（只要邮件内容未被修改），DKIM 也能发挥作用。 + **DMARC** – 确保域与至少一个 SPF 和 DKIM 保持一致。仅使用 SPF 和 DKIM 并不能确保发件人地址经过身份验证（这是您的收件人在其电子邮件客户端中看到的电子邮件地址）。SPF 仅检查 MAIL FROM 地址中指定的域（您的收件人看不到此域）。DKIM 仅检查 DKIM 签名中指定的域（您的收件人也看不到此域）。DMARC 通过要求 SPF 或 DKIM 上的域一致性正确来解决这两个问题： + 为了使 SPF 通过 DMARC 一致性检查，发件人地址中的域必须与 MAIL FROM 地址（也称为 Return-Path 和 Envelope-from 地址）中的域匹配。在转发邮件时，这几乎不可能实现，因为转发邮件会删除原始的发件人地址信息；在使用第三方批量电子邮件提供商发送邮件时也不可能实现，因为 Return-Path（MAIL FROM）用于处理退信和投诉，而提供商（SES）会使用他们自己的地址来跟踪这些退信和投诉。 + 为了使 DKIM 通过 DMARC 一致性检查，DKIM 签名中指定的域必须与发件人地址中的域相匹配。如果您使用代表您发送邮件的第三方发件人或服务，则可以通过确保第三方发件人已正确配置为使用 DKIM 签名，并且已在域中添加了相应的 DNS 记录来实现。然后，接收邮件服务器将能够验证由您的第三方发送的电子邮件，就好像该电子邮件是由授权使用域内地址的人发送的邮件一样。 **与 DMARC 协同运行** 我们在上面讨论的 DMARC 一致性检查展示了 SPF、DKIM 和 DMARC 是如何协同工作的，以增加对您的域的信任以及确保将您的电子邮件传送到收件箱。DMARC 通过确保收件人看到的发件人地址已通过 SPF 或 DKIM 进行身份验证，来实现这一目标： + 如果所述的 SPF 或 DKIM 检查中的一个或两个都成功，则消息通过 DMARC 验证。 + 如果所述的 SPF 或 DKIM 检查均失败，则邮件将无法通过 DMARC 验证。 因此，为了让 DMARC 能够最大限度地对您发送的电子邮件进行身份验证，SPF 和 DKIM 都是必不可少的，通过同时使用这三者，有助于确保您的发送域得到全面保护。 DMARC 还允许您通过设置的策略，指示电子邮件服务器在 DMARC 身份验证失败时如何处理电子邮件。下一节（[对域设置 DMARC 策略](#send-email-authentication-dmarc-dns)）将对此进行解释，其中包含有关如何配置您的 SES 域，从而使您发送的电子邮件同时通过 SPF 和 DKIM 符合 DMARC 身份验证协议的信息。 ## 对域设置 DMARC 策略 要设置 DMARC，您必须修改域的 DNS 设置。域的 DNS 设置应包括指定域的 DMARC 设置的 TXT 记录。向 DNS 配置中添加 TXT 记录的过程取决于您使用的 DNS 或托管提供商。如果您使用 Route 53，请参阅《Amazon Route 53 开发人员指南》**中的[使用记录](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)。如果使用的是其他提供商的产品，请参阅提供商的 DNS 配置文档。 您创建的 TXT 记录的名称应为 `_dmarc.example.com`，其中 `example.com` 是域。TXT 记录的值包含应用于域的 DMARC 策略。以下是包含 DMARC 策略的 TXT 记录的示例： | Name | Type | 值 | | --- | --- | --- | | \$1dmarc.example.com | TXT | "v=DMARC1;p=quarantine;rua=mailto:my\$1dmarc\$1report@example.com" | 在前面的 DMARC 策略示例中，该策略要求电子邮件提供商执行以下操作： + 对于任何未通过身份验证的消息，请按策略参数 `p=quarantine` 的指定将其发送到垃圾邮件文件夹。其他选项包括使用 `p=none` 不执行任何操作，或者使用 `p=reject` 直接拒绝消息。 + 下一节将讨论如何以及何时使用这三种策略设置 - *在错误的时间使用错误的策略设置，可能会导致您的电子邮件无法传送，*请参阅[实施 DMARC 的最佳实践](#send-email-authentication-dmarc-implement)。 + 根据报告参数 `rua=mailto:my_dmarc_report@example.com`（*rua* 代表聚合报告的报告 URI）的规定，以摘要形式（即汇总某一时间段内的数据并生成一份报告，而不是为每个事件单独发送报告）发送所有身份验证失败的电子邮件的报告。电子邮件提供商通常每天发送一次此类汇总报告，但具体政策因提供商而异。 要了解更多有关如何为域配置 DMARC 的信息，请参阅 DMARC 网站上的[概述](https://dmarc.org/overview/)。 有关 DMARC 系统的完整规范，请参阅[国际互联网工程任务组（IETF）DMARC 草案](https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/)。 ## 实施 DMARC 的最佳实践 最好是分阶段逐步实施您的 DMARC 策略执行，以免影响其他邮件流。制定并实施一个遵循以下步骤的推广计划。在进行下一步之前，先对每个子域执行这些步骤，最后再对组织中的顶级域执行。 1. 监控实施 DMARC 的影响（p=none）。 + 首先，为一个子域或域创建一个简单的监控模式记录，该记录要求邮件接收组织向您发送他们使用该域观察到的消息的统计信息。监控模式记录是一个 DMARC TXT 记录，其策略设置为无 `p=none`。 + 通过 DMARC 生成的报告将提供通过和未通过这些检查的消息的数量和来源。您可以轻松地了解您的合法流量受这些检查覆盖的情况。您会看到转发的迹象，因为如果内容被修改，转发的消息将无法通过 SPF 和 DKIM 检查。您还将开始看到发送了多少欺诈性消息，以及这些消息是从哪里发送的。 + 此步骤的目标是了解在实施接下来的两个步骤中的任何一个时，哪些电子邮件会受到影响，并确保任何第三方或授权发件人调整其 SPF 或 DKIM 策略以保持一致。 + 最适合现有域的使用。 1. 请求外部邮件系统隔离未通过 DMARC 的邮件（p=quarantine）。 + 当您认为您所有或大部分的合法流量均已通过 SPF 或 DKIM 实现了域对齐，并且您了解了实施 DMARC 的影响后，您可以实施隔离策略。隔离策略是一种 DMARC TXT 记录，其策略设置为隔离 `p=quarantine`。通过这样做，您要求 DMARC 接收方将您域下未能通过 DMARC 的邮件放入本地等同于垃圾邮件文件夹的位置，而不是您客户的收件箱。 + 最适合用于在第 1 步期间已经分析了 DMARC 报告的域转换。 1. 请求外部邮件系统不接受未通过 DMARC 的邮件（p=reject）。 + 实施拒绝策略通常是最后一步。拒绝策略是指其策略设置为拒绝 `p=reject` 的 DMARC TXT 记录。当您这样做时，您要求 DMARC 接收方不接受未能通过 DMARC 检查的消息，这意味着这些消息甚至不会被隔离到垃圾邮件文件夹中，而是会被直接拒绝。 + 当使用拒绝策略时，由于拒绝会导致 SMTP 退信，您将能够确切地知道哪些消息未能通过 DMARC 策略。而使用隔离策略时，汇总数据会提供有关通过或未通过 SPF、DKIM 和 DMARC 检查的电子邮件百分比的信息。 + 最适合已完成前两个步骤的新域或现有域。 ## 通过 SPF 遵守 DMARC 要使电子邮件基于 SPF 遵守 DMARC，必须满足以下两个条件： + 该消息必须基于您已发布到自定义 MAIL FROM 域的 DNS 配置中的有效 SPF（类型 TXT）记录，通过 SPF 检查。 + 电子邮件标头中收件人地址的域必须与 MAIL FROM 地址中指定的域或其子域一致（匹配）。为了实现与 SES 的 SPF 对齐，域的 DMARC 策略不得指定严格的 SPF 策略（aspf=s）。 要满足上述要求，请完成以下步骤： + 通过完成 [使用自定义 MAIL FROM 域](mail-from.md) 中的过程设置自定义 MAIL FROM 域。 + 确保您的发送域使用宽松的 SPF 策略。如果您尚未更改域的策略遵守方式，它将默认使用宽松的策略，就像 SES 一样。 **注意** 您可以在命令行中输入以下命令，将 `example.com` 替换为您的域名，从而确定您的域的 DMARC 与 SPF 的符合情况： ``` dig TXT _dmarc.example.com ``` 在此命令的输出中，在 **Non-authoritative answer** 下查找以 `v=DMARC1` 开头的记录。如果此记录包含字符串 `aspf=r`，或者 `aspf` 字符串根本不存在，则您的域为 SPF 使用宽松遵守。如果记录包含字符串 `aspf=s`，则您的域为 SPF 使用严格遵守。您的系统管理员需要从域的 DNS 配置的 DMARC TXT 记录中删除此标签。 或者，你可以使用基于网络的DMARC查询工具，例如 [dmarcian网站上的DMARC In](https://dmarcian.com/dmarc-inspector/) spector或网站上的 [DMARC检查工具](https://mxtoolbox.com/dmarc.aspx)来确定你的域名与SPF的政策一致性。 MxToolBox ## 通过 DKIM 遵守 DMARC 要使电子邮件基于 DKIM 遵守 DMARC，必须满足以下两个条件： + 消息必须具有有效的 DKIM 签名并通过 DKIM 检查。 + DKIM 签名中指定的域必须与发件人地址中的域一致（匹配）。如果域的 DMARC 策略指定了 DKIM 的严格遵守方式，则这些域必须完全匹配（SES 默认使用严格的 DKIM 策略）。 要满足上述要求，请完成以下步骤： + 通过完成 [Amazon SES 中的 Easy DKIM](send-email-authentication-dkim-easy.md) 中的过程设置 Easy DKIM。使用 Easy DKIM 时，Amazon SES 会自动对您的电子邮件签名。 **注意** 除了使用 Easy DKIM 以外，您也可以[为邮件手动签名](send-email-authentication-dkim-manual.md)。但是，如果您选择这样做，请务必小心，因为 Amazon SES 不验证您构建的 DKIM 签名。因此，我们强烈建议您使用 Easy DKIM。 + 确保 DKIM 签名中指定的域与发件人地址中的域一致。或者，如果从发件人地址中域的子域发送，请确保您的 DMARC 策略设置为宽松的一致性。 **注意** 您可以在命令行中输入以下命令，将 `example.com` 替换为您的域名，从而确定您的域的 DMARC 与 DKIM 的符合情况： ``` dig TXT _dmarc.example.com ``` 在此命令的输出中，在 **Non-authoritative answer** 下查找以 `v=DMARC1` 开头的记录。如果此记录包含字符串 `adkim=r`，或者 `adkim` 字符串根本不存在，则您的域为 DKIM 使用宽松遵守。如果记录包含字符串 `adkim=s`，则您的域为 DKIM 使用严格遵守。您的系统管理员需要从域的 DNS 配置的 DMARC TXT 记录中删除此标签。 或者，你可以使用基于网络的DMARC查询工具，例如d [marcian网站上的DMARC In](https://dmarcian.com/dmarc-inspector/) spector或网站上的 [DMARC检查工具](https://mxtoolbox.com/dmarc.aspx)来确定你的域名与DKIM的政策一致性。 MxToolBox