☰

由于 DMARC，转发到 Gmail 不适用于来自 Microsoft.com 的电子邮件，但适用于 PayPal.com

tag-icon • tag-icon spf gmail dkim dmarc
由于 DMARC，转发到 Gmail 不适用于来自 Microsoft.com 的电子邮件，但适用于 PayPal.com

我注意到，我无法在 Gmail 和 Yandex.Mail 中收到通过 UNIX 系统转发的某些电子邮件（无需脊髓灰质炎病毒— 不太确定发件人重写方案是否仍然是最佳实践？因为我认为使用 DMARC 时它也必须应用于From:电子邮件本身的实际标头。）来自启用 DMARC 的发件人。

我不太明白到底发生了什么——总是通过的电子邮件包括 PayPal.com，而 Microsoft.com 和其他一些电子邮件被拒绝（只能在本地传送到接收端未实施 DMARC 的系统）。

% echo _dmarc.{microsoft.com,paypal.com} | xargs -n1 dig -t txt | fgrep v=D
_dmarc.microsoft.com.   3302    IN      TXT     "v=DMARC1\; p=reject\; pct=100\; rua=mailto:[email protected]\; ruf=mailto:[email protected]\; fo=1"
_dmarc.paypal.com.      3311    IN      TXT     "v=DMARC1\; p=reject\; rua=mailto:[email protected]\; ruf=mailto:[email protected]"
%

当两个域具有相同的reject策略时——并且谷歌甚至特别提到 PayPal 确实有明确的拒绝政策— 我不太确定是不是我自己的设置出了问题，还是发送方出了问题。有什么想法吗？

这仅仅是因为 SPF 失败与软失败，还是还有其他原因？

% echo {microsoft.com,paypal.com} | xargs -n1 dig -t txt | fgrep v= | sed 's#[^[:space:]]*:[^[:space:]]*#:#g'
microsoft.com.          3332    IN      TXT     "v=spf1 : : : : : : : : : : -all"
paypal.com.             300     IN      TXT     "v=spf1 : : : : : : ~all"
%

以下是 Gmail 对通过转发递送的 PayPal 电子邮件的报告：

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass [email protected] header.s=pp-epsilon1 header.b=K96c6GUZ;
       spf=fail (google.com: domain of [email protected] does not designate 2001:470:7240:: as permitted sender) [email protected];
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=paypal.com
Return-Path: <[email protected]>

答案1

DMARC 策略保护From:标头中使用的域：要通过 DMARC 检查，必须对齐DKIM 或 SPF。对于 SPF，这需要匹配 信封发件人（即Return-PathSMTP 命令中使用的地址MAIL FROM）已通过 SPF 测试。

使用 DMARC，转发邮件（最终服务器不知道）无论如何都会导致问题：

  • 如果你不改变信封发件人，你将无法通过 SPF 检查，并且
  • 如果您更改它，它将不再与From:地址一致。

来自 PayPal 的示例邮件成功通过了 DMARC 测试，因为它具有有效的 DKIM 签名，并且与From标头一致。由于其他域的错误是标准 DMARC 拒绝，我们可以假设这些邮件要么缺少有效的 DKIM 签名，要么与标头不一致From。

唯一的解决方法是相信转发服务器已经检查了 SPF、DKIM 和 DMARC，并盲目接受来自该服务器的每封邮件。这就是在标准主/辅助 MX 配置中对通过辅助服务器传入的邮件所做的操作 - 也是在任何双方都接受的转发场景中应该如何做的。

不幸的是，根据 Gmail 帮助社区对“我可以关闭 DMARC 吗“，Gmail 不允许为 DMARC 测试添加例外。结论：不要转发到Gmail。

答案2

在我看来，Microsoft SPF 的 -all“硬失败”可能是原因。如果接收系统具有强制执行 SPF 和 DMARC 的机制，那么 SPF“硬失败”将导致此消息失败，即使 DMARC 会由于 DKIM 传递而传递它。请记住，SPF 是它自己的事物，并且在 DMARC 之前就存在了。但是，使用它的问题之一是，接收系统没有标准来解释“软失败”和“硬失败”。因此，接收者必须自行决定如何处理这两者（如果有的话）。Microsoft 可能仍让 SPF 处理入站邮件，并可能丢弃评估为“硬失败”的消息。Paypal 使用“软失败”，这可能被解释为不够重要，不足以使用 SPF 机制阻止。两者都可能由 DMARC 评估，但 SPF 检查可能会在 DMARC 有机会传递它们之前杀死这些消息。

答案3

这里实际上有 2 个政策在起作用。一个是 Microsoft SPF 的硬失败政策，由于您没有更改地址envelope.from，Gmail 可能会根据 SPF 将其删除。

envelope.from为了解决这个问题，重写aka是一个明智的做法return-path。但是，这会破坏 DMARC 基于 SPF 通过所需的一致性。因此，DKIM 只能帮您通过。

在转发场景中，这种情况有时被称为“DKIM 生存“，因为 DMARC 合规性取决于 DKIM 签名在转发过程中的存活情况。转发器的存活情况很大程度上取决于转发器更改了哪些标头字段，或者它是否剥离了原始签名（并可选择用自己的签名替换它）。

就您而言，PayPal 消息的 DKIM 签名在转发后仍然存在。在该电子邮件的标头的其他地方，您可以找到有关 DKIM 签名本身的信息，特别是已签名的字段。根据您从 Microsoft 收到的电子邮件类型（营销、调查等），这些可能是已签名的标头字段： h=From:To:Subject:Date:MIME-Version:Reply-To:List-ID:Message-ID:Content-Type; 了解您的系统在转发消息时触及哪些字段非常重要。以下是 DKIM RFC 的参考，它建议实际签名哪些标头：https://www.rfc-editor.org/rfc/rfc4871#section-5.5

然后是 ARC（即经过验证的接收链）。它仍处于草案阶段，但通常大型邮箱托管商（例如 Google）会很快实施这些新指南。DMARC Analyzer 对其功能有很好的描述：https://www.dmarcanalyzer.com/arc-is-here/

我希望这可以帮助你。

相关内容