Internet Infrastructure Review（IIR）Vol.67
2025年9月

前回の報告で、悪意のある者がメールアカウントを乗っ取り、メールサービスを用いてフィッシングメールなどの送信に利用されてしまう問題についてレポートしました。

悪意のある者によってメールサービスが不正利用されると、フィッシングメールなどの宛先ユーザが攻撃対象となってしまうだけでなく、サービス設備の可用性の低下や、宛先のメールサービスへの到達性低下など、メールサービスを利用している他のお客様にも影響が波及してしまいます。このようなインターネット上での迷惑行為や不正行為はIIJに限らず、他ISPや他社サービスでも日常的に発生しており、一般的にabuse（アビューズ）と呼ばれますが、事後対処しかできない点が課題でした。

そこで、メールサービスの品質を維持し、お客様を保護するための取り組みとして、不正利用の準備行為を察知した場合、実際にフィッシングメールなどが送信される前に必要な範囲で通信を制限し、abuseに至らないようにする新しい取り組みを、2024年5月1日より、IIJセキュアMXサービスの契約行為として開始しました^（注1）。

abuse対応は実際に行われた迷惑行為の事後対処であるのに対し、不正利用の準備行為を事前に察知してお客様を保護することから、この新しい取り組みを「ディフェンス対応」と名付けました。

さて、「ディフェンス対応」を開始してから約1年が経過しました。本稿では、この取り組みによって、どのような効果があったのかを報告します。

図-1は、abuse対応とディフェンス対応の件数を集計し、積み上げたグラフです。縦軸がabuseまたはディフェンス対応が発生した件数で、横軸は年度ごとの合計件数（4月〜翌年3月）です。参考までにディフェンス対応を開始する3年前（2021年度）からの集計も付け加えました。

グラフからも読み取れるように、直近3年間のabuse対応発生件数はほぼ変わっていないのに対し、2024年度からのディフェンス対応の取り組みによって、abuse対応の件数は約半分まで削減されています。

冒頭で説明したように、abuse対応が発生すると、メールサービスの品質が損なわれたり、この対応のためにエンジニアの突発的な稼働が発生したりします。ディフェンス対応によって、こうした要因を約50%排除できたことが分かります。

また、ディフェンス対応によって事前にメールの送信を制限し、悪用を防げているということは、IIJのネットワークから送信されるフィッシングメールなどの送信が抑制できていることを意味します。電子メールは送信者と受信者の立場が表裏一体ですから、これはインターネットインフラの安定運用を支え、信頼性向上に資する技術的取り組みであり、大きな効果を上げていると捉えることができるでしょう。

なお、本稿発行の都合上、2025年度は6月までの集計となっていますが、更に興味深い結果が浮かび上がってきました。2024年度はabuse対応とディフェンス対応がおおむね半々の割合だったのに対し、2025年度の3ヵ月はディフェンス対応の件数の割合が、abuse対応の件数より増加している点です。

IIJのメールサービスが悪意のある者にとって使いづらいインフラとなれば、次第に悪用されなくなっていくことが推測されます。そしてサービスのプロダクトオーナーの視点から言えば、abuseの対応件数が減少していけば、その分、エンジニアの稼働を運用改善や品質向上、そしてお客様サポートといった別の取り組みに回すことができます。

IIJでは、今後ともお客様を保護するための取り組みを続けてまいります。

2023年にGoogle、Yahooが送信ドメイン認証（SPF、DKIM、DMARC）必須化を発表したことを受け、IIJでも社内システムの対応作業を行いました。

対応作業の過程で、Microsoft 365（以下、M365）宛に転送を行う場合、ARC（Authenticated Received Chain）認証が失敗する事象を確認しました。ARCは、メール転送時にSPFやDKIMの認証結果を再評価し、それらの結果と署名情報をヘッダーに追加することで、DMARCポリシーによる誤判定を防ぐ役割を果たします。検証時のメールヘッダーには、以下のようにarc=fail（47）の記述があり、認証が失敗していることが示されています。

