利用終了ドメイン名を狙うなりすましメール―DMARC Report分析から見えた実態と対策

この記事は、NTT docomo Business Advent Calendar 2025 25日目の記事です。

みなさんこんにちは、イノベーションセンターの冨樫です。Network Analytics for Security¹ (以下、NA4Sec)プロジェクトのメンバーとして活動しています。

NTTドコモビジネスでは、ドロップキャッチ等のリスクに対応するため、すでに使い道がなくなったドメイン名(以下、利用終了ドメイン名)であっても、永年保有するポリシーを採用しています。ただ、利用終了ドメイン名を保持し続けることで、金銭面・管理面のコストがかかり続けます。また、不必要にドメイン名を保持し続けることはインターネット上の公共資源が解放されないため、健全性を損なっているという指摘も存在します。そのため、この利用終了ドメイン名を将来的に廃止することを目標に各種分析をしています。

今回は、利用終了ドメイン名におけるDMARC (Domain-based Message Authentication, Reporting, and Conformance) Reportを収集したので、そこから見えたことを紹介します。

DMARC Reportの分析
なりすましメールの内容
対策
まとめ

DMARC Reportの分析

DMARC Reportとは、受信側のメールサーバーで行われたDMARC認証(SPF/DKIM)の結果について、ドメイン名管理者へフィードバックを送る仕組みのことであり、ruaとrufのタグが使用されます。

rua : 集計レポート(ruaレポート)を受信します。一定期間ごとに、認証成功・失敗の件数や送信元IPアドレスなどがXML形式で各メールサービスから送られてきます。
ruf : フォレンジックレポート(rufレポート)を受信します。メールの認証失敗が発生したとき、ヘッダや本文の一部を含む詳細情報が送られてきます。

上記2種類のレポートによって、自社で管理するドメイン名から送信されたメールの情報を収集できます。ただし、今回の調査ではフォレンジックレポートについてはプロバイダから受け取ることができませんでした。このレポートはメールの件名や本文の一部を含む可能性があるため、プライバシー保護の観点から送信をサポートしていない、あるいは意図的に送信しない受信プロバイダが大半であると考えられます。

ここで重要なことは、今回レポートを収集した利用終了ドメイン名は現在ではメールの送信に使用していないということです。つまり受けとったレポートはすべて何者かが利用終了ドメイン名を騙ったなりすましメールに関する情報であるということです。

今回の調査では、NTTドコモビジネスで管理する149個の利用終了ドメイン名を対象に2025年6月から10月までに収集したレポートを対象に分析をしました。その結果、149個のドメイン名のうち、60個でなりすましメールが送信されていて、その総数は2083件に及ぶことがわかりました。

送信元の国、宛先サービス

下記は、受け取ったレポートから、なりすましメールの送信国と宛先のメールサービスを集計した結果です。

ここから、なりすましメールの半数以上は中国のサーバから送信されていることがわかります。また、宛先のメールサービスの半数以上はドコモメールであることがわかります。フォレンジックレポートを受信できなかったためあくまで予想ですが、送信元として騙られた利用終了ドメイン名は当然すべてNTTドコモビジネスと関連するものであるため、ドコモメールに対してなりすましメールを送信することで、受信者の警戒を下げる目的があった可能性を考えています。

さらに、ドコモメールの他にもKDDIやGMOのメールサービスに送信されていることから、日本語話者を狙ったなりすましメールが送信されているとも考えられます。

騙られたドメイン名の用途

今回、レポートを収集をした利用終了ドメイン名は元々、複数の正規用途で使われていましたが、大まかに下記の4種類に分類できます。

コーポレートドメイン : NTTドコモビジネス関連会社の統廃合により利用されなくなったドメイン名
ウェブサイト : かつてウェブサイトの接続先に利用されていたドメイン名
メール用 : メールの送受信に利用していたドメイン名
商標保護 : 利用実態はないが、NTTドコモビジネス関連サービスで利用されているドメイン名と似たドメイン名を商標保護の観点から登録したもの

