NIS2が自社のメールにとって何を意味するのかを整理しようとしているなら、このガイドはあなたのためのものです。NIS2は欧州連合の改正されたサイバーセキュリティ法であり、正式には指令(EU)2022/2555です。従来の規則の対象をはるかに多くの組織へと広げ、それらの組織が講じなければならないセキュリティ対策により厳しい要件を課しています。
多くの人がまず尋ねる質問のひとつは、NIS2がDMARCを要求しているのかどうかです。DMARCとは、第三者があなたのドメインを差出人としてメールを送るのを止める標準規格です。正直な答えには2つの側面があります。NIS2はその条文のどこでもDMARCに言及していません。しかし、組織に対して、なりすましからメールを保護することを求めており、しかも単に監視するだけでなく偽造メールをブロックするレベルで行うことを求めています。実際のところ、これは強制レベルのDMARCがもたらすものです。
このガイドでは、NIS2が誰に適用されるのか、メール認証がその要件のどこに位置づけられるのか、そしてNIS2が自社に適用される場合に何をすべきかを、自社のDNSを管理している場合でも、それを管理する誰かに依存している場合でも取り上げます。
名指しでは要求されていません。NIS2はその条文のどこでもDMARC、SPF、DKIMに言及していません。NIS2が求めているのは、対象となる組織がサイバーセキュリティリスクを管理するために適切かつ相応の対策を講じ、その証拠を示せるようにすることです。
メール認証は、その義務の一部を満たす手段です。なりすましメールは攻撃者がセキュリティを突破する最も一般的な手口のひとつであり、偽造メールが自社のドメインから送られるのを防ぐことは、まさにこの指令が期待する種類の対策です。これがDMARCの設計目的であるため、NIS2がDMARCを要求しているのかという問いへの実務的な答えは、明示されてはいないものの「はい」に近いものになります。
NIS2は、エネルギー、運輸、銀行、医療、飲料水、デジタルインフラ、行政、郵便サービスなど、18の分野にわたる中規模および大規模の組織を対象としています。これらの分野のいずれかで中規模または大規模の組織を運営している場合、自社を重要インフラと考えたことが一度もなくても、対象となっている可能性が高いです。
NIS2はこれらの組織を2つの区分に分けています。基幹事業体(essential entities)、つまり最も重要な分野における大規模な事業者は、能動的な監督と最も重い罰則の対象となります。重要事業体(important entities)、つまり対象となるその他の組織は、主にインシデント発生後に適用される、より軽い監督の対象となります。
基幹事業体は、不遵守に対する罰則として、最大1,000万ユーロまたは全世界の年間総売上高の2%のいずれか高い方の制裁金を科される可能性があります。重要事業体は最大700万ユーロまたは売上高の1.4%です。NIS2は経営幹部に対して個人としての責任も問います。
NIS2はそのセキュリティ義務を第21条に定めており、対象となる組織が講じなければならないリスク管理対策を列挙しています。この一覧は意図的に幅広く、ネットワークセキュリティ、アクセス制御、暗号化、インシデント対応、基本的なサイバー衛生などが含まれます。メール認証が単独で名指しされていないのは、この指令が期待するセキュリティの結果を記述しているのであって、それを達成するために用いる具体的な手法や技術を記述しているわけではないからです。
NIS2はある一群の組織に対してはさらに踏み込んでいます。この指令には独自の実施規則、すなわち委員会実施規則(EU)2024/2690があり、DNSプロバイダー、クラウド事業者、マネージドサービスプロバイダーといったデジタルインフラ事業者に対して拘束力のある技術的規則を定めています。これにより、第21条の一般的な文言が彼らにとっての具体的な要件へと変わります。これが採択された後、EUのサイバーセキュリティ機関ENISAは2025年6月に技術的な実施ガイダンスを公表し、各規則をどのように満たすか、そして監査人が何を証拠として確認するかを示しました。SPF、DKIM、DMARCを含むメール認証は、そのメールセキュリティおよびネットワークセキュリティ対策の一部です。
自社がこうしたデジタルインフラ事業者のいずれにも該当しない場合、この実施規則が直接拘束することはありませんが、NIS2そのものは依然として適用されます。第21条に基づく一般的な義務は相応のセキュリティ対策を期待しており、自社のドメインをなりすましから保護することはその明確な一例です。メール認証はそれを行う標準的な方法です。
NIS2は特定の技術を名指ししていないため、DMARC以外の何かでコンプライアンスを維持できないかと尋ねるのは当然です。一般的なメールの脅威に対しては、いくつものツールが役立ちます。セキュアメールゲートウェイ、フィッシング対策フィルター、リンクや添付ファイルのスキャン、そして従業員向けのセキュリティ意識向上トレーニングです。それぞれがセキュリティプログラムの中で役割を持っています。
しかし、いずれもこの特定の問題を解決しません。これらのツールは、自社の受信トレイに届くメールをチェックします。誰かがあなたのドメインを偽造し、詐欺メールがあたかもあなたから送られたかのように見せかけて、顧客、取引先、従業員に送りつけるのを止める役には立ちません。この脅威は受信ではなく送信の方向で起こり、それに対処する確立された唯一の方法がメール認証です。SPFとDKIMは、メッセージがあなたのドメインを使用する権限を持っていることを証明します。次にDMARCは、これらのチェックを受信者が目にするドメイン名と結びつけ、認証に失敗したメールをどう扱うかを受信サーバーに指示し、その結果をあなたに報告します。これに代わる本当の選択肢はありません。
ここでよく挙がる関連する2つの対策がありますが、どちらも認証の代わりにはなりません。MTA-STSとTLS-RPTによる転送中の暗号化もNIS2の技術ガイダンスに登場しますが、これは誰が送ったかを証明するのではなく、メールが移動する間に保護するものです。BIMIも強制レベルのDMARCに依存します。受信トレイのメッセージの隣に自社のロゴを表示するもので、認証を適切に行ったことへのご褒美であって、その代替ではありません。
つまりNIS2があなたに残している選択は、どの標準規格を採用するかではありません。それはすでに存在するその一つをどう運用するか、すなわちどのプロバイダーを使い、どのツールを使い、自社内で運用するのか監視サービスを通じて運用するのか、ということです。これは、指令が一度も明記していないにもかかわらず、監査人がメール認証の導入を期待する理由でもあります。
DMARCレコードを公開することは、それによって保護されていることと同じではありません。p=noneに設定されたレコードは、受信メールサーバーに対して監視と報告を行うよう指示しますが、なりすましメッセージはそのまま配信させます。認証に失敗したメールをブロックするには、ポリシーをp=quarantineまたはp=rejectに移行しなければなりません。これが監視と保護の境界線であり、これらの規則が求めるレベルです。
ほとんどのドメインはこの境界線をまだ越えていません。DMARCeyeの2026年第1四半期データセットでは、ヨーロッパの国別ドメインの大半が依然として監視のみのポリシーにとどまっています。.deドメインの約39%、.frドメインの50%、.nlドメインの43%がp=noneです。チェコのドメインはこのセットの中で最もリスクが高く、約69%がp=noneで、p=rejectはわずか10件に1件です。この区分に属するドメインは、監査人が確認できるDMARCレコードを持ってはいるものの、その背後に強制力がありません。
これらの数値は、DMARC導入状況に関するDMARCeyeの2026年第1四半期業界レポートに基づいています。
このパターンはNIS2に固有のものではありません。同じ強制の基準は、PCI DSSのフィッシング対策要件や、GoogleとYahooの送信者規則にも現れます。何もブロックしないレコードは数えに入りません。自社のドメインが何を公開しているのか分からない場合は、ここで確認できます。
強制ポリシーへ至る道筋は、その理由がNIS2であれ、PCI DSSであれ、単にドメインをなりすまされたくないからであれ、同じです。順序が重要です。なぜなら、急ぎすぎることこそが正規のメールがブロックされる原因だからです。
まず、あなたのドメインを差出人としてメールを送るすべてのサービスを洗い出すことから始めます。自社のメールプラットフォームはもちろん、マーケティングツール、請求システム、ヘルプデスク、そのほかあなたに代わってメールを送るあらゆるものです。それぞれをSPFまたはDKIMで認証し、メールがきれいに通過するようにします。次に数週間にわたってDMARC集約レポートを読み、正規のメールが失敗していないことを確認し、そのうえで初めてポリシーをp=quarantineへ、さらにp=rejectへと移行します。完全な実装ガイドが、各ステップを詳しく解説しています。
これを読んでいる可能性が高いマーケティングや広報の担当者の方へ。自社の組織のDNSを管理していないのであれば、これは一人で行う変更ではありません。DMARCレコードはDNS内にあるため、強制への移行はドメインのレコードを管理する人、通常はITか外部のプロバイダーの担当です。あなたの役割は、自分が持つすべての送信ツールが上記の一覧に載っていることを確かめ、ポリシーを厳しくした際に正規のメールが何も巻き込まれないようにすることです。
これは、DMARCeyeの無料プランが解消するために作られたギャップです。DMARCレポートを読み取り、どの送信者が合格していてどれが失敗しているのかを示します。そして次に何を修正すべきかを伝えるので、監視から強制への移行は当て推量ではなく、一連の明確なステップになります。
NIS2はEUレベルで発効し、加盟国が国内法に取り込むための国内法化の期限は2024年10月17日でした。多くの国がその期限を逃し、国内法はそれぞれの独自のスケジュールで順次施行されてきました。
実際のところ、あなたの正確な義務は指令そのものだけでなく、自国の実施法に左右されます。とはいえ技術的な方向性は定まっています。実施規則とENISAのガイダンスが何が望ましい状態かを示しており、強制ポリシーでのメール認証はその一部です。コンプライアンスプロジェクトの範囲を定める前に、自国の国内法化の状況を確認してください。
NIS2は、DMARCが記載されたチェックリストを手渡してくれるわけではありません。手渡されるのは、メールのリスクを管理し、それを実行していることを証明する義務であり、強制ポリシーでのメール認証はそれを満たす手段です。この指令を「DMARCが今や必須になった」と読むのは言い過ぎです。強制を任意のものと扱うのは控えめすぎます。正確な立ち位置はその中間にあります。
必要な作業は、あなたを差出人として送るすべてのサービスを把握し、それぞれを認証し、正規のメールを壊さずに強制へ移行することです。DMARCeyeは、この作業をドメインごとに見える化し、管理可能にするために存在しています。そうすることで、コンプライアンスは適切にメールセキュリティを行った結果として自然に得られるものになります。