今から約30年前、Windows 95の登場とともに、メールは画期的な連絡手段として一気に普及しました。メールサーバーを設定し、IDとパスワードだけで使える――当時としては手軽で、十分に安全だと信じられていた仕組みです。ところがこの30年で、攻撃の速度と規模、そして手口は桁違いに進化しました。
最近、ボクの身近で某通販大手のIDとメールサーバの1アカウントが同時期に侵害された。互いに無関係でも、その背後では“認証突破の波”が進んでいる可能性を捨てきれない。
この記事では、①SMTP認証の限界、②世界標準（OAuth2／Passkey／DMARC／ゼロトラスト）、③今日からできる実務対策を、要点だけに絞ってまとめる。
身近に起きた2件の侵害から見えたこと
- ケースA：某通販大手のID … 不正ログインの痕跡。推測要因：短い・使い回しパスワード、リスト型攻撃の波。
- ケースB：メールサーバの1アカウント … 送信スパムの踏み台化／不正転送ルールの仕込み懸念。
- 共通項 … ネットワーク上の接点はないが、同時期（2025年8月） に可視化。= 背景で大規模に「ID/PWの再利用」が回っている可能性。
観測ポイント：どちらも 8桁前後のシンプルPW。2025年の攻撃環境では、これは“ほぼ防壁にならない”。
SMTP認証（SMTP AUTH）とは何か
- SMTP は「メールを送る」プロトコル。昔は認証なしでも送れた（=オープンリレー問題）。
- 2000年代、SMTP AUTH が普及：ID＋パスワード を提示できたら送信を許可。
- TLS暗号化（587+STARTTLS／465+SSL）が一般化しても、認証の本体はID+PW のまま。
図1：SMTP AUTHの流れ（概念）
[メールクライアント] --(ID+PW をTLSで送信)--> [SMTPサーバ] -- 送信
問題は「ID+PWが破られたら終わり」という構造的弱点。暗号化の有無とは別の次元の話。
2025年に見えてきた限界
(1) 総当たり・辞書攻撃が高速化
8〜10桁の人間的パターン（語＋数字など）は、GPUクラスタやAI補助で短時間に破られ得る。
(2) リスト型攻撃（Credential Stuffing）
別のサービスで漏れたID/PWを、機械的に他サービスへ横展開。使い回しは即アウト。
(3) メール乗っ取りの“価値”が上昇
- パスワードリセット受信＝他サービスの鍵
- 乗っ取ったメール経由で BEC（ビジネスメール詐欺） / 送金詐欺
- サーバを スパムの踏み台 に利用 → IPがBL入り→正規メールも届かなくなる
(4) 運用の“思い込み”
- 「社内だから安全」「設定したら終わり」= 2025年は通用しない。
世界標準はこう変わっている
(A) OAuth 2.0（トークン認証）
Google/Microsoftなどは ID+PWでのSMTP/IMAPを段階的に終了。アプリは認可フローでトークンを取得・更新。
(B) Passkey / FIDO2（パスワードレス）
端末内秘密鍵＋生体認証でログイン。「覚えるパスワード」からの脱却 が主流に。
(C) DMARC / DKIM / SPF（送信ドメイン認証のセット）
「なりすまし」を技術的に難しくし、受信側の拒否 を明確化。各国で導入・強制が進む。
(D) ゼロトラスト
ネットワークの内外を問わず、端末・場所・時間・振る舞い でリスク判定し、怪しければ遮断。
まとめ：旧来の「SMTP AUTHだけ」ではもはや不十分。認証＝多層化（人間＋端末＋ドメイン＋振る舞い） へ。
いますぐ実行する実務チェックリスト
5-1. 個人編
- PWの総入れ替え：12〜16文字以上、各サービスで別のもの。覚えずに パスワードマネージャ で運用。
- MFA（多要素認証）：認証アプリ or ハードキー を推奨（SMSは代替案）。
- メール設定の点検：不審な 自動転送／署名改変／フィルタ がないか。
- 連携アプリの棚卸し：OAuth連携で見覚えのないものは削除。
- 漏洩チェック：アドレスを漏洩検知サービスで確認。ヒットしたら関連PWを総入れ替え。
- クレカ・銀行の通知ON：不正利用の早期発見に直結。
5-2. 管理者編（メールサーバ／組織）
- 暗号化の強制：587+STARTTLS or 465+SSL。平文禁止。
- Modern Auth優先：可能な範囲で OAuth2／ID+PW廃止に移行。
- レート制限：SMTP AUTHの試行回数／送信数上限。
- ログ監視と自動ブロック：国・IPレンジ・深夜大量送信の異常検知。
- 送信ドメイン認証：SPF/DKIM/DMARC をセットで導入し、DMARCレポートを運用。
- 転送ルール巡回：全メールボックスの自動転送を定期巡回。
- 資格情報の棚卸し：共有ID、APIキー、OAuth同意の整理・撤去。
- バックアップ：設定・メールデータの定期バックアップ（オフライン含む）。
よくある質問（FAQ）
Q1. Thunderbirdで急に受信できなくなった
A. サーバ側が 古い認証方式を無効化 した可能性。アカウント設定で OAuth2 を選べるか確認。SSL/TLSの設定も最新に。二段階認証の有効化が求められる場合あり。
Q2. パスワードは何文字が安全？
A. 最低 12〜16文字以上。人力で覚えるのは非現実的なので、マネージャ運用 が前提。辞書語＋数字の組み合わせはNG。
Q3. SMS認証でも大丈夫？
A. 可能なら 認証アプリ（TOTP）や ハードウェアキー を推奨。SMSは盗聴・SIMスワップのリスクが残るため“次善”。
Q4. メールが届かない／相手に届かない
A. 送信側のIPがブラックリスト入りしている、DMARCで拒否されている、受信側の迷惑判定など。送信ドメイン認証の正規実装 と 送信IPの健全性 を確認。
まとめ／提言
- SMTP AUTHは後方互換のために残っているだけ。セキュリティをそれに依存し続けるのは危険。
- 2025年の標準は、Passkey（FIDO2）＋OAuth2＋DMARCセット＋ゼロトラスト。段階的にここへ移行する設計が必要。
- 個人も組織も「設定して終わり」ではなく、常に進化させる運用 に切り替えよう。
