休眠ドメインがなりすましに悪用される｜DMARCで防げない理由

2026.09.18

株式会社プリモポスト取締役

日吉浩之メール到達エバンジェリスト

最近、メールの到達性に関する専門家が集まるコミュニティで、”やられたら嫌だな～”と思う相談が投稿されていましたのでご紹介いたします。

クライアントが、数年前から使っていない古いドメインをいくつも保有しています。ところが最近、自社とはまったく関係のない外部のWebサイト経由で、大量の苦情（迷惑メール）が届くようになった。調べてみると、それらのメールのReply-To（返信先）ヘッダに、使っていない自社の古いメールアドレスが勝手に差し込まれていた。

メールを送信しているのは自社ではありません。サーバーも止めています。それでも「自社ドメイン宛の苦情」だけが増え続ける。相談者は「能動的に止める方法が思いつかない」と書いていました。

これは特殊なケースではなく、社内で誰も管理していないドメインを抱えている組織であれば、どこでも起こりうる話です。

今回は、この手口の仕組みと、なぜDMARCのPolicyをnone以外に設定していても防ぎきれないのか、そして休眠ドメインに対して最低限打っておくべきDNS設定を整理していきたいと思います。

Reply-Toスタッフィングという手口

犯罪者（攻撃者）の狙いはシンプルで、迷惑メールや詐欺メールを送る際に返信を受け取るアドレスと、送信元として名乗るアドレスを分離することです。

メールで送信者を示すヘッダを整理すると、次のとおりです。

MAIL FROM（エンベロープFrom / RFC5321.From）バウンスの戻り先。SPFの検証対象。
From:（ヘッダFrom / RFC5322.From）受信者の画面に表示される送信者。DMARCの検証対象。
Reply-To: 返信ボタンを押したときの宛先。どの認証技術の検証対象でもない。

攻撃者は、Fromには自分が用意した使い捨て用のメール配信ドメインを置き、Reply-Toにだけ他人のアドレスを書き込みます。

こうすると、認証はすべて自分のドメインで正当に通過しながら、

返信
苦情
問い合わせ

だけが第三者のドメインに流れ込む、という状態を作れます。

被害側から見ると厄介です。自社からは一通も送っていないのに、ドメイン評価に関わる苦情だけが自社ドメインに紐づいていく。そして送信していない以上、送信側の設定をいくらいじっても止まりません。

なぜDMARCを設定していても防げないのか

ここが今回のブログ記事で最も強調したい技術的なポイントです。

DMARCが評価するのはFromヘッダのドメインであり、Reply-Toは評価対象に含まれません。SPFはMAIL FROM、DKIMは署名したd=ドメイン、DMARCはそれらとFromのアライメントを見ます。Reply-Toはどこにも登場しません。

つまり、自社ドメインがReply-Toに書かれただけのメールは、そもそも自社ドメインのなりすましには当たらないため、p=rejectを設定していても拒否のトリガーにはなりません。

そして、DMARCの集約レポートにも原則として現れません。「DMARCを入れたから休眠ドメインは安全」という理解は、この一点において誤りです。

では休眠ドメインにDMARCを設定する意味はないのか。そんなことはありません。Reply-To悪用は、休眠ドメインが晒されるリスクのひとつにすぎないからです。

休眠ドメインが抱える4つのリスク

（１）Fromヘッダのなりすまし

最も典型的なリスクです。使っていないドメインは送信実績がないぶん、フィッシングやBEC（ビジネスメール詐欺）の送信元として狙われます。

特に、本業ドメインに似せて防衛目的で取得したタイポスクワッティング用ドメインを、認証設定をしないまま放置しているケースは危険です。

犯罪者（攻撃者）から見れば「実在の企業が保有していて、かつ何の防御もしていないドメイン」という理想的な素材になります。これはSPF/DKIM/DMARCの設定で明確に防げます。

（２）Reply-Toへの悪用

前述のとおり、認証技術では防げません。現実的な対応は、該当アドレスの受信を止める、苦情の発生源を特定して通報する、といった運用側の対処になります。「防ぐ」より「気づく」ことが重要な領域です。

（３）サブドメインテイクオーバー(dangling DNS)

解約済みSaaSに向けたCNAMEレコードが残っていると、第三者がそのサービス側で同じホスト名を取得し、自社サブドメイン上にフィッシングサイトを設置できてしまいます。

棚卸しではCNAMEとNSレコードの向き先が現存するサービスかまで確認してください。時間があるときに行うタスクとして必ず実施ください。

（４）ドメイン失効後の第三者取得

「使っていないから更新もやめる」が最も危険な場合があります。

失効ドメインを第三者が取得すると、そのドメイン宛に届き続けている古いメール（パスワードリセット、取引先からの請求関連など）をすべて受信でき、アカウント乗っ取りに直結します。

非常に悩ましい話でうが、一度でも業務で使ったドメインは手放さず、防御設定をしたうえで保有し続けるのが安全側の判断です。

休眠ドメインに最低限入れるべきDNS設定

この領域には業界団体のベストプラクティスがあります。M3AAWG（Messaging, Malware and Mobile Anti-Abuse Working Group）が2022年6月に公開している「Protecting Parked Domains BCP」です。

