フィッシング対策ガイドライン（2026年度版）

フィッシング対策ガイドライン2026年度版――なりすまし対策の技術を図解する

近年、フィッシングの手口は大きく変化し、「不自然な日本語で見分ける」「OTP（ワンタイムパスワード）があれば安全」といった従来の対策が通用しなくなっています。利用者の注意深さに頼る対策は、限界を迎えつつあります。

こうした状況を踏まえ、フィッシング対策協議会は2026年6月1日、「フィッシング対策ガイドライン」の2026年度版を公開しました。本稿では、同ガイドラインが事業者に求める対策のうち、特に技術的な要素に焦点を当てて解説します。送信ドメイン認証（SPF・DKIM・DMARC）を中心に、BIMI、S/MIME、DNSSEC、RPKI、そしてパスキー（FIDO2）まで、それぞれが「何を」「どのように」守る技術なのかを図とともに整理します。

なお、具体的な導入判断や設定内容については、最新のガイドライン本文および各仕様の一次情報をご確認ください。

目次

はじめに ― なぜ「気をつける」だけでは守れないのか

フィッシングの被害報告は増加を続けており、月によっては20万件を超える状況が報告されています。かつては、日本語の不自然さや稚拙な文面から偽メールを見分けることができました。しかし近年は生成AIの悪用により、自然で違和感のない文章が容易に量産されるようになっています。受信者ごとに文脈を反映したメッセージも作成されるため、「文面の不自然さで見抜く」という従来の啓発は通用しにくくなってきました。

さらに、OTPを利用していれば安全とされてきた前提も崩れています。攻撃者が利用者と正規サイトの中間に立ち、入力された認証情報をその場で正規サイトへ中継する「リアルタイムフィッシング」により、使い捨てであるはずのOTPが突破される事例が多発しました。2026年度版のガイドラインでも、単にOTPを利用するのみではフィッシング耐性を有するとはいえない、と明記されています。

その結果、対策の重心は「利用者が見抜く」ことから「そもそも攻撃を成立させない」技術的な仕組みへと移っています。まず、フィッシング攻撃がどのような段階を踏んで進むのか、そして技術的な対策がどの段階を断ち切るのかを整理しておきます。

攻撃は、偽サイトの準備から始まり、メールやSMSの送信、偽サイトへの誘導、認証情報の入力、そして窃取した情報の悪用という流れで進みます。送信ドメイン認証は②③の段階で「そもそもメールを届かせない」ことを狙う対策であり、耐フィッシング認証は④⑤の段階で「入力されても悪用させない」ための対策です。以降では、それぞれの技術を順に見ていきます。

フィッシング対策ガイドライン2026年度版の概要

ガイドラインの位置づけ

本ガイドラインは、フィッシング対策協議会の技術・制度検討ワーキンググループが作成し、年度ごとに内容を更新しているものです。Webサイト運営者・サービス事業者向けの「フィッシング対策ガイドライン」と、エンドユーザー向けの「利用者向けフィッシング詐欺対策ガイドライン」の2種類があり、本稿で扱うのは前者、すなわち事業者向けのガイドラインです。

事業者向けガイドラインは全7章からなり、第2章で優先度の高い「重要5項目」を示したうえで、第3章で要件、第4章で具体的な実施手順（フィッシング対策マニュアル）を解説しています。第5章は利用者側の対策、第6章は付録として、用語集やチェックリストを収めています。

事業者に求められる重要5項目

ガイドラインが挙げる重要5項目は、次のとおりです。いずれも事業者を主語とした対策であり、利用者に対して事業者が実施すべき事項として整理されています。

  • 利用者に送信するメールでは、送信者を確認できるような送信ドメイン認証技術等を利用すること

  • 利用者に送信するSMSにおいては、国内の携帯キャリアに直接接続される送信サービスを利用し、事前に発信者番号等をWebサイトなどで告知すること

  • フィッシング耐性を有する多要素認証を要求すること

  • ドメインは自己ブランドと認識して管理し、利用者に周知すること

  • フィッシングについて利用者に注意喚起すること

