メインコンテンツへスキップ
Avanan:謎のメール送信量の解明

Avanan:謎のメール送信量の解明

セキュリティに関する洞察技術ガイダンス

ドメインのDMARCデータを検証している際、不可解な現象に遭遇することがあるかもしれません。それは、*.cloud-sec-av.com に解決されるIPアドレスから、貴社のドメインを名乗って送信された大量のメールであり、そのほとんどが通常、DMARC検証に失敗しているというものです。さらに懸念されるのは、Microsoftから報告されるこれらのデータすべてにおいて、メールが拒否されたと表示されている可能性があるという点です。 

「なぜ自社ドメインをなりすましたメールが、これらのサーバーからこれほど多く送信されているのだろうか?」「第三者を騙すために自社ドメインが悪用されているのだろうか?」と疑問に思うかもしれません。しかし幸いなことに、これには明確な理由があり、注目に値するMicrosoft特有の挙動が関係しています。 

Avanan(アバナン)とは?

Check Point社の「Avanan」は、Microsoft 365(M365)を利用する企業向けのクラウド型メールセキュリティサービスです。最も一般的なインバウンド(受信)導入モードである「Protect (Inline) Mode」では、Avananは受信者のMXレコードを変更しません。パブリックなMXレコードはMicrosoft 365のままです。その代わり、Avananは受信者のM365テナント内にあるコネクタとトランスポートルールを介して、Exchange Onlineのメールフローに内部的にプラグイン(挿入)する形で動作します。 

DMARCのノイズ(誤検出)

メールを送信すると、以下のような経路をたどります。 

  1. 送信元のメールサーバーが受信側のMX(つまりMicrosoft 365)にメッセージを配信します。M365は、設定されているすべてのインバウンドメール認証(DMARC、SPF、DKIM)およびメールセキュリティチェックを実行します。 
  2. M365のトランスポートルールにより、メッセージは受信側テナントの外にあるAvananのスキャンインフラへとルーティングされ、マルウェア、フィッシング、DLP(データ消失防止)の分析が行われます。このプロセスの際、URLの書き換え、添付ファイルの削除、バナーの挿入、あるいは元のメール本文の変更などが行われることがあります。これは、既存のDKIM署名が壊れずに維持できるかどうかに大きく影響します。 
  3. Avananは、変更を加えたメッセージを、自社のIPアドレス帯(*.cloud-sec-av.com)から受信側のM365テナントへと送り返します。 
  4. M365はメッセージを2度目に受信し、この再入場に対して再び認証チェック(SPF、DKIM、DMARC)を実行します。DMARCレポートに表示されているのは、この「2回目」の認証チェックの結果です。 
Avanan:謎のメール送信量の解明(画像)

Microsoftの誤解を招くレポーティング

MicrosoftによるDMARC検証チェックの報告方法は、お客様の間でしばしば混乱を引き起こします。もし自社ドメインでDMARCポリシーを quarantine(隔離)または reject(拒否)で強制適用(Enforcement)している場合、レポートには「DMARCは失敗」と記載され、メールの処理結果(Disposition)には公開している強制適用ポリシーがそのまま反映されることがよくあります。。 

しかし、その処理結果は、実際のメールに起こったことではありません。 

メッセージは実際にはユーザーに届いています!

AvananのIPアドレスは、確実にメールが配信されるよう接続レベルでホワイトリスト(許可リスト)に登録されています。それにもかかわらず、MicrosoftはDMARCチェックを実行するだけでなく、「ホワイトリストがなかった場合にどう処理されていたか」をレポートに記載してしまうのです。
本来、DMARCレポートには、公開しているポリシーとは異なる処理を適用した理由を報告者が示すための仕組みが存在します。これは、アグリゲート(集計)レポートの「Override Reason(オーバーライド理由)」や「Override Comment(オーバーライドコメント)」機能を通じて行われますが、Microsoftがこの機能を使用していないことは周知の通りです。

これに対して何をすべきか?

何もする必要はありません。

送信ドメインの所有者として、有効な対策はありません。特に以下の点に注意してください。

  • 自身でAvananを所有・利用していない限り、AvananのIPアドレスを自社のSPFレコードに追加しないでください。 
  • 間接的なメールフロー(転送など)を理由に、自社のDMARCポリシーを変更しないでください。 レポートの記載内容にかかわらず、実際にはメールの配信失敗は起きていません。そのため、何のアクションも起こさないことが強く推奨されます。これらのDMARCの失敗は、お客様の管理境界の外にあるインフラによってメールが中継(リレー)されることで発生します。これは、意図した受信者に正常に配信された「後」に転送されるメール(自動転送など)と同様の現象です。
  • 受信者に連絡する必要はありません。 相手があなたのメールを拒否しているわけではありません。 

さらに詳しく議論を続けたい方は、ぜひ dmarcian Forum へお越しください。