推奨される設定は、大きく「送信させない」「受信させない」の2本立てです。

送信させないに関する設定

; --- 送信させない ---
; SPF: 許可する送信元をゼロにする
example.jp.               IN TXT  "v=spf1 -all"
; SPFはサブドメインに継承されないため、ワイルドカードも併せて設定
*.example.jp.             IN TXT  "v=spf1 -all"

; DKIM: 公開鍵を失効状態で宣言する(鍵を置かない運用でも可)
*._domainkey.example.jp.  IN TXT  "v=DKIM1; p="

; DMARC: 認証に失敗したメールは拒否し、レポートを受け取る
_dmarc.example.jp.        IN TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@monitor.example.com"

受信させないに関する設定


; --- 受信させない ---
; Null MX (RFC 7505): このドメインはメールを受け取らないと明示する
example.jp.               IN MX 0 .

SPFのワイルドカードは必須です。

SPFレコードはサブドメインに継承されないため、example.jpだけに-allを置いても、mail.example.jpを名乗るなりすましは素通りします。

DKIMには2つの流儀があります。M3AAWGのBCPは「そもそもDKIMレコードを公開しない」ことを推奨しています（公開鍵がなければ署名検証は成立しないため）。

一方、ワイルドカードでp=(空の公開鍵=失効)を明示する方法も広く使われており、過去に発行した鍵の取りこぼしを潰せます。

Null MXは「受信しない」の積極的な宣言です。

MXもAレコードもない状態では、送信側MTAが数日間リトライを続けてしまいます。MX 0 .(ホスト名がドット単体)を置くことで即座にハードバウンスさせられます。

Webサイトだけを運用していてAレコードがあるドメインでも有効です。

RUAの送り先を別ドメインにする場合は、承認レコードが必要です。見落としの多いポイントです。休眠ドメイン自身はメールを受け取れないため、レポート送信先には監視用の別ドメインを指定することになります。

その場合、受け取る側のドメインに以下のレコードを置かないと、多くの受信事業者はレポートを送信しません。

example.jp._report._dmarc.monitor.example.com.  IN TXT  "v=DMARC1"

「設定して終わり」にならないために

ここまでの設定は、1ドメインだけなら30分もかからない作業です。問題はそのあとにあります。

まず、レポートは届き続けます。ruaを設定すると、各受信事業者からXMLを圧縮した集約レポートが日次で飛んできます。

休眠ドメインがなりすましに使われていれば、その事実はレポートにしか現れません。誰も開かないメールボックスに溜め続けているなら、設定していないのとほとんど同じです。

次に、ドメインが増えると破綻します。防衛目的で取得した

類似ドメイン
過去のキャンペーン用ドメイン
買収した事業のドメイン

数えてみると10や20を保有している組織は珍しくありません。XMLを手で読む運用は、この規模で維持できません。

さらに、設定はいつの間にか壊れます。DNS移管やCDN導入に伴うレコードの入れ替えで、休眠ドメインのレコードは「誰も使っていない」がゆえに無自覚に消されがちです。

最初の作業は保有ドメインの棚卸しから

今回のブログ記事の趣旨をチェックリストにまとめます。社内で保有しているドメインについて確認してみてください。

自社（グループ会社含む）が保有しているドメインを、すべて列挙できるか
そのうち、現在メール送信に使っていないドメインはどれか
休眠ドメインに v=spf1 -all / DMARC p=reject / Null MX が入っているか
SPFのワイルドカード（*.example.jp）まで手当てされているか
DMARCレポートの送り先が設定され、かつ実際に誰かが中身を確認しているか
外部ドメインにレポートを送る場合、_report._dmarc の承認レコードがあるか
解約済みSaaSに向いたままのCNAME/NSレコードが残っていないか
更新期限が切れかけているドメインはないか

最初の1項目で詰まるようであれば、それ自体がリスクの所在を示しています。冒頭の事例のように、問題は「使っていないドメイン」から起こります。使っているドメインは誰かが見ているので、異常があればすぐ気づくのです。

ツールを使う!?継続的な監視をどう担保するか

休眠ドメインの対策は、設定作業そのものよりも「入れた設定が維持されていること」「なりすましが起きたときに気づけること」を、担当者の記憶に頼らずに回す仕組みのほうが重要になります。

弊社が取り扱っているPowerDMARCは、複数ドメインのDMARC集約レポートを一元的に取り込み、XMLを読まずに

「どのドメインが、どこから、どれだけなりすまされているか」

を把握できるようにするサービスです。

休眠ドメインもまとめて登録しておけば、普段は誰も見ないドメインで異常が起きたときにも検知できます。レポート受信用のメールボックスを自前で用意・運用する必要がない点も、保有ドメイン数が多い組織では効いてきます。

なお今回のブログ記事で述べたとおり、Reply-Toの悪用そのものはDMARCで遮断できる攻撃ではありません。

ただし、休眠ドメインが「攻撃者にとって使い勝手のよい資産」である状態を解消し、実際に何が起きているかを可視化しておくことは、その後の対処のスピードを大きく変えます。

保有ドメインの棚卸しや設定方針のご相談も承っています。まずは自社が何本のドメインを抱えているかを数えるところから始めてみてください。