本稿では、このうち技術的な要素の比重が大きい重要項目1（送信ドメイン認証）と重要項目3（フィッシング耐性を有する多要素認証）を中心に、関連する周辺技術もあわせて解説します。

送信ドメイン認証 ― SPF・DKIM・DMARC

メールの「差出人」は2か所ある

送信ドメイン認証を理解するうえで最初に押さえておきたいのが、電子メールには差出人を示す情報が2か所存在するという点です。この二重構造が、なりすましが成立してしまう原因であり、同時にDMARCが必要とされる理由でもあります。

ひとつは「エンベロープFrom」（Return-Path）で、これはメールを配送するための情報です。封筒に書かれた差出人にあたるもので、通常は利用者の目に触れることはありません。もうひとつが「ヘッダFrom」で、こちらはメールソフトが「差出人」として画面に表示する情報です。利用者が見て判断するのは、このヘッダFromだけです。

ここで問題になるのが、SPFが検査するのはエンベロープFromであるという点です。つまり攻撃者は、自分が管理するドメインについてSPFを正しく設定しておいたうえで、ヘッダFromだけを実在する企業のものに詐称することができます。この場合、SPFの検査には合格しながら、利用者の画面には正規企業の名前が表示されることになります。SPFやDKIM単体では、この「ずれ」を防ぐことができません。

SPFの仕組み

SPF（Sender Policy Framework）は、送信元メールサーバのIPアドレスを認証する技術です。SPFもDKIMも、「送信側があらかじめ必要な情報をDNSサーバに登録しておき、受信側がそれを取得して照合する」という共通の構造を持っています。

送信側はDNSのTXTレコードに、自ドメインを名乗ってよいサーバのIPアドレスをSPFレコードとして登録しておきます（①）。受信側は、メールを受け取ると（②）、送信元ドメインのSPFレコードをDNSに問い合わせ（③）、取得した許可対象のIPアドレス（④）と、実際に接続してきたサーバのIPアドレスを突き合わせます（⑤）。SPFレコードで許可された範囲に含まれていれば、SPF認証は成功です。

なお、SPFレコードには個々のサーバのIPアドレス（ホストアドレス）を列挙することも、「203.0.113.0/24」のようにネットワークアドレスで範囲をまとめて指定することもできます。図の例では後者の書き方で、203.0.113.0〜203.0.113.255 の範囲を許可しています。

また、各項目の先頭には、その条件に合致したときの扱いを示す記号を付けられます。「+」は許可（pass）、「-」は拒否（fail）を表し、図の末尾にある「-all」は、ここに挙げたIPアドレス以外からの送信をすべて認証失敗として扱うという宣言です。なお「+」は省略時の既定値であるため、「+ip4:」と書いても意味は同じですが、実際には「ip4:」と省略して記載するのが一般的です。

DKIMの仕組み

DKIM（DomainKeys Identified Mail）は、電子署名によってメール本体を認証する技術です。構成要素と手順の流れはSPFと共通していますが、認証の材料が異なります。SPFが接続元のIPアドレスを照合するのに対し、DKIMはメールそのものに付与された電子署名を検証します。

送信側は秘密鍵でメールに電子署名を付与し、検証用の公開鍵をDNSサーバに登録します（①）。秘密鍵は外部に漏れないよう、送信側で適切に管理します。受信側は、署名に含まれる「d=」タグのドメインをもとに公開鍵をDNSへ問い合わせ（③④）、その公開鍵で署名を検証します（⑤）。検証できれば、メールが改ざんされておらず、署名したドメインが正しいことを確認できます。

両者は競合する技術ではなく、役割が異なります。SPFは「送ってきたサーバは正しいか」を検証します。一方DKIMは電子署名を用いるため、「署名したドメインが正しいか」に加えて「メールの内容が改ざんされていないか」まで検証できます。

