## この記事でわかること

- 自社ドメインがなりすましに使われていないかを確認する3つの方法
- 各方法で必要な権限と、得られる情報の違い
- なりすまされている事実が分かったときに、最初に取るべき対応

「うちのドメインが勝手に使われて、知らない取引先からクレームが来た」という相談が増えています。多くの場合、攻撃者は被害企業のサーバーには侵入していません。差出人欄（Header From）に他社ドメインを書くだけで、誰でも「○○株式会社からのメール」を装える、というのがインターネットメールの素朴な仕様だからです。

問題は、自社が攻撃に使われている事実を、当事者である自分たちが気づきにくいことです。攻撃メールは外部の取引先や顧客に届くため、自社受信箱には何も残りません。本記事では、特別なログ調査ツールを使わずに「自分のドメインが今この瞬間どう使われているか」を確認する3つの方法を、難易度順に整理します。

### なぜ自社では気づけないのか

なりすましメールの流れはシンプルです。攻撃者は自分のサーバー（またはクラウド配信サービス）から、`From: 経理@your-company.co.jp` と書いたメールを送信します。受信側のメールサーバーは差出人欄をそのまま表示するため、受け取った人は本物の取引先からの請求書だと信じてしまいます。

この一連の流れの中に、被害企業のサーバーは登場しません。**自社のメールログを何時間調べても、攻撃の痕跡は1件も見つからない**のがなりすましの特徴です。だから「不審な送信元のリスト」を外部から取り寄せる仕組みが必要になります。

メール認証の基礎については[メール認証の基礎](/blog/email-auth-basics)で整理していますので、SPF・DKIM・DMARCの役割があいまいな方は先に目を通してください。

## 確認方法は3つある（権限と情報量で使い分け）

実務でよく使う確認方法は次の3つです。情報量の多い順に並べました。

![なりすまし確認の3つの方法と必要な権限](/blog/check-domain-spoofing/check-methods.svg)

### 1. DMARC集計レポート（rua）を見る

最も網羅性が高い方法です。DMARC（ディーマーク、Domain-based Message Authentication, Reporting and Conformance）を `p=none` で設定し、`rua` パラメータに集計レポートの受信用アドレスを指定すると、Google・Yahoo・Microsoftなどの主要受信プロバイダから1日1通、その日に自社ドメインを差出人として届いたメールの統計XMLが送られてきます。

XMLには「どの送信元IPから・何通・SPF/DKIMの認証結果はどうだったか」が含まれます。自社で使っている送信元（社内SMTP、配信サービス等）のIPと突き合わせれば、**身に覚えのない送信元IPがそこにあるなら、それがなりすましの候補**です。

### 2. ドメイン診断ツールを使う

DMARC設定そのものがまだなく、レポートも届いていない場合は、まず公開DNS情報からSPF/DKIM/DMARCの設定状態を確認します。設定不備はなりすましの被害を拡大させる原因です。例えばDMARCが未設定だと、受信側は不正なメールを受け取ってよいか判断できず、結果として正規メールと並んで配信されてしまいます。

このカテゴリは権限が要りません。社外に公開されているDNS情報だけで完結します。本サイトの[ドメイン診断](/diagnose)も同じ仕組みで動いており、数十秒で設定の穴を一覧化できます。

### 3. Google Postmaster Tools

Gmail宛に送るメール量が多い企業向けの補助手段です。自社ドメインのDNSにTXTレコードで所有確認を入れたあと、Gmail側で集計しているスパム率や認証結果が見えます。一定の送信ボリューム（おおむね月数百通以上）がないと統計が出ないため、社内利用が中心のサイト運営者では補助的な位置づけになります。

実務では「DMARCレポート + 診断ツール」を主軸にし、Postmaster Toolsはメルマガを出している部門があれば追加で見る、という運用が現実的です。さらに「自社ドメインに似た名前で不正な SSL 証明書が発行されていないか」を継続監視したい場合は [CT log（Certificate Transparency log）の仕組み](/blog/ct-log-basics-smb) を理解した上で [CT log 監視ツール 5 選比較](/blog/ct-log-monitoring-tools-guide) を併用すると、なりすましサイト構築の予兆を最短で掴めます。

