標準の警告が見ているのは、3つの条件だけ
Thunderbird には「これは詐欺メールの可能性があります」という警告バーが標準で備わっています。便利ですが、判定条件は3つしかありません。
| 条件 | 意味 |
|---|---|
| 表示とリンク先の食い違い | 本文に書かれたURLと、実際にアクセスするURLが違う |
| IPアドレスのリンク | リンク先がドメイン名ではなくIPアドレスになっている |
| HTMLフォーム | メール本文に入力フォームが埋め込まれている |
この3条件は、フィッシング対策協議会が Thunderbird 開発者に行ったインタビューで説明されているものです。原典は NEWS LETTER No.8：Thunderbird のフィッシング詐欺メール警告機能をご覧ください。同記事でも、これらに当てはまったからといって必ず詐欺とは限らない、と注意が添えられています。
お気づきのとおり、この3つはいずれも「本文の書き方」の話です。差出人が本物かどうかは、まったく見ていません。つまり、リンクを1本も貼らず、文面も自然な「Amazonを名乗る請求メール」は、標準機能では素通りします。
差出人の真偽を確かめるには、SPF・DKIM・DMARC といった送信ドメイン認証の結果を見る必要があります。そこはアドオンの領分です。
2つのアドオンで、役割が違います
目的が重なっていないので、両方入れても構いません。どちらも無料で、処理はすべて手元のPCで完結します（メールの内容が外部に送られることはありません）。
| アドオン | 強み | 向いている人 |
|---|---|---|
| DKIM Verifier | DKIM署名を自分で検証する（RFC 6376）。DNSから公開鍵を取得して照合する | 受信サーバーの判定を鵜呑みにせず、自分で確かめたい |
| Mail Auth Info Viewer | SPF・DKIM・DMARC・ARC、送信者の整合、配送経路、本文リンクを1画面にまとめて表示する | 1通のメールについて、全体像をまとめて把握したい |
DKIM Verifier
この違いは地味ですが重要です。多くのツールは、受信サーバーが付けた Authentication-Results ヘッダを読んでいるだけです。つまり「受信サーバーがそう言っている」という伝聞を表示しています。
DKIM Verifier は署名そのものを検証し、公開鍵をDNSから自分で引きます。伝聞ではなくその場での検証結果なので、経路の途中で結果を書き換えられる余地がありません。
配布元：Add-ons for Thunderbird（DKIM Verifier） ／ ソースコード：GitHub
Mail Auth Info Viewer
認証結果に加えて、表示名だけを似せたなりすましの検出、配送経路の各区間が暗号化されていたか、本文リンクの危険度（IPアドレス直打ち、見た目を似せた国際化ドメイン、トラッキングピクセルなど）まで1画面に出ます。信頼するドメインを登録して警告を抑える機能もあります。
GPL v3 のオープンソースで、日本語を含む12言語に対応しています。
配布元：Add-ons for Thunderbird（Mail Auth Info Viewer） ／ ソースコード：GitHub
いずれも当社が開発・提供しているものではありません。導入は各配布元の説明をご確認のうえ、ご判断ください。
結果の読み方を間違えないこと
アドオンを入れても、表示される語の意味を取り違えると意味がありません。ここがいちばん誤解の多いところです。
| 表示 | 意味 | どう扱うか |
|---|---|---|
pass | 認証に成功した | 名乗ったドメインの持ち主が送った、という積極的な証拠 |
fail | 認証に失敗した | 偽物であることの積極的な証拠。いちばん重い |
softfail | 失敗だが、送信側が「弾くほどではない」としている | 疑わしい。他の材料と合わせて判断する |
none | そもそも設定がない | 失敗ではない。確かめられなかっただけ |
neutral | 送信側が判断を表明していない | 同上。確かめられなかっただけ |
permerror | 設定を解釈できなかった | 失敗ではない。送信側の設定不備の可能性 |
temperror | 一時的な障害で検証できなかった | 時間をおけば結果が変わりうる |
実務でいちばん危ないのは、none や permerror を「失敗」と読んでしまうことです。これらは「偽物だと分かった」ではなく「確かめられなかった」です。本物のメールでも普通に出ます。
当社の判定ツールでも、この取り違えを実際にやりました。spf=permerror だけを根拠に、本物のメールを「危険」と判定してしまったのです。原因は、送信元の設定が古い記法のままで解釈できなかっただけでした。いまは「確かめられなかったこと」として別枠で表示するように直してあります。
もうひとつ、DKIM が pass でも安心はできません。DKIM は「署名したドメイン」を保証しますが、それが差出人として表示されているドメインと同じとは限らないからです。この一致をアライメントと呼びます。攻撃者が自分のドメインで正しく署名すれば、DKIM 自体は堂々と pass します。DMARC はこのアライメントまで見るので、見るべきは DMARC の結果です。
認証が通っても「安全」ではありません
ここを誤解すると、かえって危険になります。送信ドメイン認証が言っているのは、「名乗ったドメインの持ち主が送った」という1点だけです。
- 攻撃者が自分のドメインを正しく設定していれば、すべて
passします。認証は「詐欺かどうか」を判定していません - 乗っ取られた正規アカウントからの送信も
passします。本物のサーバーから本当に送られているためです - 表示名だけを似せる手口には、認証は無力です。差出人名を「株式会社○○ 経理部」にして、ドメインは攻撃者自身のもの、という形です
認証は「偽物を弾く」ための仕組みであって、「本物を保証する」ものではありません。緑色の表示が出ても、お金や認証情報に関わる依頼は、メールの返信ではなく相手の公式な連絡先へ別の手段で確認する——この原則は変わりません。
Thunderbird 以外をお使いの場合
ここまでの話は Thunderbird に限ったものです。Outlook や Gmail、携帯キャリアのメールでは、同じことをするアドオンがありません。
メーラーを問わず、受信したメールのソース（ヘッダ＋本文）を貼り付けて、配送経路・SPF/DKIM/DMARC の結果・差出人と実際の送信元の食い違い・本文中のリンクを確認できます。登録不要・無料で、貼り付けた内容は保存しません。
迷惑メール・なりすまし判定ツール →なお Thunderbird をお使いなら、上で紹介したアドオンのほうが便利です。メールを開いたまま結果が見られますし、内容が手元から出ません。当社のツールは、アドオンが使えない環境向けとお考えください。
自社が「かたられる側」になることもあります
ここまでは受け取る側の話でしたが、自社のドメインが偽メールに使われる可能性もあります。フィッシング対策協議会の集計では、調査用アドレスに届いたフィッシングメールの約32%が実在するドメイン名を差出人に使っていました（フィッシングの最新傾向）。
この場合、被害を受けるのは取引先や顧客です。自社のシステムは何も侵害されていないのに信用を失います。しかも偽メールは自社のサーバーを通らないので、自社側では気づけません。
対策は、いま読み方を説明した SPF・DKIM・DMARC を自社ドメイン側で設定することです。特に DMARC のポリシーが p=none のままだと、認証に失敗したメールもそのまま配送されます。設定した気になって1通も止まっていない、という状態が少なくありません。