なお、SPFには転送に弱いという性質があります。メールが転送されると、エンベロープFromが転送サーバのものに書き換わったり、接続元が転送サーバのIPアドレスになったりするためです。その結果、送信者がなりすましを行っていなくても、受信側では元の送信元を正規のものとして確認できなくなり、なりすましと同じ扱いを受けてしまうことがあります。技術そのものが動作しなくなるわけではなく、正規のメールが認証を通らなくなるという意味です。これに対しDKIMの署名はメール本体に付随して転送先まで届くため、転送されても認証が成立しやすいという違いがあります。

DMARCとアライメント

ここまで見てきたSPFとDKIMには、それぞれ弱点があります。SPFが検査するのはエンベロープFromであり、利用者が画面で目にするヘッダFromは検査の対象外です。DKIMも、署名したドメイン（d=）が正しいことは確認できますが、そのドメインがヘッダFromと一致しているかまでは見ていません。つまりどちらも、認証には成功しながら、利用者に見える差出人だけが詐称されている状態を見逃してしまいます。

DMARC（Domain-based Message Authentication, Reporting and Conformance）は、この弱点を補強する技術です。その中核となるのが「アライメント」と呼ばれる確認で、SPFやDKIMが認証したドメインと、利用者に見えるヘッダFromのドメインが一致しているかを検証します。

アライメントには2種類あります。SPFアライメントでは、ヘッダFromのドメインとReturn-Path（エンベロープFrom）のドメインが一致しているかを確認します。DKIMアライメントでは、ヘッダFromのドメインとDKIM署名の「d=」タグで指定されたドメインが一致しているかを確認します。

DMARCに合格するための条件は、「SPF認証とSPFアライメント」または「DKIM認証とDKIMアライメント」のいずれか一方を満たすことです。両方を満たす必要はありません。ただし、認証とアライメントは同じ系統で揃っている必要があり、SPF認証とDKIMアライメントを組み合わせて合格とすることはできません。

実務上は、SPFとDKIMの両方を設定しておくことが基本となります。前述のとおりSPFは転送に弱い一方、どちらか一方が成立すればDMARCには合格できるため、冗長性を確保する意味があるためです。

先ほどのなりすましの例に、DMARCを適用するとどうなるかを見てみます。

正規メールもなりすましメールも、いずれもSPFの検査自体には合格しています。差がつくのはアライメントです。なりすましメールはエンベロープFromが攻撃者のドメインであるため、利用者に見えるヘッダFromとドメインが一致せず、アライメントが成立しません。結果としてDMARCは不合格となり、送信側が宣言したポリシーに従って受信が拒否されます。

DMARCポリシーの段階運用

DMARCでは、認証に失敗したメールをどのように扱うかを送信側が宣言し、受信側がそれに従います。宣言できるポリシーは、何もしない「none」、迷惑メールボックスへ隔離する「quarantine」、受信を拒否する「reject」の3種類です。

ガイドラインは、なりすまし対策としてポリシーに「reject」を設定することが重要であるとしています。ただし、いきなりrejectを設定すると正規のメールまで拒否されるおそれがあるため、段階的な移行が推奨されます。まず受信に影響を与えないnoneで現状を把握し、DMARCレポートによって自社ドメインを使用している正規の送信元（メール配信代行やSaaSなど）を洗い出します。正規メールが正しく認証されて届いていることを確認したうえで、quarantine、rejectへと引き上げていきます。

注意すべきは、noneのまま運用を続けた場合です。この状態ではなりすましメールが受信者へ素通しで届き続けるため、被害の抑制にはつながりません。また、メールの送信に使用していないドメインについても、なりすましに悪用されることを防ぐためp=rejectを設定しておくことが重要です。

正規メールを「見せる」技術 ― BIMI・VMC・S/MIME

SPF・DKIM・DMARCが「不正なメールを弾く」ための技術であるのに対し、ここで扱うのは、受信箱まで届いた正規のメールを利用者に「正規のものだと示す」ための技術です。

