如何修复错误 550 5.7.509：Exchange Online 中的访问被拒绝

错误 550 5.7.509 与 DMARC 消息身份验证相关，当您发送电子邮件但收件人因 DMARC 失败而拒绝您的电子邮件时，该错误会作为退回邮件收到。确切的错误将如下所示：

550 5.7.509：访问被拒绝，发送域 yourdomain.com 未通过 DMARC 验证，且 DMARC 策略为拒绝

在本教程中，我将向您展示如何轻松修复 Exchange Online 错误。

DMARC 是如何工作的？

DMARC 代表基于域的消息验证、报告和一致性，是一种帮助邮件服务器确定消息是否合法的方法和流程。然后，在发送域上配置的 DMARC 策略将帮助接收邮件服务器如何处理未通过 DMARC 检查的传入邮件。

下图有助于可视化 DMARC 身份验证过程：

总结上图：

1. 用户首先发送一封新邮件，发送邮件服务器将根据公共 DNS 中收件人域中配置的 MX 记录处理该邮件并将其发送到收件人的邮件服务器。

2. 收件人的邮件服务收到邮件后将对域执行 3 种不同的检查：

• • 首先，收件人服务器将检查发件人服务器的 IP 地址是否与公共 DNS 中 SPF 记录中的授权服务器的 IP 地址相匹配。
• 其次，收件人的服务器会将邮件标头中的加密 DKIM 签名与公共 DNS 中的 DKIM 记录进行匹配。
• 最后，收件人的服务器将检查公共 DNS 中发件人域的 DMARC 记录。如果第一次或第二次检查失败，该记录将确定如何处理该消息。

3. 第三，如果 SPF 和 DKIM 检查均通过，DMARC 将结果通过，邮件将发送到收件人的邮箱。如果 DMARC 失败，根据发件人公共 DNS 中配置的 DMARC 策略，邮件将被发送到隔离区或被拒绝，并向发件人发送包含错误 550 5.7.509 的 NDR。

4. 最后，如果发件人的 DMARC 记录配置为聚合或取证报告，则邮件将以 XML 或纯文本形式发送到所需目的地（通常是专用邮箱或 DMARC 分析平台），其中包含邮件消息的信息。

EasyDMARC 有一个简单易用的 DMARC 报告工具，请查看！

为什么我收到错误 550 5.7.509？

您收到错误 550 5.7.509 的原因是您未经过正确的身份验证，无法代表您的域发送。例如，如果您的域名是 ourcloudnetwork.com 并且您的电子邮件地址受 [电子邮件保护]。您正在使用的邮件服务（例如 Microsoft 365）与公共 DNS 提供商（例如 GoDaddy）中配置的 DKIM 或 SPF 记录不匹配，因此返回失败。

这并不意味着它曾经配置不正确，它可能意味着某些东西已经发生了变化。因此，您应该检查谁有权更改您的公共 DNS 记录，因为第三方提供商通常会请求访问权限（例如 Web 开发人员），而实际上，此访问权限只能由您信任的 IT 提供商进行。

除此之外，您还收到此错误消息，因为您使用“拒绝”设置配置了 DMARC 策略。这是最严格的方法，如果策略未通过，消息将被拒绝，并显示错误 550 5.7.509。

如何修复错误 550 5.7.509

为了解决此错误，我将突出显示您应在您的环境中执行的所有必要步骤，以便电子邮件被正确标记为合法并通过 DMARC 检查。请按照以下步骤操作：

第 1 步：识别您的发送服务器

有时，特别是如果您没有参与组织邮件解决方案的设置，发送服务器与您用于访问电子邮件的服务器不同。例如，下图描述了发件人使用 Exchange Online 作为其主电子邮件服务器的情况。在 Exchange Online 中，配置了一个发送连接器，该连接器将出站邮件定向到第 3 方邮件筛选服务，然后再将其转发给收件人。

因此，为 SPF 和 DKIM 正确配置此邮件过滤服务至关重要，这将允许 DMARC 通过。我建议您将邮件流程转换为图表，以便其他需要熟悉它的人变得简单。

第 2 步：查看并修复您的 SPF 记录

一旦您熟悉了邮件流程，首先要检查的是您的 SPF 记录是否已正确配置为代表您的域发送的邮件服务。如果您愿意，您可以通过向默认情况下不会拒绝您的邮件的服务（例如个人 GMail 帐户）发送电子邮件并查看邮件属性来测试您的 SPF 检查当前是否通过。以下是我从欺骗服务发送给自己的测试电子邮件的示例：