この問題がIIJ側のシステムに起因するものか、他メールシステム側の処理に起因するものかを切り分けるため、複数プロバイダに対してARC検証を実施しました。

表-1は、各プロバイダへの転送結果をまとめたものです。各プロバイダへの転送結果をまとめた表です。IIJ-officeはIIJ社内で業務利用 しているメールシステム、SMXはIIJセキュアMXサービスで異なるメールシステムです。

ARC認証失敗の原因を特定するため、RFC6376およびRFC8617準拠のPythonライブラリ「dkimpy」を用いて署名検証を行ったところ、IIJからM365宛のメールにおいてARC-Message-Signature（AMS）のverifyに成功することが確認されました。

この結果を基に被疑を深めMicrosoft社へ問い合わせを行ったところ、Microsoft社からの回答として、ARC署名の検証を行った際のハッシュ値が一致しないためarc = failとなっており、署名を行った時点から改変された可能性があるとの見解が示されました。

ハッシュ値の計算前には正規化が行われますが、確認したところ、IIJではsimpleアルゴリズムを使用していたのに対し、M365ではrelaxedアルゴリズムを使用していることが判明しました。

正規化とは、メールの内容を一定の形式に変換する処理であり、DKIMの標準であるRFC6376に準拠しています。RFC6376では、ヘッダーと本文の正規化アルゴリズムとして「simple」と「relaxed」の2種類が定義されています。「simple」は改行や空白をそのまま使用する方式で、送信時の内容を忠実に保持します。一方「relaxed」は空白や改行を無視し、連続する空白を1つにまとめるなどの処理を行います。

ARCの標準であるRFC8617では、ARCがDKIMの構文と処理を踏襲することが明記されており、特にbh（body hash）タグの扱いについては、DKIMと同様に正規化後の本文に対してハッシュ値を計算することが求められています。

また、他のGmailやOSSを用いてIIJサービスが生成するハッシュ値と一致すること、M365側の正規化アルゴリズムが他サービスやOSSと異なっている可能性がある旨も併せて伝えましたが、IIJ側のメールシステムがarc=failの原因である可能性を完全に否定できないことから調査が難しいとのことだったため、問い合わせはクローズとなりました。

その後、別件で確認されたarc = failの事象に対して、IIJ側の不具合を修正し、本文の正規化アルゴリズムをsimpleからrelaxedに変更する暫定対応を行いました。この変更により、ARC認証失敗の問題は解消されると想定されましたが、引き続きarc=failとなる事例が確認されたため、再度詳細な調査を行いました。

1度目の問い合わせの内容と同じく他プロバイダへの転送と並行して、メールヘッダーの中の値をより詳細に確認するようにしました。本文が空であるメールとテキストがあるメールを検体として検証を行ったところ、本文が空の場合bhタグのハッシュ値がIIJ側とM365側で異なっていました。IIJからは、Microsoft社に本不具合を修正するよう要請しました。

テキストがある場合はbhタグのハッシュ値が同じようでした。

ARCが準拠しているRFC6376のセクション3.4.4では、relaxedモードにおいても末尾の改行は除去してはならないと記述されています。
一方、M365では末尾改行を除いた状態でハッシュ値を計算していたため、bhタグの値が一致しませんでした。
このRFCの記述を根拠としてMicrosoft社に問い合わせた結果、M365側の不具合であることが認められました。

ARCの普及率はSPF、DKIM、DMARCなど他の送信ドメイン認証と比較して依然として低く、多くのメールシステムではARC認証が実装されていないのが現状です。これはARC認証を設定しなくても現時点では大きな問題が発生しないこと、またARCのRFCであるRFC8617がまだExperimental（実験的）であることが一因と考えられます。

Googleの送信者ガイドラインでもメールを定期的に転送する場合、ARC認証を使用することが推奨されています。また、ARCが適切に実装されていないと転送の過程で元のSPF、DKIMの検証が正しく行えなくなる可能性があり、DMARCポリシーによっては受信拒否され、メールの到達性に影響を及ぼす可能性があります。

