Email Security 06-11-2026

ゼロトラストメールを実現する DMARC、PKI、TLS の連携

ゼロトラストは、ネットワークセキュリティのバズワードから、あらゆるデジタルインタラクションを保護するための戦略的なモデルへと進化しました。その基本原則は、どの実装においても一貫しています。すなわち、「決して信頼せず、常に検証する（Never trust, always verify）」という考え方です。

組織はこのフレームワークをユーザーアクセス、デバイス認証、および Web トラフィックの保護に取り入れてきました。Web サイトの ID を検証するために証明書を発行し、TLS によって接続を暗号化しています。また、機密システムへのアクセスを許可する前に、多要素認証（MFA）を要求しています。

しかし、トラストチェーンの中で見落とされがちな要素が一つあります。

メールです。メールはサイバー攻撃で最も一般的な侵入経路であるにもかかわらず、多くの場合ゼロトラストモデルの外で運用されています。メッセージは信頼できる送信元を名乗って届き、多くの組織はそれをそのまま受け入れています。検証も認証もありません。テキストフィールドに記載された情報を暗黙的に信頼しているだけです。

それはゼロトラストではなく、その正反対です。

以下では、DMARC、PKI、TLS がどのように連携し、Web とメールの両チャネルをカバーする多層的なゼロトラストアーキテクチャを構築するのかを見ていきます。

プロトコルは異なっても、原則は同じです。通信を信頼する前に ID を検証することです。

ゼロトラストとは何か

ゼロトラストは購入できる製品ではありません。単一の技術でもなく、コンプライアンスチェックリストの項目でもありません。その中心にある考え方は一つです。暗黙的な信頼を排除することです。

従来のセキュリティモデルでは、ネットワーク境界の内側にあるものは安全であると想定していました。企業ネットワーク内にいれば信頼され、内部 IP アドレスからのリクエストは正当である可能性が高いと考えられていました。

しかし、そのモデルはもはや成り立ちません。

攻撃者は境界を突破します。認証情報は盗まれます。内部関係者による不正も発生します。リモートワークの普及によって、「ネットワークの内側」と「外側」の境界は事実上消滅しました。

ゼロトラストはこの前提を覆します。すべてのリクエストは、正当性が証明されるまで潜在的な脅威として扱われます。すべてのユーザー、デバイス、接続は、その発信元に関係なく認証および認可されなければなりません。

このフレームワークは、いくつかの重要な原則に基づいています。

明示的に検証する：利用可能なすべてのデータポイントに基づいて常に認証する。
最小権限アクセスを適用する：必要最小限の権限のみを付与する。
侵害を前提とする：攻撃者がすでに内部に存在すると想定してシステムを設計する。

これらの原則は、ユーザーアクセス、デバイス管理、アプリケーションセキュリティ、ネットワーク分離など、あらゆる領域に適用されます。

そして本来はメールにも適用されるべきです。しかし実際には、そうなっていないケースが少なくありません。

PKI と TLS が Web トラフィックを保護する仕組み

公開鍵基盤（PKI）は、デジタル証明書を発行、管理、検証する仕組みです。ユーザーが Web サイトへアクセスすると、サーバーは信頼された認証局（CA）によって発行された証明書を提示します。ブラウザはその証明書を確認し、その Web サイトが主張する組織によって運営されていることを検証します。

これは大規模な ID 検証です。何十億もの証明書が発行・検証され続け、接続先の Web サイトが本当にその組織であることを確認しています。

ID が検証されると、TLS（Transport Layer Security）がブラウザとサーバー間の通信を暗号化します。この接続上で送信されるデータは、第三者による盗聴や改ざんから保護されます。

PKI と TLS は、次の 2 つを保証します。

ID：サーバーが主張する正当な相手であること。
完全性：通信内容が改ざんされていないこと。

これは Web トラフィックに適用されたゼロトラストです。証明書が検証されるまでは、どの接続も信頼されません。暗号化が確立されるまでは、どのデータも送信されません。ユーザーアクセスやデバイス認証を支える原則が、すべての HTTPS 接続にも適用されています。

この仕組みは機能しています。証明書が無効な場合、ブラウザは警告を表示します。TLS を利用していないサイトは検索エンジンで不利になります。ユーザーも南京錠アイコンを確認する習慣を身につけています。インフラは整備され、多くの組織が活用しています。

では、メールと比較してみましょう。

ゼロトラストメールにおけるギャップ

メールは現代の Web よりも前から存在しています。メールを支えるプロトコルは、インターネットが小規模で学術的な利用が中心であり、基本的に信頼できる環境だった時代に設計されました。当時は悪意ある攻撃者が大きな問題ではなかったため、認証は優先事項ではありませんでした。

しかし、その前提は現在では通用しません。

今やメールは、フィッシング、ビジネスメール詐欺（BEC）、なりすまし攻撃の主要な侵入口となっています。そして根本的な問題は非常にシンプルです。「From」フィールドは単なるテキストであるということです。誰でも他人を装ったメールを送信できます。そのドメインを利用する権限が送信者にあるかどうかを検証する仕組みは標準では存在しません。

これは Web トラフィックとは大きく異なります。

Web サイトへアクセスすると、ブラウザは自動的に証明書を確認します。ID を検証できない場合は警告が表示され、場合によっては接続自体がブロックされます。利用者は何もする必要がありません。検証は毎回、自動的かつ透過的に行われています。