## DMARCレポートからなりすましを見つける流れ

DMARC設定がまだの場合は、最初に `p=none`（観察モード）で導入し、1〜2日経ってから集計レポートが届くのを待ちます。設定手順は[DMARC設定方法を徹底解説](/blog/dmarc-setup-guide)にまとめています。

![DMARCレポートで認識していない送信元を見つけるフロー](/blog/check-domain-spoofing/dmarc-detect-flow.svg)

レポートが届き始めたら、次の順で読み解きます。

1. **送信元IPを一覧化する**: 受信したXMLを集計し、ユニークな送信元IPと通数を表にします。手作業がきついので、無料の可視化ツール（dmarcian、Postmark DMARC Digestsなど）を使うのが現実的です。具体的なXML構造の読み方は[DMARCレポートの見方](/blog/dmarc-report-reading)を参照してください。
2. **「認識ある／なし」で仕分ける**: 自社が把握している送信元（社内SMTP、Microsoft 365、Google Workspace、Resendなどの配信サービス）のIPに該当するかを確認します。`spf=pass` かつ `dkim=pass` で「認識ある」送信元なら正常です。
3. **認識のない送信元を絞り込む**: 自社のIPでも委託先配信サービスでもないIPが混ざっていれば、なりすまし、または設定漏れによる第三者送信の疑いがあります。

特に注意したいのは、見覚えのある名称（例: `mailgun.net`）だが社内では契約していないケースです。実際になりすまされている可能性が高いので、社内全部署に「契約しているメール配信サービスはあるか」を確認したうえで除外していきます。

## なりすましが発覚したら、最初の48時間で何をするか

「認識のない送信元IPから自社ドメインで大量送信されている」と確認できたら、対応は次の優先順で進めます。

**初日（〜24時間）:**

- DMARCポリシーを `p=quarantine` に引き上げる。これで認証に失敗したメールは受信側で迷惑メールフォルダに振り分けられ、被害が一時的に止まります。`p=reject` まで一気に上げる前に、自社の正規メールが誤って弾かれていないかを翌日のレポートで確認します。
- 主要な取引先に注意喚起メール（自社の正規SMTPから送る）を出します。「弊社ドメインを名乗る不審メールが出回っています、添付ファイルやURLを開く前にこちらで確認してください」と一報を入れるだけで、被害連鎖を大きく減らせます。

**翌日〜1週間:**

- DMARCレポートを毎日確認し、`p=quarantine` 後も認識のない送信元から送信が続いているかをモニタします。続いていれば、攻撃者は気にせず送り続けているのでポリシーを `p=reject` に引き上げて完全拒否に切り替えます。
- 自社の正規送信が誤って弾かれていないかをログで確認し、必要ならSPF/DKIMの設定を整えます。SPFのinclude上限超過など、典型的な落とし穴は[SPF設定方法](/blog/spf-setup-guide)に整理しています。

**継続的な対応:**

- 月1回のDMARCレポート確認をルーティン化します。新しい配信サービスを契約したのに認証設定を忘れる、という社内オペレーション漏れも同じ手順で検知できます。

## まずは「現状を見える化」してから動く

なりすましの確認は、特別なツールを買わなくても、DNS編集権限と1〜2日の観察期間があれば始められます。重要なのは推測で動かないことです。「うちは大丈夫だろう」「うちなんて狙われない」という前提で何もしないと、最初の通報を取引先から受けることになりかねません。

逆に「うちはなりすまされているはずだ」と決めつけて、いきなり `p=reject` を入れてしまうと、自社の正規メール（請求書送付など）まで止まります。観察 → 仕分け → 段階的強化の順番を守るのが安全です。

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。