フィッシング詐欺（Phishing）
概要
フィッシング詐欺（Phishing） は、銀行やクラウドサービスなど正規の組織を装ったメールや Web サイトを使い、パスワード・クレジットカード番号・個人情報を詐取する攻撃です。
APWG（Anti-Phishing Working Group）の報告によると、2025 年第 2 四半期には 113 万件超のフィッシング攻撃が観測されました。2024 年通年では 480 万件に達し、2025 年は 500 万件を超える見通しです。攻撃件数は年々増加しており、生成 AI を使ったメール文面の巧妙化が拍車をかけています。
フィッシングの多くはメールを起点とします。攻撃者はヘッダー From のドメインを詐称し、本物と見分けがつかないメールを送信します。ここで有効な防御策が DMARC です。DMARC はヘッダー From と SPF / DKIM の認証結果をアライメント検証し、認証失敗メールを隔離（quarantine）または拒否（reject）します。RFC 7489 の本文でも、DMARC の主要なユースケースとしてフィッシング対策が明記されています。
ただし DMARC が防げるのは「正規ドメインの詐称（exact-domain spoofing）」のみです。examp1e.com のような類似ドメイン（cousin domain）や、表示名のなりすましには対応できません。技術的対策とユーザー教育の両輪で防御する必要があります。
仕組み
フィッシングは偽サイトへの誘導で認証情報を詐取し、DMARC と BIMI がメール経由の攻撃を技術的に抑制します。
フィッシング攻撃の典型的な流れ
- 攻撃者が正規サービスのログインページを模倣した偽サイトを用意する
- ヘッダー From を詐称したメールを大量送信する。件名には「アカウントが停止されました」「不正アクセスを検出しました」など緊急性を煽る文言を入れる
- 受信者がメール内のリンクをクリックし、偽サイトにアクセスする
- 偽サイトに入力された認証情報や個人情報が攻撃者のサーバーに送信される
メール以外にも SMS（スミッシング）、音声通話（ビッシング）、QR コード（キッシング）を使う手口があります。2025 年第 4 四半期には SMS を使ったフィッシングの増加が報告されています。
DMARC によるフィッシング防御
DMARC は受信サーバー側で機能するフィッシング対策です。
- 受信サーバーがメールの SPF と DKIM を検証する
- ヘッダー From のドメインと SPF / DKIM が検証したドメインのアライメントを確認する
_dmarc.ドメインの TXT レコードからポリシーを取得する- アライメントが取れていなければ、ポリシーに従ってメールを処理する
p=reject を設定したドメインでは、そのドメインを詐称したフィッシングメールは受信者の受信トレイに届きません。SPF がエンベロープ From の IP アドレスを検証し、DKIM が署名で改ざんを検出し、DMARC がこの両方をヘッダー From と照合します。3 層の認証が連携して、ドメイン詐称を防ぎます。
BIMI による視覚的な信頼性向上
DMARC ポリシーを p=quarantine 以上に強化した上で BIMI を設定すると、受信トレイにブランドロゴが表示されます。Gmail では VMC 認証済みのロゴの隣に青いチェックマークが付きます。受信者は「ロゴが出ていないメールは怪しい」と視覚的に判断できるため、フィッシングメールとの区別が容易になります。
確認方法
自社ドメインがフィッシングに悪用されるリスクを評価するには、DMARC レコードの設定状況を確認します。
dig TXT _dmarc.example.comp=none が返る場合、DMARC はモニタリングのみで、フィッシングメールの配信を阻止していません。p=quarantine または p=reject が返れば、認証失敗メールに対する防御が有効です。
SPF と DKIM も併せて確認します。
dig TXT example.comdig TXT default._domainkey.example.com外部の視点からも確認したい場合は、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.dmarc.exists が true で、data.dmarc.record に p=quarantine または p=reject が含まれていれば、ドメイン詐称型のフィッシングに対する基本的な防御が機能しています。data.spf.exists と data.dkim.exists も true であることを確認します。
よくある問題
DMARC ポリシーの未強化や類似ドメインの放置がフィッシング被害を拡大させます。
DMARC が p=none のまま放置されている
p=none は認証結果をレポートするだけで、フィッシングメールの配信を止めません。Google は 2025 年 11 月以降、大量送信者（1 日 5,000 通以上）に対して DMARC の設定を義務化しています。rua レポートで正規メールの認証状況を確認し、問題がなければ p=quarantine → p=reject へ段階的に移行します。
類似ドメインによるフィッシングを見落とす
DMARC は example.com のドメイン詐称を防ぎますが、examp1e.com や example-login.com のような類似ドメインには対応できません。自社ブランド名に似たドメインが登録されていないか定期的に監視し、発見した場合はドメインレジストラへの報告や UDRP（統一ドメイン名紛争処理方針）による対処を行います。
SPF / DKIM が未設定でアライメントが取れない
DMARC は SPF または DKIM のいずれかが pass し、かつアライメントが取れて初めて有効です。SPF レコードがない、または DKIM 署名を設定していない場合、DMARC の判定は常に fail になります。特にサードパーティのメール配信サービスを使う場合、サービス提供元の指示に従って DKIM のカスタムドメイン署名を設定する必要があります。
メールヘッダーの確認方法を知らない
受信したメールがフィッシングかどうかを判断するには、メールヘッダーの Authentication-Results を確認します。Gmail では「メッセージのソースを表示」、Outlook では「メッセージのプロパティ」からヘッダーを確認できます。dmarc=pass、spf=pass、dkim=pass が揃っていれば、少なくともドメイン詐称ではありません。
ユーザー教育が不足している
技術的対策は送信ドメインの詐称を防ぎますが、表示名のなりすましや URL の偽装には対応できません。「リンク先の URL をホバーして確認する」「緊急を装うメールほど慎重に対応する」「不審なメールの添付ファイルを開かない」といった基本的なリテラシー教育を定期的に実施します。APWG の 2025 年データでは、ソーシャルメディアと SaaS / Webmail が最も攻撃を受けたカテゴリで、それぞれ全体の 20.3% を占めています。攻撃対象は業種を問いません。
DMARC 以外の技術的対策
BIMI によるブランドロゴ表示、MTA-STS による通信経路の暗号化、DNS 監視による改ざん検知を組み合わせて多層防御を構築します。
BIMI の導入
DMARC ポリシーを p=quarantine 以上に設定し、VMC または CMC を取得して BIMI を導入すると、Gmail や Yahoo Mail の受信トレイにブランドロゴが表示されます。ロゴが表示されないメールに対する受信者の警戒感が高まり、フィッシングの成功率を下げる効果があります。
MTA-STS の設定
MTA-STS（Mail Transfer Agent Strict Transport Security）は、メールサーバー間の通信で TLS を強制する仕組みです。STARTTLS のダウングレード攻撃を防ぎ、メールの盗聴やメール経路上での改ざんを防止します。DMARC と組み合わせることで、送信ドメインの認証と通信経路の暗号化の両方を確保できます。
DNS 監視
自社ドメインの DNS レコードが不正に変更されていないか定期的に監視します。攻撃者が DNS を乗っ取ると、SPF / DKIM / DMARC の設定が無効化される可能性があります。CAA レコードで証明書の発行元を制限し、DNSSEC でレコードの改ざんを検出する構成が有効です。