标签: spf

之间有什么区别

v=spf1 include:_spf.google.com ~all

和

v=spf1 include:spf.google.com ~all

（第一个在spf前面有下划线，第二个没有）

我有一个域，其 SPF 记录如下所示："v=spf1 mx ip4:6.7.8.9 -all". 该记录是有效的，据我所知，这意味着仅允许来自以下方面的邮件：

• 作为域的 MX 记录的服务器。
• 说ipv4地址：6.7.8.9

所有其他邮件的硬失败。

当我向 Gmail 帐户发送电子邮件时，使用的 ip 不是其中任何一个 -电子邮件仍会到达我的收件箱。当我查看标题时，结果证明 google 确实按照我的预期读取了我的 SPF 记录，并且知道它应该失败，但它没有

fail (google.com: domain of me@example.com does not designate 99.9.9.99 as permitted sender) client-ip=99.9.9.99

有人会知道我在这里缺少什么吗？

我目前正在收集一个从 SendGrid 迁移到 Mandrill 作为交易电子邮件服务提供商的小型（希望如此）项目的需求。我们已经使用 SendGrid 近 3-4 年了，平均每天大约 5k-10k 封电子邮件。我们正确配置了 SPF 和 DKIM 记录，因此，退回/垃圾邮件率非常低，并且作为发件人享有很高的声誉。

已经决定迁移到 Mandrill，现在我必须确保迁移顺利进行，服务中断尽可能少，从而重新开始审批/声誉流程。

我知道对于 SPF 条目，可以添加多个项目，因此，暂时我将同时保留 SendGrid 和 Mandrill。但是，我对 DKIM 条目不是 100% 确定。一些服务推荐 CNAME 条目，而其他服务推荐 TXT 条目。

这让我想知道是否可以为一项服务设置 CNAME DKIM 条目，为另一项设置 TXT DKIM 条目。我很好奇这种变化的影响。此条目的审查/验证是否完全取决于中介/接收者？或者，他们通常会同时看到两者并只选择第一个？

本质上，我想做的是找到某种方法，以尽可能少的中断从一项服务缓慢过渡到下一项服务。我们之前在 ISP 黑名单方面遇到过问题，我非常想避免这种情况。

非常感谢您的参与！

我读到为一个也有自己的 SPF 的域使用 CNAME 是无效的，因为所有记录都是从 CNAME 指向的域中获取的。

然而，这似乎不是我发生的事情。我已pi.dantup.comCNAMEd 到dantuppi.dynv6.net，但是我的 SPF 记录似乎工作正常（dynv6.net域上没有 SPF ：

https://toolbox.googleapps.com/apps/dig/#CNAME/pi.dantup.com https://toolbox.googleapps.com/apps/dig/#TXT/pi.dantup.com

这似乎可以很好地使用此工具进行测试。但是，一位朋友的设置非常相似，似乎无法正常工作。在深入研究之前，我试图了解我的做法是否正确？

有没有办法强制 DMARC 拒绝/拒绝未通过 DKIM 和 SPF 的邮件？

我们一直在缩小失败的数量，但我们的汇总 (rua) 报告中有一些域仅通过了 DKIM，我们宁愿它们通过我们的 DMARC，因为我们无法识别它们。

我们确实识别的域是完全对齐的。

我们的最终目标是，除非完全对齐（DKIM 和 SPF），否则消息将被拒绝

鼓励0365 邮件用户在其 SPF 记录中使用include:spf.protection.outlook.com -all。

我遵循了这个指导。我公司的 spf 记录说：
v=spf1 include:spf.protection.outlook.com -all

spf.protection.outlook.com 记录以 include:spfa.protection.outlook.com 结尾 -all 以 include:spfb.protection.outlook.com 结尾

其中每个都包含一组 CIDR，用于 Outlook.com 在发送电子邮件时使用的 IP。

但是，我从 google.com 收到了 DMARC 报告，表明某个 IP 的 SPF 失败，该 IP 实际上被 SPF 记录中的一个包含项所涵盖。我认为这是不正确的，但经常发生。

下面是一个例子：

    source_ip>104.47.117.233</source_ip>

<count>1</count>


-<policy_evaluated>

<disposition>none</disposition>

<dkim>pass</dkim>

<spf>fail</spf>

被拒绝的 ip 是 ip4:104.47.0.0/17 的一部分，它是 spfb.protection.outlook 记录的一部分：

spfb.protection.outlook.com。394 在 TXT "v=spf1 ip6:2a01:111:f400::/48 ip4:23.103.128.0/19 ip4:23.103.198.0/23 ip4:65.55.88.0/24 ip4:10.104.ip4 :10.04. 200.0/21 ip4:23.103.208.0/21 ip4:23.103.191.0/24 ip4:216.32.180.0/23 ip4:94.245.120.64/26 -all"

