web-dev-qa-db-ja.com

GMAILが誤って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で終わります

これらの各インクルードには、電子メールの送信時にOutlook.comが使用するIPのCIDRのセットがあります。

ただし、実際にはSPFレコードのインクルードの1つでカバーされているIPのSPF FAILを示すDMARCレポートをgoogle.comから取得しています。これは間違っていると思いますが、頻繁に発生しています。

次に例を示します。

    source_ip>104.47.117.233</source_ip>

<count>1</count>


-<policy_evaluated>

<disposition>none</disposition>

<dkim>pass</dkim>

<spf>fail</spf>

拒否されたIPは、sp4b.protection.Outlookレコードの一部であるip4：104.47.0.0/17の一部です。

spfb.protection.Outlook.com。 394 IN 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/24ip4：104.47.0.0/17ip4：23.103.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レコードに含まれるIPに関して頻繁にSPF失敗通知を受け取ります。

emailspfgoogledmarc
5
OzPHB

私はそれを理解しました。当然のことながら、GoogleがDMARCの実装を間違っているのではなく、レポートを誤って解釈したのです:)

（OPにコピーが投稿された）混乱していたポリシー評価セクションのSPF結果は、DMRC評価SPF結果afterです。

この引用 here は問題を説明しています：

Auth_resultsのSPFおよびDKIMの結果は、Identifier Alignmentに関係なく生の結果であることに注意してください。 Identifier Alignmentを使用したDMARC評価の結果は、policy_evaluatedセクションにあります。

レコードの残りの部分を確認したところ、同じレコードのrawの結果は、正確にはSPFパスでした。

したがって、DMARCレポートが伝えていることは、SPFの結果は確かにOutlook.comから（つまり、生の「パス」でした）、リターンパスヘッダーが送信ドメインと一致せず、DMARCevaluationSPFは失敗します。別のリファレンス here 。

基本的に、XMLレポートを直接読み取ろうとしないでください-それらは人間にとって難しいです！私は this DMARC xmlパーサーを見つけましたDMARCレポートがあなたに伝えようとしていることを明確に見ることができるというすばらしい仕事をします。

5
OzPHB