重要なお知らせ:GoogleとYahooは2024年4月よりDMARCを義務付けます。
PowerDMARC

DMARCポリシーのオーバーライド。説明

DMARCポリシーのオーバーライド

DMARCポリシーのオーバーライド

読書時間 6

この記事では、DMARCポリシーのオーバーライドとは何か、どのように機能するのか、DMARCポリシーのオーバーライドとDMARCポリシーの失敗の違いは何か、DMARCレコードのオーバーライドは正当かどうかについて詳しく説明します。

DMARCポリシーのオーバーライド。説明

DMARCポリシーのオーバーライドは、受信メールサーバーがDMARCポリシーのオーバーライドを行う場合に発生します。 DMARCレコードを上書きする場合に発生します。これは、送信者が受信メールサーバーのポリシーに一致しない場合にメールを拒否するように指定したが、受信メールサーバーが自身のポリシーセットに適切でないと判断した場合に発生します。

例えば、送信者が厳格なポリシー(「p=SPFまたはDKIMのないすべてのメールを拒否する」など)を指定し、受信側のメールサーバーが緩やかなポリシー(「SPFまたはDKIMのないすべてのメールを受け入れる」など)を指定している場合です。このような場合、受信サーバーは送信者のDMARCポリシー設定を独自のローカルポリシーで上書きし、DMARCチェックに失敗しても受信者の受信箱にメッセージを配信することがあります。

DMARCポリシーオーバーライドメカニズムの理解

DMARCは、お客様のドメインから送信されたメールに対して、メール受信者が使用できるポリシー設定を伝達するために使用されます。

例えば、DMARCのポリシーを使用して、お客様のドメインから送信された電子メールでSPFまたはDKIMのチェックに失敗した場合に、受信者の電子メールサーバーが何をすべきか(p=rejectまたはp=noneまたはp=quarantine)指示することができます。

これがDMARCの威力をよく表していますね。

しかし、受信側のメールサーバーが、受信メールを処理するための独自のローカルポリシーのセットを持っている場合はどうでしょうか?送信者が設定したDMARCポリシーに従うのか、それとも、独自のローカルポリシーで送信者のポリシーを上書きするのか?

まあ...

DMARCの仕様では、メール受信者はドメイン所有者が公開したDMARCポリシーを尊重するために誠実に努力することが要求されています。したがって、送信者のSPF、DKIM、Fromヘッダーのテストが失敗した場合、送信者のDMARCポリシー(p)で指定されたもの(隔離、拒否、またはNONEなど)をトリガーする必要があります。

さて、仮にこのような状況だとします。

➜ お客様のドメイン (mypersonaldomain.org) に DMARC ポリシー (p=none) が設定されています。

➜ 受信者(theirdomain.org)が運営するメールサーバーは、SPFチェックに失敗したメールをすべて拒否します。つまり、(theirdomain.org)に送信されたメールがSPFチェックに失敗した場合、拒否されるということです。そうだろう?

でも...

DMARCポリシーp=noneのあなたのドメイン(mypersonaldomain.org)からのメールがsomedomain.orgで受信され、SPFチェックに失敗するとどうなるのでしょう?

この場合、送信者が設定したDMARCポリシーに同意するか、SPFチェックに失敗したらp=rejectというローカルポリシーで定義したルールで送信者のポリシーを上書きしてメールを拒否するかは、受信メールサーバー(設定方法)に依存することになります。

Microsoft 365は、p=rejectのメールをすべて拒否するのではなく、ユーザーの迷惑メール/スパムフォルダに送るという、リアルタイムの例である。これは、O365が、最終的な処分は受信者が決定すれば良いと考えているからです。

DMARCポリシーオーバーライドの5つの値

転送された- 転送パターンを識別するローカルアルゴリズムに基づき、メールが転送された可能性が高い。認証に失敗することが予想されます。

ローカルポリシー- は、メール受信者のローカルポリシーが、ドメイン所有者によって要求されたアクションの対象から電子メールを除外したことを意味します。例えば、要求されたポリシーが "reject "に設定されているが、ARCチェックが通過した場合、メール受信者はその決定を上書きし、メールを拒否しないことを選択することができる。

ARCとは?