那么，为什么 Google 的电子邮件服务器会将此视为 SPF 失败？

这不是一个孤立的例子 - 我经常收到与 SPF 记录中包含的 …

我已将 Postfix 配置为拒绝从没有 PTR 记录的主机和没有 A 记录的主机名发送的电子邮件。我发现有些合法的邮件服务器具有有效的 SPF 记录，但它们的主机名没有 A 记录。结果，合法的电子邮件被拒绝了。

即使主机名没有 A 记录或 IP 地址没有 PTR 记录，有没有办法将 Postfix 配置为接受具有有效 SPF 记录的电子邮件？

我试图了解 RFC7208 (SPF) 中定义的 HELO 身份的好处。

有一个邮件服务器，比如说mail.example.com。此服务器用作不同域的中继。

在第 2.4 节中：

如果“HELO”检查尚未执行或未通过将 check_host() 函数应用于“MAIL FROM”身份作为 <sender>，则 SPF 验证者必须检查“MAIL FROM”身份。

据我所知，如果HELO已经通过，则无需检查MAIL FROM。

2.3 节类似：

检查“HELO”可促进结果的一致性并可以减少 DNS 资源的使用。如果可以基于对“HELO”的检查对消息做出决定性的确定，则可以避免使用 DNS 资源来处理通常更复杂的“MAIL FROM”。

这不会导致未经检查的 MAIL FROM 身份吗？

问候，亚历克斯

当我在 Microsoft Teams 中编写聊天消息时，当接收者在 Teams 中处于脱机状态时，她会在其 Office 365 帐户 (receiver@htlvb.at) 上收到电子邮件通知。收件人进行设置，以便将她的所有邮件转发到她的个人 Gmail 帐户 (receiver@gmail.com)。对于发送到receiver@htlvb.at 的普通邮件，这按预期工作。但所有 Teams 通知都被标记为垃圾邮件。Google 表示 DMARC 失败（见下文）。

我们有一个自定义 DNS 服务器，其中包含以下 TXT 记录：

Google 显示收到的邮件的以下详细信息：

以及以下消息来源：

Delivered-To: receiver@gmail.com
Received: by 2002:a05:6102:22c6:0:0:0:0 with SMTP id a6csp126141vsh;
        Tue, 28 Sep 2021 20:57:32 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJzoIoMngWwglBmEptt30Zo9LbSYdi+h60ylB7JYY70zFSXHQNhbDjrM0JhFd+XgdPAeZKJj
X-Received: by 2002:a92:ca4e:: with SMTP id q14mr3941013ilo.233.1632887852170;
        Tue, 28 Sep 2021 20:57:32 -0700 (PDT)
ARC-Seal: i=4; a=rsa-sha256; t=1632887852; cv=pass;
        d=google.com; s=arc-20160816;
        b=uZnSPh2our1xDKqBgznYVmLU4MHkWy+9WfIBcYxGbuAOiHypyYi2pU3yByqTWDxC3m
         XD8lQzitQmtWzWPozdJmWv6DFJW5eSVogISaSrA6i8qY2wBhk8ZlukHsKjWLlRTsWD/Q
         TJa+99FG/eIio0EDYtVW+2d+WlVN9qMei8Ap/aaA1snA27wHv91lUsAGLNI2kUUvwsMA
         omJAMvTBBCgGtEa6V8s4Z7nWhkGGpwwRnxaCefPwqBCZ8QMVy8zYmk/JGTVcSSTSQdQk
         bqWRkoJlrscnt3JLAA4WUpYdNcpORAi8WuuoXs+w6uxzNxfg2EpcvNWIOwBFvOm/WVVq
         FoUg==
ARC-Message-Signature: i=4; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=message-id:subject:date:to:from:mime-version …

我最近收到了来自 Google 的 DMARC 报告，提醒我来自 Amazon SES IP 地址的邮件出现了一些 SPF 故障。示例记录如下（我已将我们的域名替换为 example.com。）：

  <record>
    <row>
      <source_ip>54.240.27.187</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
      </dkim>
      <dkim>
        <domain>amazonses.com</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>mail.example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

SPF 是否失败，因为该header_from值是example.comSPFdomain值mail.example.com？

我们使用 Amazon WorkMail 和 Amazon SES 发送手动和自动电子邮件。通常From address是webmaster@example.com，我们已将MAIL FROM域设置为mail.example.com。因此，我有点困惑为什么 Google 会将header_from域名报告example.com为mail.example.com. example.com我们为和设定了适当的 SPF 记录mail.example.com …