SPF中立メカニズム（？いつ、どのように使うか

ブログ

SPFレコードの~allや?SPFレコードの中立的な意味、使用するタイミング、メール配信の問題を回避する方法を学びましょう。

byユネス・タラダ

最終更新日:
5 読了時間：5分
SPF中立メカニズム（？いつ、どのように使うか

SPFの中立メカニズム "すべて"は、Sender Policy Framework (SPF) レコードのメカニズムであり、中立的な評価をもたらす。これは、SPFに基づいて合否判定を行わないように受信サーバーに指示するものである。

  • SPFレコードの例
    v=spf1 include:_spf.google.com ?all

この例では、ドメインはグーグルのSPF設定を含んでいるが、末尾は`?all`で終わっている。承認も拒否もせず、明確な判断を下さない。

技術的には有効ですが、`?all`は曖昧さを生み、信頼を弱め、DMARCの実施を妨げ、不適切に使用された場合には配信の問題につながる可能性があります。

主なポイント

  • SPFニュートラル・メカニズムは、電子メールが正当なものかどうかを明確に特定するものではない。
  • .allメカニズムは、テストやレガシーコンフィギュレーションなど、場合によってはまだ役に立つかもしれない。 
  • しかし、実運用で使用すると、メールサーバーに曖昧さを生じさせる可能性がある。
  • SPFニュートラルメカニズムは、なりすましを容易にし、メール認証や配信の失敗を引き起こす可能性があるため、実運用で使用することは推奨されません。 
  • ドメインのメールセキュリティを強化するために、?allメカニズムをsoftfail（つまり、~all）に置き換えることをお勧めします。

SPF中立メカニズム(?すべて)とその他のメカニズムとの比較

"ドメイン所有者は、そのIPアドレスが認可されているかどうか を主張できないか、主張したくないと明示的に述べている。 Neutral "の結果は "None "の結果と同様に扱われなければならない。 Neutral "を "None "よりも厳しく扱うことは、ドメイン所有者がSPFレコードの使用をテストすることを妨げることになる。"- RFC 4408

? "である。all"の仕組みは他の SPF 修飾子とは異なり、合格・不合格の結果を出さないので、DMARC の評価やメールサーバーの意思決定を妨げる可能性がある。

その"すべて"メカニズムは受信メールサーバーを混乱させ、メールを信頼すべきかどうかわからなくなる。下の表は、さまざまなメカニズムの効果と使用例を簡潔にまとめたものである。

メカニズム効果使用例
すべて（中立メカニズム）中立 - 合否判定なしめったに使われないし、推奨もされない。過渡期のセットアップで使われることがある。
~すべて（推奨手法）不合格 - 不審人物としてマークDMARCが誤検知のリスクを負うことなくポリシーを実施できるように、未承認の送信者をブロックせずにフラグを立てるため、SPFロールアウト時に使用される。
-すべてハードフェール - メールサーバーによって拒否される可能性がある。厳格な執行と強力なセキュリティのために使用される。

注意して使用してください。SPFレコードが完全であることを確認してから-allを適用し、正当なメールが拒否されないようにしてください。

SPF中立メカニズムの使用時期

SPFニュートラル・メカニズムは、ほとんどの最新メール・セットアップでは推奨されません。しかし、より安全な仕組みへの移行を事前に計画し、注意を払うことで、場合によっては使用することができます。 

レガシーシステム

一部の古いインフラやシステムでは、明確な送信者ポリシーや適切なSPF処理が行われていない場合があります。そのような場合、機能を維持するために、SPFニュートラル・メカニズムのような中立的なスタンスが必要になります。

テスト段階

また、SPFの初期導入時にこのメカニズムを使用することもできます。これにより、ドメイン所有者はメールのトラフィックを監視しながら、配信を維持することができます。

珍しいエッジケース

時々、~allや-allのような他のメカニズムが、予期しない配信上の問題を引き起こすことがあります。このような問題を診断するために、一時的に?allメカニズムを使用することができます。 

⚠️ SPFメカニズムは順次評価され、?allを他のメカニズムの前に置くと、SPF評価が早期に停止し、意図したチェックをバイパスする可能性がある。

すべてを使うことのリスクとは？

?allメカニズムにより、明確な認証結果が得られないため、メールセキュリティ（なりすまし防止など）とメール配信性の両方が損なわれる。考えられるリスクは以下の通りです： 