ARCにはメール転送を行う中間システムの協力が不可欠です。IIJでは今後もARCを含む送信ドメイン認証技術への対応を継続し、メールの信頼性と到達性の向上に努めてまいります。

なお、フィッシング対策協議会の月次報告書「フィッシング報告状況」^（注2）によると、2024年12月はフィッシング報告数が過去最高値であったとレポートされており、IIJで観測した状況と同様の傾向が読み取れます。この結果から、IIJのみならず他ISPでも同様に観測しており、日本国内を標的としたフィッシングメールが数多く送られていたことが分かります。同レポートの総評として、日本国内の組織では、送信ドメイン認証を代表とするセキュリティ対策が遅れており、海外と比較してフィッシングメールが利用者に届きやすい状況になっていることを挙げています。

2025年以降も高い水準でフィッシングメールを観測しており、引き続き警戒が必要です。

ところで、2021年6月に発行した以前のIIR Vol.51^（注3）でもこのようなフィッシングメールの急増についてレポートしました。当時は新型コロナウイルス感染症を発端に、テレワークが急速に広まった時期です。これに便乗したフィッシングメールも観測しました。また、2019年にはメールに添付されたパスワード付きZIPファイルで感染を広げるEmotetが日本国内で猛威をふるい、広範囲での影響が確認されました。

このように、フィッシングメールやウイルスは活動の休止と再開を繰り返し、手を替え品を替え、時代の変化にも合わせてきています。

従って、セキュリティ対策は一度実施すれば終わるものではなく、脅威の進化に応じて継続的に見直し、強化していく必要があります。そしてそれは、終わりのない戦いであり、持続的な投資であり、組織全体で取り組むべき活動です。今後もIIJは、安心・安全な環境の維持に向けて、不断の努力を重ねてまいります。

定点観測として、IIJが提供するメールサービスで集計した、送信ドメイン認証の結果の割合を図-3〜図-6に示します。期間は2025年3月の1ヵ月間です。

前回の報告から送信ドメイン認証の検証に成功（pass）した割合がいずれも低下しています。日本国内の送信ドメイン認証、特にDMARCの対応は、Google Sender Guidelines^（注4）の発表で大きく普及していることが分かっています^（注5）。

従って、図-2のデータと合わせると、これは通常メールに対して、送信ドメイン認証に対応していない、または送信ドメイン認証の検証に失敗（fail）したフィッシングメールの量がデータに対して支配的になり、割合が低下したと考えるのが自然です。

なお、今回からARCの集計結果を追加しました。ARCは必ずしもすべての組織に対応が求められるものではありませんが、法人向けメールセキュリティのIIJセキュアMXサービスでは受信メールに対するARC署名に2019年から対応済みです。

次にIIJセキュアMXサービスで集計した経路暗号化（STARTTLS）について見ていきます。図-7は受信メールに対する経路暗号化の種類と割合です。PLAINは経路暗号化されていないことを示しています。

受信メールでは7割近くの通信で経路暗号化が行われていました。TLSv1.3による通信も半数近くで行われています。なお、12月にフィッシングメールが急増したことを2.3章で報告しましたが、このグラフでは12月頃にTLSv1.2の割合が増加していることが読み取れます。この結果から、当時フィッシングメールの送信にもTLSによる暗号化通信が行われていたことが分かります。

図-8はIIJセキュアMXサービスから送信されるメールに対しての経路暗号化の割合です。こちらは設備の都合で割合のみの集計ですが、概ね100%に近い推移で暗号化通信が行われていることが分かります。

前回、IIR Vol.59^（注6）で報告したときには80〜90%の間で推移していましたので、約2年経過してWebと同様、メールの世界も常時TLSの時代に突入したと考えて良さそうです。

なお、Google透明性レポート^（注7）でもメールの経路暗号化割合が公開されていますが、ほぼ同様の傾向が読み取れます。2023年に発表されたGoogle Sender Guidelinesで、STARTTLSを要件に盛り込んだことが大きな影響を与えたと考えられます。