最近、差出人にブランド名の入ったメールを受け取って「本物かな？」と思ったことはありませんか？
「ECサイトや銀行を装ったメールで個人情報が盗まれた」といったニュースを目にすることも増えています。
「どうして騙されるの？」と思うかもしれませんが、 実はあなたが普段受け取っているメールの中にも、見た目は本物そっくりななりすましメールが紛れている可能性があります。
では、なぜこうしたなりすましメールが、正規のメールのように届いてしまうのでしょうか？
今回は、多くの人が抱く疑問をもとに、なりすましメールの仕組みをわかりやすく解説します。
疑問1：なんで「なりすましメール」が送れるの？
メール送信に使われる「SMTP（Simple Mail Transfer Protocol）」という仕組みは、なんと1980年代に作られた古い仕組みです。
この仕組みには、「差出人の名前（From欄）を、誰でも自由に、何のチェックもなく設定できてしまう」という、セキュリティ上の根本的な弱点があります。
例えるなら、「手紙の差出人欄に、他人の名前を勝手に書いても、配達員も受け取り手も、それが本当の名前かどうかを原則確認しない」ようなものです。つまりSMTPには、誰がそのメールを送っているか、確認する仕組みがないのです。
攻撃者は、この弱点を突いて、次の2つの部分にあなたの会社のアドレスを勝手に設定します。
| 項目 | 説明 | 書き換え可能性 | 備考 |
|---|---|---|---|
| MAIL FROM（Envelope-From） | 送信時に「MAIL FROM:<…>」コマンドで指定されるSMTP上の送信元。 | ✅ 非常に容易 | 任意のアドレスを設定できる。SPFがないと検知困難。 |
| From: （ヘッダー内） | 表示上の差出人。メール本文の一部。 | ✅ 最も多い偽装箇所 | 見た目上「〇〇社」になりすますのに利用される。 |
攻撃者は、メールの「送信元の情報」を自由に書き換えることができます。
つまり、受信者の画面に表示される差出人アドレス（見える情報）と、実際にメールを送っている本当の送信元（見えない情報）の両方を偽装できるのです。
そのため、実際には関係のない相手から送られたなりすましメールでも、受信者の画面では、正規の会社から来たように見えます。
実際の送信サーバーは攻撃者のものですが、見た目は完全に正規ドメインに偽装されてしまいます。
疑問2：なりすましを見抜く仕組みはないの？
実は、メールの世界では「なりすましを防ぐための認証ルール」が3つあります。
それがSMTPの弱点を補うために追加された、送信ドメイン認証技術「 SPF／DKIM／DMARC 」です。
| 技術名 | 役割 | 例えるなら… |
|---|---|---|
| SPF | そのメールサーバー（IPアドレス）が、本当にそのドメインから送信する許可を持っているかを確認する | 差出人の「印鑑」 |
| DKIM | メールの本文や差出人情報が改ざんされていないか、電子署名で確認する | 封筒の「封印」 |
| DMARC | SPF／DKIMの結果と「From欄」の整合性を照合し、失敗時の扱い（拒否・隔離・通過）を決める | 配達員が「差出人印鑑と宛名を照らし合わせるルール」 |
この3つを組み合わせることで、SMTPの“誰でも送れる”という欠点を補い、
本当に正しいドメインからのメールかどうかを受信側で自動判定できるようになりました。
🛡️ Gmailなどの主要サービスでは設定が必須に
2024年以降、GmailやYahoo!メールなどの主要プロバイダは、送信側に対して SPF／DKIM／DMARCの設定を義務化 しています。
たとえば、Googleは2024年2月から次のような方針を発表しています。
- 1日5,000通以上をGmail宛に送信するドメインは、SPFまたはDKIMの設定が必須
- DMARCポリシーも p=none 以上で設定する必要あり（設定なしは警告対象）
- これらを満たさない送信ドメインからのメールは、迷惑メール扱いまたは拒否される可能性あり
つまり、認証設定をしていない企業は「メールを届けてもらえない時代」になっているのです。
SPF／DKIM／DMARCの結果は、メールの「ヘッダー情報」という部分に記載されています。
次に、ヘッダーを開いて“本当の送信元”を見分ける方法を紹介します。
疑問3：本当の送信元はどこに書いてあるの？メールヘッダーの見方
ヘッダーには、普段のメール画面では見えない「通信の記録」が含まれており、誰が・どのサーバーから・どの経路でメールを送ったのかがすべて残っています。
つまり、ヘッダーを見れば“本当の送信元”を確認できるのです。
では、実際にどのように見ればよいのでしょうか？
1. メールヘッダーとは？
メールヘッダーは、受信者には普段見えない通信記録の部分です。
誰が、どのサーバーから、どの経路でメールを送ったのかがすべて記録されています。
ヘッダーを開くと、多くの情報が並びますが、なりすましメールを見抜くポイントは次の4つです👇
| 項目 | 意味 | チェックポイント |
|---|---|---|
| Received | メールが通過したサーバーの履歴 | 最上段（自組織の受信サーバーが付与）を起点に信頼し、上→下へ遡って確認。最下段は偽造され得る。 |
| Return-Path | 配送上の差出人アドレス（SMTPの MAIL FROM で指定されるアドレス）で、配信エラー時の返送先（バウンス先）を示す技術的な差出人です。 | SPF検証の対象。SRSで書き換わる場合あり。空（<>）のバウンスではSPFはHELO/EHLOで評価。 |
| Authentication-Results | SPF／DKIM／DMARCの認証結果 | 自組織が付与した最上段のみ信頼。 |
| From | 表示上の差出人 （RFC5322.From） | 偽装が容易。DMARCはこのFromを基準に整合性を評価。 |
2. 本当の送信元を確認するステップ
STEP 1: 最上段の Received を起点に、上から下へ遡る
Received: from mail.fakehost.net (mail.fakehost.net [203.0.113.55] )
- 最上段（自組織が付与）を起点に信頼し、上→下へと信頼可能な経路を辿ります
- 最下段のReceivedは改ざん可能なので注意が必要です。
STEP 2: Authentication-Results を確認
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=info@brand.co.jp;
dkim=pass header.d=brand.co.jp;
dmarc=pass header.from=brand.co.jp
→ ここには受信サーバーが実施した認証結果が記録されています。
- spf=pass → 送信元IPがそのドメインに許可されている
- dkim=pass → 電子署名が正しい（改ざんなし）
- dmarc=pass → RFC5322.From （表示上の差出人）とSPF/DKIM の整合性が取れている
DMARCは「SPF または DKIM」のどちらか一方が(a) 認証 pass ＋ (b) RFC5322.From（表示上の差出人） と整合（アライメント） すれば passします。
アライメントの要件
SPFアライメント: エンベロープ From ドメインとヘッダ From ドメインが一致。
DKIMアライメント: DKIMドメインとヘッダ From ドメインが一致。
例）転送で SPF fail でも DKIM pass & alignment なら DMARC pass。
- 転送メールなど、メール経路で内容が変更されたり、エンベロープFrom（Return-Path）が書き換えられたりするケースでは、SPF認証はFailしやすい傾向があります。
STEP 3: 「Return-Path」も確認
Return-Path: <bounce@fake-domain.com>
Return-Path は、メール配送時にSMTPコマンド（MAIL FROM）で指定された「配送上の差出人アドレス」で、配信エラー（バウンス）を返す宛先を示します。
このドメインが SPF 検証の対象 になります。
SPF 認証では、「Return-Path のドメイン」と「実際に送信したサーバーの IP（Receivedヘッダーに記録）」を照合し、そのサーバーが Return-Path ドメインに登録された送信許可IPであるかを確認します。もし一致しなければ spf=fail となり、なりすましや転送経路の問題が疑われます。
💡 注意
- Return-Path は“、配送上の差出人（バウンス宛先）を示す識別子です。
- SRS（Sender Rewriting Scheme） により、転送サーバーが Return-Path を自分のドメインに書き換えることがあります（SPFを維持するため）。
- バウンスメール（エラーメール） では、Return-Path が空（<>）になり、SPFは HELO/EHLO ドメインで評価されます。
3. 正規メールとなりすましメールの比較
【正規メールの場合】
From: “Brand” official@brand.co.jp
Return-Path: bounce@brand.co.jp
Received: from mail-out.brand.co.jp [54.240.x.x]
Authentication-Results:
spf=pass dkim=pass dmarc=pass
✅SPF／DKIM／DMARC いずれもpass。
正規ドメイン（brand.co.jp）から正しい経路で送信されていることを示しています。
【なりすましメールの場合】
From: “Brand” official@brand.co.jp
Return-Path: bounce@fake-brand.co.jp
Received: from mail.fakehost.net [203.0.113.55]
Authentication-Results:
spf=fail dkim=none dmarc=fail
❌ SPF／DKIM／DMARC がいずれも失敗。
見た目は本物のアドレスにそっくりでも、別サーバーから送信されたなりすましメールです。
4. まとめ
| チェック項目 | 見る場所 | 安全な状態 |
|---|---|---|
| 実際の送信サーバー | 最上段の Received から上→下へ遡って信頼経路を確認 | 信頼できるドメインまたはIP |
| SPF | Authentication-Results | pass |
| DKIM | Authentication-Results | pass |
| DMARC | Authentication-Results | SPFまたはDKIMのいずれかが整合してpass |
| From | 表示（RFC5322.From） | 偽装容易。DMARC整合の基準となる。 |
結論：本当の送信元を知るには「最上段の Received」と「Authentication-Results（SPF／DKIM／DMARC）」の整合を確認すること。
知っておいてほしいこと
「From欄」が偽装されていても、あなたの会社のドメインやメールサーバーが乗っ取られたわけではありません 。攻撃者は、あなたの会社のブランドを装ってメールをばらまいているだけなのです 。
DMARCを設定すれば、こうした“見た目だけの偽装”を可視化・制御できます。
DMARCを導入すると「見えない攻撃」が見えるようになる
DMARCを設定すると、単にメールをp=reject（受信拒否）にできるだけでなく、「誰が自分のドメインを使ってなりすましメールを送っているのか」を可視化できるようになります。
その仕組みが、DMARCレポート（集計レポート）です。
これは、受信サーバー（Gmail・Microsoft・Yahooなど）が、あなたのドメインになりすまして送信されたメールの認証結果を毎日まとめて報告してくれる仕組みです。
つまりDMARCレポートを見れば、次のことが確認できます。
- 正規の送信サーバーからのメールなのか
- なりすましの第三者からの送信なのか
DMARCレポートで「なりすましの正体」を見抜く
たとえばDMARC集計レポートで、こんな結果が出ているとします👇
| Source IP | SPF | DKIM | Disposition | 備考 |
|---|---|---|---|---|
| 203.0.113.25 | pass | pass | none（通過） | 正規送信（Gmail経由） |
| 45.13.12.99 | fail | fail | reject （受信拒否） | 不明な送信元（なりすまし） |
この「45.13.12.99」こそが、From欄だけ偽装して送信してきた攻撃者です。
なりすましメールの受信者から見たときの違い
| 状況 | 受信者の見え方 | 処理 |
|---|---|---|
| DMARC未設定 | 普通に「support@example.co.jp」から届いたように見える | ⚠️ 偽装に気づかない |
| DMARC設定（p=quarantine） | Gmailなどで「送信元を確認できません」と警告表示 | 🚫 迷惑メール扱い |
| DMARC設定（p=reject） | メールが破棄され、受信者の受信箱に届かない | ✅ 被害防止 |
DMARC設定をp=reject（受信拒否）にすることで、なりすましメールがあった場合でも
受信者へは届かず、フィッシングなどの被害を防ぐことができます。
まとめ
「From欄にあなたの会社ドメインが表示されている＝正規メール」とは限りません。
メールの世界では、“見た目”はいくらでも偽装できるのです。
だからこそ、会社のブランドを守るためには、DMARCによる認証と可視化が大切。
不明な送信元を見逃さないことで、 自社ブランドをなりすましから守ることができます。