なりすましメール

allは中立の結果を返すので、なりすましに対する防御にはならない。対照的に、~allと-allは識別可能なフェイルシグナルを返します。これらのシグナルをDMARCポリシーと組み合わせることで、受信サーバーは不正なメールを隔離または拒否することができます。

DMARCの競合

からの中立的なSPF結果は、ドメインが一致していれば、技術的にはDMARCに合致しているかもしれないが、DMARCが強制措置を取るために必要とする合格／不合格のシグナルを提供しない。

配信の問題

一部のメールサーバーは、SPFの?allメカニズム（中立）を弱い、または非妥協的なポリシーと解釈する。これは、送信者アイデンティティの施行が不十分であることを示す可能性があり、信頼を低下させる可能性があります。Gmailのようなメールプロバイダーは複数のシグナルを使用しており、弱いSPFポリシーは多くの要因の1つに過ぎない可能性があります。

allを~allまたは-allに置き換える方法

ドメインのメールセキュリティ体制を向上させるには、?allメカニズムをより明確なものに置き換える必要があります。そのために必要な主な手順は以下の通りです。 

1.現在のSPFレコードを監査する

PowerDMARCの SPFチェッカーを使用して、現在の設定を監査してください。レコードがない場合は、無料の SPFジェネレータを使用して、送信元に合わせて作成することができます。

2.allを~allに置き換える。

ソフトフェイル（～すべて）メカニズムは、慎重かつ実用的なアプローチである。p=rejectのDMARC を使用してもに基づいてメールを拒否することができる（~allは "fail "をトリガーする）。

3.DMARCレポートの監視

また、DMARC集計レポートを使用して、定期的に電子メールのアクティビティを追跡することも重要です。PowerDMARCの DMARCレポートアナライザーは、ユーザーフレンドリーなリアルタイムのDMARC レポートを提供し、情報と安全性の維持を支援します。

よくあるSPF中立メカニズムの誤設定

allメカニズムを誤用すると、意図しないセキュリティ・ギャップや配信上の問題が発生する可能性があります。ここでは、避けるべきよくある間違いを紹介します。 

間違い1：本番で「?

中立的なポリシーは何の保護も提供しない。このため、なりすましメールが合法的に見えるようになります。その結果、貴社の評判と受信者の安全の両方が危険にさらされる可能性があります。 

間違い2: 厳格なDMARCポリシーと?

p=rejectのようなDMARCポリシーは、SPF(またはDKIM)が明確な合否を提供することに依存します。中立的なSPFでは、DMARCは何をすべきかわからず、不必要なDMARCの失敗が発生するかもしれません。

間違い3：「すべて」が「～すべて」と等価だと思い込む

~allは少なくとも不正な送信者にフラグを立てる。一方、?all メカニズムはまったく判定を行わない。多くの人がこの2つを混同しているため、電子メールの認証や配信に問題が生じている。 

よくあるご質問

1.SPFレコードがないのと同じですか？

いいえ、すべて中立的なスタンスを示しています。一方、SPFレコードなしは、まったく指針を与えません。メールサーバーはそれぞれ異なる扱いをします。

2.DMARCは使えますか？

技術的には可能だが、推奨されない。DMARCは明確なSPFの合否結果に依存している。.allを使用すると、しばしば中立的な結果となり、DMARCの有効性が低下します。

最終的な感想

SPFレコードの?allメカニズムは、一見無害に見えるかもしれませんが、危険かもしれません。これは実際には推奨されず、あなたのドメインがなりすましにさらされ、DMARCポリシーの効果を低下させる可能性があります。

現在?allを使用している場合は、より良いセキュリティと信頼性の高いメール認証のために、‾all（ソフトフェール）に置き換えることを計画してください。 

長期的なSPFの信頼性を確保するために、PowerDMARCの以下を使用することで、管理を簡素化し、DNSルックアップの制限を回避することができます。 主催SPF ソリューションです。複雑なレコードを処理し、エラーのないドメイン認証を提供するために自動的に最適化するように構築されている。CTA

最新記事 by Yunes Tarada(全て見る)
最終更新日:
DMARCの誤検知：原因、修正、防止ガイドDKIMを使用せずにDMARCを設定することはできますか？DKIMなしでDMARCを設定できますか？