一方でメールを受信した場合、同等の確認は標準では行われません。メッセージはそのまま届き、名前とメールアドレスが表示されます。そして利用者は、その見た目をもとに信頼するかどうかを判断します。

これはゼロトラストではありません。暗黙的な信頼です。

組織は他の防御策でこれを補おうとしてきました。セキュアメールゲートウェイ（SEG）は悪意あるリンクや添付ファイルを分析します。スパムフィルターは不審なパターンを検知します。従業員教育では危険な兆候を見抜く方法を教えています。

これらの対策は役立ちますが、根本的な問題を解決するものではありません。送信元の ID を検証するのではなく、振る舞いから攻撃者を検出しようとしているだけだからです。

ゼロトラストが求めるのは検証です。メールにおいては、メッセージを信頼する前に送信者を認証することを意味します。

DMARC が送信者 ID を検証する仕組み

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、ゼロトラストの原則をメールへ適用します。ドメインレベルで送信者 ID を検証し、そのメッセージが本当に許可された送信元から送信されたことを確認します。

DMARC は次の 2 つの基盤技術の上に成り立っています。

SPF（Sender Policy Framework）：ドメインを代表してメールを送信できるサーバーを定義します。ドメイン所有者は、許可された IP アドレスの一覧を DNS に公開します。メール受信時に、受信サーバーは送信元 IP がその一覧に含まれているかを確認します。
DKIM（DomainKeys Identified Mail）：送信メールに暗号学的署名を付与します。送信サーバーは秘密鍵でメールへ署名し、受信サーバーは DNS 上の公開鍵を取得して署名の正当性とメッセージの改ざん有無を検証します。

DMARC は、少なくともどちらか一方が成功しているか、そしてその結果が表示される「From」ドメインと一致しているかを確認します。認証に失敗した場合、DMARC は受信サーバーへ次の動作を指示します。

p=none：メールは配信するが、ドメイン所有者へレポートを送信する。
p=quarantine：メールを迷惑メールフォルダへ隔離する。
p=reject：メールを完全に拒否する。

これは PKI と TLS の関係によく似ています。

DMARC は、メール認証を実効性のあるものにするための強制適用メカニズムです。DMARC がなければ、SPF や DKIM は情報を提供するだけで何も強制できません。DMARC を適用モードで運用することで、許可されていない送信者は入口でブロックされます。

これこそがメールにおけるゼロトラストです。送信者を検証し、ポリシーを適用し、認証に失敗したメッセージを信頼しないことです。

チャネル全体にセキュリティを重ねる方法

ゼロトラストは単一のレイヤーではありません。あらゆるチャネルに対して検証とポリシー適用を積み重ねる多層構造です。

Web トラフィックにおいては、次のレイヤーで構成されます。

サーバー ID を検証する PKI
通信を暗号化する TLS
誤発行を検知する Certificate Transparency
標準を強制適用するブラウザポリシー

メールにおける同等のレイヤーは次のとおりです。

送信サーバーを認可する SPF
メッセージへ署名し検証する DKIM
ポリシー適用と可視性を提供する DMARC
BIMI による受信トレイでの検証済みブランドロゴ表示

どちらか一方が他方を置き換えるものではありません。TLS を完璧に実装している組織でも、メール認証がなければ脆弱です。DMARC を適用モードで運用していても、Web 通信が暗号化されていなければリスクは残ります。

ゼロトラストには両方が必要です。

チャネルごとに使用するプロトコルは異なりますが、結果は同じです。すべてのインタラクションは認証され、すべての失敗はポリシーに従って処理されます。暗黙的な信頼は排除されます。

この多層アプローチは多層防御（Defense in Depth）も実現します。一つのレイヤーが突破されても、他のレイヤーが保護を提供します。例えば攻撃者が送信サーバーを侵害したとしても、DKIM 署名は検証に失敗します。「From」アドレスを偽装しても SPF が失敗します。仮に両方を回避できたとしても、DMARC レポートが異常を可視化します。

最終的には、このような重層的な防御によってリスクを低減できます。

なぜこれがセキュリティ態勢に重要なのか

Web とメールの両方にゼロトラストを適用することは、コンプライアンス、到達率、リスク管理の観点で大きな意味を持ちます。

コンプライアンスおよび規制要件：厳格なデータ保護要件を持つ業界では、セキュリティ対策の一部としてメール認証が求められています。DMARC の適用を実証することで、なりすまし防止に積極的に取り組んでいることを監査人や規制当局へ示せます。
メールプロバイダーの要件：Google、Yahoo、Microsoft は現在、大量送信者に対して SPF、DKIM、DMARC の実装を求めています。要件を満たさない場合、正当なメールが迷惑メール扱いになったり、完全に拒否されたりする可能性があります。
攻撃対象領域の削減：DMARC を適用モードで運用すると、攻撃者は顧客、パートナー、従業員に対して自社ドメインを使ったなりすましメールを送信できなくなります。最も一般的な攻撃経路の一つが閉ざされることで、攻撃対象領域が縮小します。

ブランド保護：なりすましはトラストを損ないます。顧客が自社ドメインを装ったフィッシングメールを受信すると、送信していないにもかかわらずブランドイメージが損なわれます。DMARC の適用はこれを防ぎます。さらに BIMI によって受信トレイへ検証済みロゴを表示できます。
統合されたセキュリティ戦略：Web とメールのセキュリティを別々のサイロとして扱う組織はギャップを生み出します。統一されたゼロトラストアプローチは、すべてのコミュニケーションチャネルに一貫した検証をもたらします。