BIMI（Brand Indicators for Message Identification）は、DMARCで認証されたメールについて、送信元のブランドロゴを受信箱に表示する仕組みです。利用者は、ロゴの有無によって正規のメールかどうかを視覚的に判断できるようになります。表示されるロゴの正当性は、VMC（認証マーク証明書）によって担保されます。前提として、DMARCがp=rejectまたはp=quarantineで有効になっている必要があり、DMARCに対応していない場合はロゴが表示されません。

あわせて検討したいのがS/MIMEです。DKIMがドメイン単位の署名であるのに対し、S/MIMEは電子証明書を用いてメールアドレス単位で電子署名を行い、差出人そのものの真正性を証明します。スマートフォン標準のメールアプリでも確認できるため、正規メールの裏付けとして有効です。ただしガイドラインは、送信に使用するすべてのメールアドレスで署名を行う必要があると指摘しています。アドレスによって署名を付けたり付けなかったりすると、利用者が「署名がない場合もある」と認識してしまい、効果が半減してしまうためです。

通信経路を守る技術 ― DNSSEC・RPKI

ここまではメールに関する対策、すなわちアプリケーション層の話でした。しかし、利用者が正しいURLを入力したにもかかわらず偽サイトに接続されてしまうのであれば、これらの対策は意味をなさなくなります。ガイドラインは、この点にも言及しています。

DNSSEC（DNS Security Extensions）は、名前解決、すなわちドメイン名からIPアドレスへの変換の正しさを守る技術です。DNSの応答に電子署名を付与し、上位から順に信頼の連鎖をたどって検証することで、改ざんされた応答を拒否します。これにより、DNSキャッシュポイズニングを防ぎます。

RPKI（Resource PKI）は、経路制御の正しさを守る技術です。特定のIPアドレス帯を広告してよいAS（自律システム）を電子証明書によって登録（ROA）しておき、不正な経路広告を無効と判定します。これにより、BGPハイジャックを防ぎます。

いずれも通信の完全性・真正性を守る技術であり、通信内容を暗号化して秘匿するものではない点に注意が必要です。ガイドラインは、オンラインサービスの提供者に対して、利用者が正しいURLを使ったときに正規サイトへ接続される状態を保つ必要があるとしています。そのうえで、DNSSECやRPKIといったセキュリティ技術を採用している通信事業者やクラウドサービス事業者を利用することを求めています。

認証を破られないために ― パスキー（FIDO2）

なぜOTPでは不十分なのか

重要項目3では、フィッシング耐性を有する多要素認証を要求することが求められています。その背景にあるのが、冒頭でも触れたリアルタイムフィッシングです。

この攻撃では、攻撃者が用意した偽サイトが利用者と正規サイトの中間に立ちます。利用者が偽サイトに入力したID、パスワード、そしてOTPは、その場で正規サイトへ転送され、攻撃者によるログインが成立してしまいます。OTPは使い捨てであっても、リアルタイムに中継されてしまえば防御にはなりません。SMSによる認証コードについても同様です。

パスキーの耐フィッシング原理

この問題に対してガイドラインが挙げている対策が、パスキーです。パスキーはFIDO2をベースに利便性を高めた認証規格で、生体認証と、認証器（鍵を保管する端末。スマートフォンやパソコン、FIDOセキュリティキーなど）を持っていることの二要素を組み合わせ、パスワードレス認証を実現します。

パスキーがフィッシングに強い理由は、その仕組みにあります。パスキーは公開鍵暗号方式を採用しており、秘密鍵は認証器の中から外に出ることがありません。サーバが預かるのは公開鍵だけであるため、仮にサーバ側から情報が漏えいしても、それを使って認証を突破することはできません。認証の際は、サーバから送られたチャレンジ（乱数）に対して認証器が秘密鍵で署名を行い、サーバが公開鍵で検証します。パスワードのような「盗める秘密」がやり取りされないのです。

フィッシング対策として重要なのは、この鍵がドメイン名と結びついている点です。パスキーは、鍵を登録したときのドメイン名を認証器の中に一緒に記録しています。そして認証を求められると、認証器は「いま接続している相手はどのドメインか」を確認し、登録時のドメインと一致した場合にだけ署名を返します。ドメインが違えば、そもそも署名を返しません。