下記は、なりすましメールに悪用されたドメイン名の数を利用用途ごとに集計した結果です。(分類が難しいドメイン名は、除外しています)
用途によっては十分な数のドメイン名がないため、統計的に有意な結果とは言えませんが、各利用用途で悪用された比率に大きな乖離はないことがわかります。このことから、なりすましメールの送信者は、なりすましに利用するドメイン名を選定する際、元々そのドメイン名がどのような用途で使われていたのかという調査は活発にはしていない可能性があると考えました。

騙られたドメイン名のTLD

次に、なりすましメールに悪用されたドメイン名の数をTLD(Top Level Domain)ごとに集計したところ、.JPが最もなりすましメールに使われるという結果が見えました。これは、日本語話者になりすましメールを送る際に受信者の警戒心を下げられることや、レピュテーションが他のTLDに比べると良い場合があることなどが原因である可能性があります。

また、TLDに注目した分析ではありませんが、平仮名・カタカナ・漢字が含まれる国際化ドメイン名については悪用される可能性が極端に低いことも確認しています。一般的に国際化ドメイン名からメールが来ることは稀であることから、受信者の警戒を煽る可能性があり、なりすましに利用するメリットが低いためと考えています。

なりすましメールの内容

冒頭に記述したように、今回の調査ではフォレンジックレポートを受け取ることができなかったため、基本的にはなりすましメールの内容を確認できませんでした。ただ、この施策では観測対象のドメイン名に対して送信されたメールの収集も行っていて、そこから一部のなりすましメールの内容を確認できました。

To: xxxxxxxx@aaa.example.jp (利用終了ドメイン名)
datetime: 2025-MM-DDTHH:MM:SS.000Z
Subject: Returned mail: see transcript for details
From: Mail Delivery Subsystem <MAILER-DAEMON@bounce.example.net>
Body: This message was created automatically by mail delivery software.  Deny to deliver the message you sent to one or more recipients.  Reasons for deny are as follows:    REASONS: Policy Reasons    RECIPIENTS:    yyyyyyyyy@bbb.example.co.jp (なりすましメールの宛先)

受信側のメールアドレスが存在しない場合やメールフィルターに弾かれた場合、利用終了ドメイン名宛に上記のような未達メールが届くため、その内容からなりすましメールの送信アドレス(偽装)、宛先アドレス、メールの内容等を確認できる場合があります。このような未達メールを数件確認したところ、いずれも日本企業(証券会社、鉄道会社など)が提供するサービスのフィッシングメールであることがわかりました。

対策

これまでの調査から利用終了ドメイン名であっても、なりすましメールの送信元として悪用されることがわかります。これに対抗するため、NTTドコモビジネスでは対象のドメイン名に対して以下のDNSレコードを設定し、対策を講じています。

example.jp.  IN  MX    0 .
example.jp.  IN  TXT   "v=spf1 -all"
_dmarc.example.jp. IN TXT "v=DMARC1; p=reject; aspf=s; rua=mailto:rua@example.com; ruf=mailto:ruf@example.com"

MX: レコードが設定されたドメイン名でメールの受信をしないことを明示している。
SPF : あらゆる送信元IPアドレスからのメールを不正メールとして処理する。
DMARC : SPFの認証に失敗したメールの受取を拒否することを推奨するポリシー。指定したメールアドレス宛に集計レポートとフォレンジックレポートの送信を依頼。

今回の調査からDMARCレコードを設定することの重要性を再認識しました。

SPF認証は、メールデータ上のEnvelope-From(配送上の送信元)で指定されたドメイン名をもとに行われます。そのため、なりすましメールの送信者がEnvelope-Fromに「送信元IPアドレスを許可する、自身が管理するドメイン名」を設定し、Header-From(メールソフト上の表示名)だけにNTTドコモビジネスの利用終了ドメイン名を設定した場合、SPF認証自体はパスしてしまうことがあります。この手法はなりすましメール全体の13%で使用されていました。このとき、DMARCレコードが設定されていれば、SPFアライメント(Header-FromとEnvelope-Fromのドメイン名が一致しているか)の検証も行われるため、DMARC認証でフェイルさせることができます。