当社のSPFレコード形式は以下のとおりです。
"v = spf1 include:_spf.google.com〜alla mx ip4:X.X.0.0/23 include:spf.example.com?all"
したがって、SPFレコードの途中に「〜all」があります。 openspf.com Webサイト で、彼らは「すべての」メカニズムに関して次のように述べています。
このメカニズムは常に一致します。通常、SPFレコードの最後にあります。
したがって、彼らは「すべて」がSPFレコードの最後に行く必要があるとは言いませんが、通常は最後に行くと言います。
私たちの会社では、最近、SPFレコードにリストされているサーバーから送信された電子メールでソフト障害が発生していますが、SPFレコードはこれまでに見つけたすべての検証ツールに合格しています。
私が疑問に思っているのは、Google Apps(_spf.google.com)のインクルードの直後のこの「〜all」によって解析が停止し、SPFレコードの残りの部分が認識されないということです。合格とソフト不合格は、誰が解析しているのか、SPFレコードを処理する方法の具体的な実装に依存しますか? SPFレコードの最後にない「すべて」のメカニズムを持つ理由はありますか?
はい、SPFレコードを変更するだけでよいことはわかっています。この質問は、これがどのように機能するかを明確にすることに関するものであり、必ずしも特定の状況を解決することに関するものではありません。
RFC7208§5.1 はこれについて明示的です:all
が表示された後、それ以降はすべて無視する必要があります。
「すべて」の後のメカニズムは決してテストされません。 「すべて」の後にリストされているメカニズムは無視する必要があります。用語の相対的な順序に関係なく、レコードに「すべて」のメカニズムがある場合、「リダイレクト」修飾子( セクション6.1 )は無視する必要があります。
それが廃止したRFC、 RFC 4408 は、ほとんど同じことを言っていました。 RFCの新しいバージョンは、単に意図を明確にしています。
「すべて」の後のメカニズムは決してテストされません。 「すべて」のメカニズムがある場合、「リダイレクト」修飾子( セクション6.1 )は効果がありません。
したがって、SPFの適合実装は、最初の~all
以降のすべてを完全に無視します。ただし、これはすべての実装が仕様に準拠していることを意味するものではありません。特に、これはおそらく正確に説明する価値があると考えられていましたbecause 1つ以上の実装が準拠していませんでした。
オンライン検証ツールがこの設定ミスを検出しない理由はまったく明らかではありませんが、最初のall
の後に何かを使用する場合は、適切な実装ではレコードが無視されるため、レコードを修正する必要があります。
"v = spf1 include:_spf.google.com〜all a mx ip4:X.X.0.0/23 include:spf.example.com?all"
順番に言う:
「
_spf.google.com
のSPFレコードを渡すメールは私たちのドメインで有効です」「私たちのドメインの他のすべての送信者でsoftfail」
「Aレコードからのメールはドメインで有効です」
「MXレコードからのメールはドメインで有効です」
「IP範囲
x.x.0.0/23
からのメールは私たちのドメインで有効です」「
spf.example.com
のSPFレコードを渡すメールは私たちのドメインで有効です」「私たちのドメインの他のすべての送信者からの電子メールは、いずれかの方法で検証できません」
レコード構文ごと:
メカニズムは順番に評価されます。一致するメカニズムまたは修飾子がない場合、デフォルトの結果は「ニュートラル」です。
したがって、「他のすべてのソフトフェイル」に到達すると、それは本当にそれについてです...それはあなたが指定した残りのメカニズムを無視するはずです。
SPFレコードは、できるだけ簡潔にする必要があります。ドメインに電子メールを送信する必要がある/ 23ネットワーク全体があり、すべてのAレコードもあるはずがないことを強く疑っています。多分そうです...しかし、おそらくそうではありません。
きれいなSPFレコードは次のようになります。
"v = spf1 include:_spf.google.com include:spf.example.com mx -all"
これは基本的に、_spf.google.com、spf.example.com、およびMXレコードがドメインの唯一の有効な送信者であると言うでしょう...他のすべては無効として扱われるべきです。
適切に実装されたSPFチェッカーはメカニズムの一致で短絡し、check_Host()関数は結果として修飾子の値を返します。ほとんどの電子メールサーバーがRFCに準拠しているかどうかに関して、提供する「現実の」データはありません。
出典: RFC7208 (17ページを参照)