そのため、利用者が偽サイトにアクセスしてしまったとしても、認証器は偽サイトのドメインを見て「登録済みのドメインとは違う」と判断し、何も返しません。攻撃者の手元には中継すべき情報が残らないため、OTPのときのような転送が成立しないのです。ガイドラインでも、パスキーは秘密情報をドメイン名と紐づけて認証器内に保存するため、フィッシングサイトに対して正規ドメインと紐づいた秘密情報を送信することはない、と説明されています。

導入にあたっての留意点

パスキーの導入は、認証の入口を固める対策です。しかしガイドラインは、入口以外の経路にも注意を促しています。まず、パスキーの初期登録時には、攻撃者によるなりすまし登録を防ぐため、本人確認を厳格に行うことが望ましいとされています。

また、攻撃者はログインに成功した後、永続的なアクセスを維持するために多要素認証を無効化したり、OTPの送信先を自身のアドレスへ変更したりすることがあります。そのため、利用者情報や多要素認証の設定を変更する際にも、同様にフィッシング耐性を有する多要素認証で本人確認を行う必要があります。

さらに、端末の紛失や盗難に備えた代替手段（フォールバック）やアカウント回復の手続についても、フィッシング耐性を有する認証方式を用いることが適切であるとされています。認証経路の中に一つでも弱い部分が残っていれば、攻撃者はそこを狙うためです。

一方で、ガイドラインはこうした対策が利用者に与える影響にも配慮を求めています。利用者のITリテラシーやデバイス環境の差異により、利便性の観点で著しい格差を生じさせる可能性があるため、設計時には十分な配慮が望まれるとされています。

企業での対応

ここまで見てきた技術を踏まえ、事業者として確認すべき事項を整理します。

まず、自社が管理するドメインについて、SPF・DKIM・DMARCが設定されているかを確認します。設定済みの場合は、DMARCのポリシーが現在どの段階にあるかを把握します。noneのままであれば、DMARCレポートを確認して正規の送信元を洗い出し、quarantine、rejectへと段階的に引き上げる計画を立てることになります。あわせて、メールの送信に使用していないドメインについてもp=rejectが設定されているかを確認します。

ドメインの管理体制も重要です。ガイドラインはドメイン名を自己ブランドとして認識し、一元管理することを求めています。廃止したドメインが第三者に取得されて悪用されるドロップキャッチへの対策や、CDNサービスの利用終了時におけるCNAMEレコードの削除漏れ（サブドメインテイクオーバー）にも注意が必要です。

認証方式については、自社が提供するサービスでどのような多要素認証を採用しているかを確認します。OTPのみに依存している場合は、リアルタイムフィッシングへの耐性がないことを前提に、パスキーをはじめとする耐フィッシング認証の導入を検討することになります。その際は、初期登録、設定変更、アカウント回復といった周辺の経路まで含めて設計することが求められます。

おわりに

フィッシング対策ガイドライン2026年度版が示しているのは、対策の重心が「利用者が見抜く」ことから「技術的に成立させない」ことへ移行しているという方向性です。生成AIによって文面の巧妙化が進み、リアルタイムフィッシングによってOTPが突破される以上、利用者の注意深さに依存した対策には限界があります。

本稿で取り上げた技術は、それぞれ守る対象と層が異なります。SPF・DKIM・DMARCはなりすましメールを届かせないための対策であり、BIMIやS/MIMEは届いた正規メールを正規のものとして示すための対策です。DNSSECやRPKIは通信経路そのものの正しさを守り、パスキーは認証情報が窃取される前提でもログインを成立させないための対策です。いずれか一つで完結するものではなく、多層的に組み合わせることが重要になります。

まずは自社のDMARCポリシーの状態と、提供しているサービスの認証方式を確認することが出発点となります。そのうえで、ガイドラインが示す重要5項目に照らして、現状の対策状況を点検してみてはいかがでしょうか。

参考

お問い合わせ