なりすましメール対策：仕組みと防ぎ方を解説

状況で変わるなりすまし対策

適切な対応は、手元にある証拠と、どのドメインが関わるかで変わります。

受信したメールなら、実際の送信者アドレスと、配信されたメールの認証結果を確認します。送信者が正規の外部サービスを使っている場合もあり、公開DNSレコードからは個々のメールに何が起きたかは分かりません。送金、認証情報、振込先の変更、予期しない添付ファイルを求めるメールなら、対応する前に、別に把握している連絡手段で依頼を確認します。

ヘッダーごとの確認手順と、偽装を最初に見抜ける目に見える兆候は、なりすましメールの見分け方で解説しています。

自社で運用するドメインなら、認証レコードを公開・維持し、実際のトラフィックで検証します。正規の送信サービスがアライメントの取れたSPFまたはDKIMで成功していなければ、DMARCの保護は不完全です。またp=rejectポリシーは、すべての受信側が同じように適用しなければならない指示ではありません。RFC 9989では、受信側がDMARCの結果を扱う際に独自のポリシーを適用することを認めています。

次の基準で判断します。

• 不審なメールを受信した場合は、そのメールを保存し、完全なヘッダーまたはメールのソースを確認します。返信、添付ファイルの開封、リンクのクリックの前に、表示アドレス、返信先アドレス、認証結果を確認します。
• ドメイン名が分かっていて、公開されている認証の状態を調べたい場合は、公開DMARCレコードを照会します。
• ドメインの管理者なら、なりすまし対策が機能していると判断する前に4つの層を検証します。権威DNSと公開DNS、送信ベンダーのステータス、本番経路から実際に配信されたメール、蓄積されたDMARC集計レポートです。
• 送信者が紛らわしい別のドメインを使っている場合、自社ドメインのDMARCではその類似ドメインを認証できません。メールプロバイダーの手順でそのメールを報告・ブロックし、なりすましドメインは別途調査します。

重要な本番の送信元を特定してテストするまでは、ドメインをp=quarantineやp=rejectに移行しないでください。ポリシーを変更すると、まだDMARCアライメントに失敗する正規のメールにも影響が出ることがあります。

認証結果の読み方の例

配信されたメールには、受信側による認証の評価を記録したAuthentication-Resultsヘッダーが含まれることがあります。RFC 8601はAuthentication-Resultsヘッダーフィールドを定義しています。以下は説明用の例で、実際のメールから取ったものではありません。

Authentication-Results: receiver.example;
  spf=pass smtp.mailfrom=mailer.yourdomain.com;
  dkim=pass header.d=yourdomain.com;
  dmarc=pass header.from=yourdomain.com

この例は、mailer.yourdomain.comでSPFが成功し、yourdomain.comを使う署名でDKIMが成功し、表示上のFromドメインyourdomain.comでDMARCが成功したことを示します。

dmarc=passのような結果は、その受信側でのそのメールについての有効な証拠です。ただし、今後のメールがすべて成功することも、そのドメインを使う送信者がすべて許可されていることも、そのメールが受信トレイに入るべきことも証明しません。受信者と送信者の既知の関係や依頼の内容も含め、メール全体の文脈を確認してください。

次にすべきこと

不審なメールを受信したら、メールソフトの報告機能を使い、既知の電話番号、社内名簿、以前に確認済みのアドレスで、送信者とされる相手に連絡します。確認に、不審なメールに書かれた返信先を使ってはいけません。ドメインの偽装を伴うとは限らないなりすましについては、メールのなりすまし（インパーソネーション）と防ぎ方をご覧ください。

表示上のFromドメインを管理しているなら、そのドメインでメールを送るサービスをすべて洗い出します。サービスごとに、ベンダー側の現在の認証ステータスを確認し、本番とまったく同じ経路でテストメールを送り、配信されたヘッダーを確認します。そのうえでDMARC集計レポートを使い、送信元と、認証やアライメントの失敗を継続的に把握します。受信メールはメールフィルタリングで防御を重ねられますが、ドメイン認証の代わりにはなりません。メールフィルタリングでスパムを防ぐ仕組みもご覧ください。

「このドメインは今どんなDMARCポリシーを公開しているか？」を知りたいときは、公開レコードのチェックを使います。個々の不審なメールの送信元を証明するためのツールではありません。

なりすまし対策でよくある問題

自社の正規メールがDMARCに失敗するのはなぜ？

ほとんどの場合、アライメントか送信元の登録漏れが原因です。SPFやDKIMに成功していても、認証に使うドメインがFromアドレスのドメインと異なれば、アライメントに失敗します。あるいは、CRMや給与計算ツールなど忘れていた送信元が、SPFに追加されておらず、DKIMの鍵も設定されていないケースです。p=rejectに移行する前に、ドメインの集計レポートを読んで送信元を特定し、認証するか、許可された経路を通すようにします。

SPFがpermerrorを返し続けるのはなぜ？

レコードが10回のDNSルックアップ上限を超えているか、ドメインにSPFレコードが複数あるためです。include、a、mxの各メカニズムは、それぞれルックアップを消費します。プロバイダーを集約する、使っていないincludeを削除する、SPFフラット化を使うなどして対処し、v=spf1レコードが1つだけ存在するようにします。詳しくはSPF permerror（DNSルックアップ過多）の直し方をご覧ください。

自社ではなく類似ドメインが悪用されている場合、DMARCは有効？

DMARCが保護するのは、公開されているそのドメインだけです。yourdomaìn.comやyourdomain-support.comのような類似ドメインは別のドメインで、独自の対策が必要です。分かりやすい類似ドメインを取得し、新規登録を監視し、ポリシー強化と従業員教育を組み合わせます。DMARCが止めるのは、そのドメインそのもののなりすましです。所有していない名前までは取り締まれません。全体像は類似ドメインがDMARCをすり抜ける仕組みをご覧ください。

p=rejectにしたら転送メールがバウンスするのはなぜ？

転送では転送サーバーが送信者になるためSPFが壊れ、転送サーバーがメールを書き換えるとDKIMも壊れることがあります。DKIMが転送後も無傷なら、DMARCはそれによって成功します。DKIMが重要なのはこのためです。バウンスしたメールのヘッダーでどの確認が失敗したかを調べ、転送経路で正しく署名または再署名されているかを確かめます。

なりすましが疑われるドメインのDMARCレコードを確認

表示上のFromアドレスにあるドメインをPalisadeのチェックツールにかけると、現在公開されているDMARCレコードとポリシータグを確認できます。その結果を配信されたメールの認証結果と比べ、許可のないなりすましか、別のなりすまし（インパーソネーション）の試みかを判断します。

DMARCレコードをチェック

公開DNSのチェックでは、一通のメールの送信者の証明、認証されていない送信元の修正、受信側の非公開のフィルタリング判断の表示、ドメインの送信元のその後の変化の監視はできません。

IT部門やMSPが複数ドメインのレポートを処理する必要があるなら、Palisadeはエージェント型DMARCソフトウェアです。DMARC集計レポートのデータを分析し、送信元と、認証やアライメントの問題を特定して、優先度付きの修正チケットを作成します。証拠に基づいて次のポリシー段階を提案できますが、証拠を確認して変更を反映するのは人です。

Palisadeを始める

PalisadeがDMARCポリシーを独断で変更することはありません。今後のすべてのメールが認証されることや、受信側の最終的なメールボックス判断を左右することもありません。

メール以外のなりすまし（IPや発信者番号の偽装を含む）については、スプーフィングとは？なりすまし攻撃の解説をご覧ください。