ARCとは Authenticated Received Chain(認証済み受信チェーン(ARC)の略です。ARCを使えば、電子メールのDKIMやSPFのプロトコルが、転送やメーリングリストによって壊されることがなくなります。これは、ARCが、インターネット上のあるノードから別のノードへメッセージを渡す際に、メッセージを変更する可能性のあるルーター、仲介者、その他のシステム(「ホップ」)を越えて、電子メールの認証結果を保持するためである。

したがって、もしARCチェーンが存在すれば、本来ならメッセージを破棄するはずの受信メールサーバーが、テストの結果を評価して例外を作り、これらの間接的なメールフローからの正当なメッセージを宛先に到達させることを選択する可能性がある。

メーリングリスト- このメールはメーリングリストから送信されているので、フィルタプログラムはおそらく正当なメールではないと判断しました。

sampled_out - DMARCレコードに"pct "が設定されていたため、メッセージはポリシーに適用されなかった。

信頼できるフォワーダー- ローカルで管理されている信頼できるフォワーダーのリストにメールをリンクする証拠によって、障害が予期されました。

その他- 一部のポリシーには、リスト内の他のエントリでは対応できない例外が含まれています。

DMARC Policy Overriding:許されるのか?

RFC7489のセクション6では、メールサーバーは送信者のポリシーに沿ったメッセージを尊重し、処理すべきであると述べています。上書きはDMARCの精神に反するものですが、メールボックス・プロバイダーはいかなる送信者のポリシーも上書きする権利を留保しています。したがって、受信サーバーがDMARCのポリシーをローカルポリシーで上書きすることは許容されます。

つまり、電子メールサーバーが従うべきポリシーに反していても、偽造されたメッセージを配信してしまう可能性があるのです。

DMARCポリシーオーバーライドレポートを送信すべきか?

DMARCポリシーのオーバーライドは、主に以下の場合に行われます。

DMARCポリシーのオーバーライドは認められていますが、RFC7489のセクション6と7.2では、受信者がドメイン所有者の公開ポリシーから外れることを選択した場合、その事実と理由をドメイン所有者に(集約されたフィードバック報告形式を用いて)報告しなければならないとされています。

DMARCポリシーのオーバーライドはどのように許可されますか?

DMARCは2つの部分から構成されています。

DMARCポリシー- これは、送信側の組織が設定し(SPFやDKIMとともに送信側の組織の公開DNS上)、受信側がそのポリシーに従わないメッセージをどのように処理すべきかを定義するものです。

DMARC検証- これは、受信側の組織(受信側の組織のメールセキュリティゲートウェイ上)で使用され、特定の組織から受信したすべてのメッセージについて、その企業のDMARCレコードに記載されているポリシーをチェックします。ただし、送信組織のDMARCポリシー実施を上書きする機能は、受信組織にも当てはまります。

設定する DMARCポリシーの設定「義務ではなく、要求」です。: それは本質的に、あなたが 要求」することです。メールサーバーに、あなたのドメインから送信されたメールやあなたのドメインになりすましたメールをどのように扱うべきかを示すよう「要求」していることを本質的に意味します。

しかし、電子メールの受信者は、受信した電子メールを処理する際に、厳格なガイドラインに従うことを要求されません。受信者は、受け入れるメッセージや拒否するメッセージについて独自のポリシーを策定し、その基準を適宜適用することができます。

例えば、メール受信者がそのメッセージを有効だと判断した場合です。そのため、あるメールがDMARCチェックに失敗しても、受信者はローカルポリシーを適用して受信箱に配信することができます。さらに、メール受信者のポリシーがドメイン所有者のポリシーを上書きすることもあります。

受信側の組織が私のDMARCポリシーを上書きする方法は?

他の組織は、独自のDMARC検証ツールによってお客様のDMARCポリシー設定を上書きし、受信メッセージに対してどのように対処するか、独自のポリシーセットを決定することができます。システムによっては、管理者権限を持つユーザーが、すべてのドメインを上書きできる場合と、特定のドメインのみを上書きできる場合があります。

DMARCポリシーはドメイン所有者によって設定され、各ポリシーはその組織のドメインにのみ適用されることに留意する必要があります。したがって、DMARCポリシーは、他の組織のアドレスやメッセージに影響を与えることはできません。

DMARC Policy Failure vs DMARC Policy Overrides。何が違うのか?

DMARC障害は、メールサーバーがDMARCを適切に実装していない場合、受信者側でSPFやDKIMの検証に失敗することを指します。送信者の正当性を確認できない場合、受信箱は送信者をスパムとしてマークしたり、メッセージを拒否したりします。この場合、受信側のメールサーバーは送信者のポリシーを尊重し、そのローカルポリシーで上書きすることはありません。

DMARCポリシーのオーバーライドは、受信メールサーバーが送信者のポリシーを尊重しない場合に発生します。その代わりに、送信者のDMARCポリシーをローカルポリシーでオーバーライドします。つまり、送信者のメッセージがSPFまたはDKIM検証なしでp=rejectという厳しいポリシーを持っている場合、受信メールはポリシーを上書きして、とにかくメッセージを受信トレイに配信します。

PowerDMARCでDMARCポリシーのオーバーライドを適切に追跡する

DMARCポリシーのオーバーライドを常に最新の状態に保つことは、電子メールのスプーフィングやなりすましを防止するために重要な要素です。しかし、ほとんどの組織では、DMARCポリシーの無効化を追跡するための時間やリソースがありません。

DMARCポリシーのオーバーライドを止めることはできませんが、当社のDMARCサービスを利用することで追跡することができます。どの組織がポリシーモードをオーバーライドしたのか、どの組織からどのようなタイプのメッセージが送信され、受信者側でどのメールが許可されたのか、完全なレポートを提供します。これにより、送信者が追跡し、なりすましやなりすましが見つかった場合に必要な措置を取ることができます。

登録はこちら 無料DMARCトライアル今すぐお試しください。

モバイル版を終了する