有几种方法可以检查您的 SPF 记录的配置方式。最快的方法是在工作站的命令行中使用nslookup工具。尝试运行以下命令并将“ourcloudnetwork.com”更改为您的电子邮件域：

nslookup -type=txt ourcloudnetwork.com

这是我的结果：

如果此命令未返回包含 v=spf1 的结果，那么您就知道这是问题的一部分。如果有人在您的 DNS 注册商处进行更改（例如重置所有记录或更改名称服务器），则 SPF 记录可能会很快被覆盖或删除。

确保您的 SPF 记录配置正确。 SPF 记录应该是基于 txt 的 DNS 记录，并以 v=spf1 开头，以 -all 结尾（最好）。应存在 include: 部分，其中包括发送邮件服务器的公共 IP 或邮件提供商提供的特定 spf 子域，例如，Microsoft 365 的 SPF 记录为 spf .protection.outlook.com。

步骤 3. 检查并修复您的域的 DKIM

DKIM 的目标与 SPF 的目标类似，验证发件人是否有权代表发送域进行发送。尽管它的工作原理确实有点不同。 DKIM 使用加密技术使用来自授权发送服务器（在许多情况下为 Microsoft 365）的私钥对电子邮件进行签名，然后邮件收件人将使用发送域的公共 DNS 服务器发布的公钥来验证邮件。如果电子邮件附加的签名在传输过程中未被修改，则该邮件将通过 DKIM 验证。

在某些情况下，可能未（或曾经）配置过 DKIM。除此之外，如果邮件服务发送电子邮件时未签署 DKIM（无论是合法还是恶意），DKIM 将返回为 none (dkim=none)。这仍然可能导致收件人由于完全缺乏身份验证而拒绝电子邮件。

如果邮件服务使用 DKIM 签署电子邮件，但公钥与解密签名不匹配，则您的电子邮件标头中会出现以下错误：

要修复您的 DKIM 记录，您应该遵循电子邮件提供商提供的指南，因为从电子邮件服务端启用 DKIM 签名的步骤对于每个提供商而言都不同。对于 Microsoft 365，您应执行以下步骤：

登录 Microsoft Defender 管理门户> 策略和规则 > 威胁策略 > 电子邮件身份验证设置 > DKIM > 选择您的域并启用 DKIM

此时，您将获得需要添加到公共 DNS 提供商的必要 DNS 记录。

此时，对于大多数人来说，如果您正确配置了 SPF 和 DKIM，那么您应该不会再收到退回邮件，并且邮件应该会被退回。交付成功。但是，如果您使用其他第三方服务发送邮件，或者仍然收到 NDR 邮件，请继续执行后续步骤。

步骤 4. 将 DMARC 恢复为“无”并配置 DMARC 报告

从根本上来说，当您的 DMARC 策略配置为拒绝 (dmarc=reject) 时，550 5.7.509 错误将作为退回电子邮件返回。因此，最简单的解决方案（短期）是将 DMARC 策略设置回无，同时继续排除故障并解决任何问题。

此时，SPF 和 DKIM 的步骤 2 和步骤 3 仍然最相关，但是，您可能正在使用第三方邮件服务来发送邮件来自您的域的电子邮件。这方面的一些例子可以是费用系统、人力资源系统或营销系统。

DMARC 还支持在电子邮件未通过 DMARC 记录检查时进行报告。这允许您作为管理员查看这些报告电子邮件，以确定代表您的域发送电子邮件的服务的配置问题。不幸的是，大多数电子邮件服务没有内置的分析服务，但是 DMARC 报告可以发送到任何邮件以供阅读和解释，理想情况下应使用第三方服务进行准确的报告分析。

以下是策略设置为无的 DMARC 记录示例：

v=DMARC1; p=none; pct=100; [email ; fo=1"

要分解这个政策：

• P=none - 这会将 DMARC 策略设置为无，建议收件人不对未通过 DMARC 检查的电子邮件执行任何操作。
• pct=100 - 这意味着该政策将适用于 100% 收到的电子邮件。
• rua=%email% - 这是您希望接收 DMARC 故障汇总报告的目标。

步骤 5. 将 DMARC 策略重新设置为“拒绝”

有时，DMARC 部署最困难的部分是了解何时将 DMARC 策略更改回拒绝 (p=reject)。太早这样做可能会导致电子邮件被退回并不得不重新发送，但时间太长会使您进一步暴露于被恶意行为者欺骗的风险。

我建议您最多留出 1 个月的时间来验证您是否已捕获并处理通过 DMARC 报告收到的所有信息。这允许捕获并解决最多每月发送电子邮件的任何服务。