メールスプーフィング（Email Spoofing）
概要
メールスプーフィング（Email Spoofing） は、メールの送信者アドレスを偽装して受信者に正規の差出人からのメールであるかのように見せかける攻撃手法です。SMTP（RFC 5321）にはメールアドレスの真正性を検証する仕組みが組み込まれておらず、送信者は任意の From アドレスを自由に設定できます。この仕様上の制約が、スプーフィングを技術的に容易にしています。
FBI IC3 の 2025 年報告書によると、フィッシング・スプーフィング関連の苦情件数は 191,561件 に達し、報告された損失額は 2億1,500万ドル でした。ビジネスメール詐欺（BEC）は 30億4,600万ドル の損失を記録しており、メールのなりすましは依然として深刻な脅威です。
現在は SPF・DKIM・DMARC の 3 層防御でスプーフィングを検知・排除する仕組みが整備されています。Google（2025 年 11 月強化）、Microsoft（2025 年 5 月強化）、Yahoo がそれぞれメール認証の義務化を進めており、認証が不十分なメールは受信拒否される運用に移行しています。
仕組み
スプーフィングは SMTP がエンベロープ From とヘッダー From の一致を要求しない構造的な弱点に起因し、SPF・DKIM・DMARC の 3 層で防御します。
SMTP の構造的な弱点
メールには「エンベロープ」と「ヘッダー」という 2 つの送信者情報があります。
エンベロープ From（RFC 5321 の MAIL FROM）は、サーバー間のメール配送に使われるアドレスです。受信者のメールクライアントには通常表示されません。ヘッダー From（RFC 5322 の From フィールド）は、受信者の画面に「差出人」として表示されるアドレスです。
SMTP はこの 2 つのアドレスが一致することを要求しません。攻撃者はヘッダー From に任意のドメイン（例: ceo@yourcompany.com）を設定し、エンベロープ From には自分が管理するドメインを使ってメールを送信できます。受信者の画面には偽装されたヘッダー From だけが表示されるため、正規のメールと区別がつきません。
典型的な攻撃パターン
スプーフィングは主に 3 つのパターンで悪用されます。
1 つ目は表示名の偽装です。"山田太郎 - 経理部" <attacker@malicious.com> のように、表示名だけを正規の人物にして実際のアドレスは攻撃者のものにします。技術的にはスプーフィングではありませんが、受信者がアドレスを確認しなければ気づけません。
2 つ目はヘッダー From のドメイン偽装です。ヘッダー From を ceo@yourcompany.com に設定し、あたかも社内からのメールに見せかけます。SPF と DMARC が未設定のドメインはこの攻撃に対して無防備です。
3 つ目は類似ドメインの利用です。yourcompany.com に似た yourcompnay.com（typosquatting）を登録し、そのドメインから正規の SPF / DKIM 設定でメールを送信します。認証自体は pass するため、受信者がドメイン名を注意深く確認しない限り見抜けません。
3 層防御の仕組み
SPF・DKIM・DMARC はそれぞれ異なる側面からスプーフィングに対処します。
SPF はエンベロープ From のドメインに紐づく DNS レコードを参照し、送信元 IP アドレスが許可リストに含まれているかを検証します。許可されていない IP から送信されたメールは SPF fail になります。ただし SPF はヘッダー From を検証しないため、単独ではスプーフィングを防げません。
DKIM は送信サーバーがメールに電子署名を付加し、受信サーバーが DNS に公開された公開鍵で署名を検証します。署名の d= タグに指定されたドメインが検証対象です。メール本文やヘッダーの改ざんを検知できますが、署名ドメインとヘッダー From の一致を強制する仕組みではありません。
DMARC がこの 2 つを統合します。SPF または DKIM のいずれかが pass し、かつそのドメインがヘッダー From とアライメント（一致）していれば DMARC pass です。fail した場合は、ドメイン所有者が DNS で宣言したポリシー（none / quarantine / reject）に従って受信サーバーがメールを処理します。p=reject を設定すれば、ヘッダー From を偽装したメールを受信段階で拒否できます。
確認方法
自社ドメインがスプーフィングに対して保護されているかは、SPF・DKIM・DMARC レコードの存在と設定内容で判断します。
dig TXT example.com | grep spfdig TXT default._domainkey.example.comdig TXT _dmarc.example.comSPF レコードが v=spf1 で始まること、DKIM レコードが存在すること、DMARC レコードの p= タグが quarantine または reject に設定されていることを確認します。p=none のままでは、なりすましメールを検知してもブロックしません。
外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/mail-auth?domain=example.com"レスポンスは次の形式で返ります。
{
"success": true,
"data": {
"spf": {
"record": "v=spf1 include:_spf.google.com ~all",
"exists": true
},
"dkim": {
"record": null,
"exists": false,
"selector": "default"
},
"dmarc": {
"record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com",
"exists": true
},
"bimi": {
"record": null,
"exists": false
}
},
"error": null,
"meta": { "responseTime": 120 }
}data.spf.exists、data.dkim.exists、data.dmarc.exists がすべて true であれば、3 つの認証レコードが外部から参照可能です。data.dmarc.record フィールドの値で p= タグのポリシーも確認できます。DKIM の検証にはセレクタの指定が必要で、selector パラメーターで指定します（デフォルトは default）。
curl "https://labee.dev/api/mail-auth?domain=example.com&selector=google"よくある問題
スプーフィング対策の設定で陥りやすいのは、DMARC ポリシーの未強化、認証の部分的な設定、類似ドメインの見落としです。
DMARC を p=none のまま運用している
DMARC レコードを公開しても p=none ではメール処理に影響を与えません。攻撃者がヘッダー From を偽装したメールは、認証失敗として記録されるだけで受信者に届き続けます。rua レポートで正規の送信元が pass していることを確認したら、p=quarantine → p=reject と段階的に移行します。
SPF だけ設定して DKIM と DMARC を省略する
SPF はエンベロープ From の IP アドレスしか検証しません。ヘッダー From に別ドメインを設定するスプーフィングに対して SPF 単独では防御になりません。DKIM で署名を付加し、DMARC でアライメントを強制して初めて、ヘッダー From の偽装を排除できます。
SaaS メールサービスの認証設定を忘れる
マーケティングツールやカスタマーサポートツールが自社ドメインでメールを送信する場合、そのサービスの送信 IP を SPF に追加し、DKIM 署名を設定する必要があります。設定漏れがあると、正規のメールが DMARC fail になり迷惑メールフォルダに振り分けられます。DMARC の rua レポートを確認すると、認証に失敗している送信元 IP を特定できます。
類似ドメインによるスプーフィングを見落とす
SPF / DKIM / DMARC は自社ドメインの偽装を防ぎますが、攻撃者が yourcompnay.com のような類似ドメインを取得してメールを送信するケースには対処できません。類似ドメインは正規に取得されたドメインのため、攻撃者側で SPF / DKIM / DMARC を正しく設定でき、認証は pass します。防御には、主要な類似ドメインを先行取得する、DMARC レポートで不審なドメインを監視する、といった運用が必要です。
メールヘッダーの確認方法を知らない
受信したメールがスプーフィングかどうかを判断するには、メールヘッダーの Authentication-Results フィールドを確認します。Gmail では「メッセージのソースを表示」、Outlook では「メッセージのプロパティ」からヘッダーを確認できます。spf=pass、dkim=pass、dmarc=pass がすべて揃っていれば、そのメールは認証に成功しています。1 つでも fail があれば、偽装の可能性を疑います。
業界の動向
Google は 2025 年 11 月に大量送信者（1 日 5,000 通以上）に対するメール認証要件を強化し、非準拠メールの拒否率を段階的に引き上げています。Microsoft も 2025 年 5 月に Outlook.com / Microsoft 365 向けの送信者要件を施行し、SPF・DKIM・DMARC の 3 つすべてを必須としました。Yahoo も同様のポリシーを適用しています。
これら 3 社のメールボックスプロバイダーは、B2C メールリストの約 90% を占めます。メール認証の設定が不十分なドメインから送信されたメールは、受信拒否や迷惑メール判定の対象になります。DMARC のポリシーを p=reject まで強化することは、自社ドメインの保護だけでなくメール到達率の維持にも直結します。