DMARCを導入していますか？それは本当にドメインを保護できていますか？

DMARCの導入は最初の一歩にすぎません

セキュリティ評価を実施したり、メール認証の設定を確認したりした際に、「DMARCのquarantine/rejectポリシーが有効になっていません」という警告を目にしたことがあるかもしれません。

一見すると、何か問題が発生しているように思えます。しかし実際には、DMARCの導入を開始しているものの、まだ設定が完了していないことを示しています。

多くの組織は、p=noneポリシーを設定したDMARCレコードを公開しています。これにより、メールの配信に影響を与えることなく、メール認証の状況を監視できます。これは重要な第一歩ですが、攻撃者によるドメインのなりすましを防ぐことはできません。ポリシーをquarantine（隔離）またはreject（拒否）に変更するまでは、認証に失敗したメールに対してメールボックスプロバイダが対処するよう指示されません。

この警告の意味を理解し、安全にポリシーの適用を進めることで、フィッシングのリスクを軽減し、ブランドを保護するとともに、組織が送信するメールの信頼性を高めることができます。

DMARCポリシーの仕組み：基本のおさらい

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、メールが認証に失敗した場合の処理方法を、ドメイン所有者がメールボックスプロバイダに指示できる仕組みです。DMARCはSPFとDKIMを基盤とし、ポリシーの適用とレポート機能を追加することで、ドメインの保護と認証上の問題の可視化を実現します。

すべてのDMARCレコードには、認証に失敗したメールを受信側のメールサーバがどのように処理するかを指定するポリシー（p=）が含まれています。

p=none

このポリシーは、DMARC認証に失敗したメールに対して、メールボックスプロバイダに特別な措置を求めません。メールは通常どおり配信され、認証結果のレポートがドメイン所有者に送信されます。

監視モードは、DMARCの導入段階で役立ちます。正規のメール送信元を特定し、認証設定の不備を発見して、より厳格なポリシーを適用する前に設定上の問題を修正できます。

p=quarantine

p=quarantineを設定すると、メールボックスプロバイダに対して、認証に失敗したメールを不審なメールとして扱うよう求めます。プロバイダによっては、受信者の受信トレイではなく、迷惑メールフォルダに振り分けられます。

このポリシーは、認証に失敗したメールを完全にブロックする前に影響を監視できるため、一定の保護を確保しながら段階的に対策を進められます。

p=reject

p=rejectは、最も強力な保護を提供するポリシーです。メールボックスプロバイダに対して、DMARC認証に失敗したメールを拒否するよう指示し、なりすましメールが受信者に届くことを防ぎます。

すべての正規のメール送信元で適切に認証が設定されている組織にとって、通常、rejectポリシーへの移行が長期的な目標となります。

「DMARCのquarantine/rejectポリシーが有効になっていません」とはどういう意味ですか？

この警告は通常、ドメインにDMARCレコードがすでに設定されているものの、ポリシーがp=quarantineまたはp=rejectではなく、p=noneのままになっていることを意味します。

つまり、認証結果に関する有用なレポートは収集できていますが、DMARC認証に失敗したメールを隔離または拒否するよう、メールボックスプロバイダには指示されていません。そのため、他のセキュリティ対策でブロックされない限り、攻撃者がドメインになりすます可能性があります。

これは、玄関に鍵をかけずに防犯カメラだけを設置しているような状態です。何が起きているかは把握できますが、DMARCが提供する強力な保護機能をまだ十分に活用できていません。

多くの組織がp=noneのままにしている理由

ポリシーを適用すれば保護を強化できるのに、なぜ多くの組織は有効化しないのでしょうか。

最大の課題は、DMARCレコードを公開することではありません。正規のメール送信元すべてが、ポリシーの適用に対応できる状態になっているかを確認することです。

ほとんどの組織では、想定以上に多くのシステムからメールが送信されています。マーケティングオートメーションプラットフォーム、カスタマサポートツール、人事管理ソフトウェア、CRMシステム、請求管理プラットフォーム、コラボレーションツールなど、さまざまなサードパーティサービスが自社ドメインを使用してメールを送信している可能性があります。これらのシステムのうち一つでも適切に認証されていない場合、ポリシーの適用を急ぐと、正規のメール通信に支障が生じるおそれがあります。

また、多くのセキュリティチームやITチームは、十分なドキュメントが残されていないレガシーインフラストラクチャを長年にわたって運用しています。すべての送信元を特定し、SPFとDKIMのアライメントを検証し、複数の部門と調整しながら設定を変更するには時間がかかります。

そのためにp=noneが用意されています。メール環境全体を可視化し、より厳格なポリシーを適用する前に必要な状況を把握できます。

p=noneは有用ですが、それだけでは不十分な理由

監視モードから始めることは、DMARC導入において適切な方法です。これにより、次のことが可能になります。

• 組織内の正規のメール送信元を特定する
• 認証エラーを検出する
• SPFとDKIMのアライメントを検証する
• メール配信に影響を与えずにDMARCレポートを確認する

問題は、そこで対応を止めてしまうことです。p=noneの状態が数か月、あるいは数年続くと、認証に失敗したメールをブロックするようメールボックスプロバイダに指示されないため、ドメインは引き続きなりすまし攻撃のリスクにさらされます。監視によって状況を把握できますが、実効性のある保護を実現するにはポリシーの適用が必要です。

DMARCポリシーを適用しない場合のリスク

DMARCを監視モードのまま運用し続けると、組織は次のようなセキュリティ上およびビジネス上のリスクにさらされる可能性があります。

ドメインのなりすまし

攻撃者は自社ドメインから送信されたように見えるメールを送り続けることができ、フィッシング攻撃が成功する可能性が高まります。

フィッシングとビジネスメール詐欺

サイバー犯罪者は、信頼されている組織になりすまして認証情報を盗み、マルウェアを配布したり、従業員や顧客をだまして送金や機密情報の提供を促したりします。DMARCポリシーを厳格に適用することで、自社ドメインを悪用したこうした攻撃の実行を大幅に困難にできます。

ブランドへの信頼の低下

顧客は、企業から届く正規のメールを信頼できるものと考えています。しかし、本物と見分けがつかないなりすましメールを受信すると、その後に届く正規のメールまで疑うようになる可能性があります。

なりすまし攻撃によって失われた信頼を回復するには、被害を未然に防ぐための保護対策を導入するよりも、はるかに長い時間がかかる場合があります。

メール到達率への影響

メールボックスプロバイダは、送信元のブランド評価を判断する際に、メール認証の状況をますます重視しています。DMARCだけで受信トレイへの到達が保証されるわけではありませんが、適切な認証を維持することで、送信元のブランド評価を良好に保ち、メール配信に対する信頼性を高めることができます。

セキュリティチームとITチームの負担増加

ポリシーを適用していない場合、セキュリティチームは、フィッシングの報告の調査、ユーザからの問い合わせへの対応、本来防げたはずのなりすましインシデントの追跡などに、余分な時間を費やすことになります。

現在のDMARCポリシーを確認する方法

現在のポリシーは、ドメインのDMARCレコードを確認することで把握できます。

次の場所に公開されているDNS TXTレコードを確認してください。

_dmarc.example.com

一般的なレコードは次のようになります。

v=DMARC1; p=none; rua=mailto:dmarc@example.com

特に、次の項目を確認してください。

• バージョン（v=DMARC1）：現在のDMARC仕様を使用しているかを確認する
• ポリシー（p=）：none、quarantine、rejectのいずれが設定されているかを確認する
• レポート送信先アドレス（rua、および使用している場合はruf）：DMARCレポートの受信先を確認する
• アライメント設定（adkimとaspf）：厳格または緩和されたアライメントを設定している場合、その内容を確認する

ポリシーがp=noneのままであれば、この警告はポリシーの適用がまだ有効になっていないことを示しているだけです。

DMARCポリシーを適用する前に確認すべきこと

DMARCポリシーを変更する前に、次の対応が完了していることを確認してください。

• 自社ドメインを使用してメールを送信する正規のシステムをすべて特定する
• 各送信元にSPFまたはDKIM、あるいはその両方を正しく設定する
• 一定期間のDMARCレポートを確認し、認証エラーを特定する
• 業務アプリケーションを管理する社内チームと調整する
• ポリシーを変更する前に、重要なメール送信ワークフローをテストする

これらの対応を完了することで、ポリシーの適用開始時に正規のメール配信が妨げられるリスクを軽減できます。

p=noneからquarantineまたはrejectへ移行する方法

ほとんどの組織にとって、最初からポリシーを全面的に適用するのではなく、段階的に導入することが最も安全な方法です。

1. 正規の送信元をすべて把握する
   サードパーティサービスや社内で管理するアプリケーションを含め、自社ドメインを使用してメールを送信するすべてのシステムを一覧化します。
2. 認証上の問題を修正する
   すべての送信元にSPF、DKIM、またはその両方が正しく設定されていることを確認し、DMARCポリシーとのアライメントを検証します。
3. DMARCレポートを確認する
   ポリシーを厳格化する前に認証レポートを分析し、不明な送信元、設定上の問題、繰り返し発生する認証エラーを特定します。
4. 部分的なポリシー適用から始める
   多くの組織は、影響を抑えながら結果を監視するため、まずp=quarantineへ移行します。
5. ポリシーの適用範囲を段階的に拡大する
   認証状況が改善し、運用への確信が高まったら、ポリシーの適用対象となるメールの割合を徐々に増やします。
6. p=rejectへ移行する
   正規のメールが確実に認証されていることを確認できたら、p=rejectへ移行し、ドメインのなりすましに対する最も強力な保護を実現します。

DMARCポリシーの適用時によくある間違い

十分に計画された導入でも、問題が発生することがあります。代表的な例は次のとおりです。

• 自社に代わってメールを送信するサードパーティサービスを見落とす
• SPFのinclude設定が不足している、または誤っている
• クラウドアプリケーションでDKIM署名を有効にし忘れる
• 正規の送信元をすべて検証する前にp=rejectへ直接移行する
• ポリシーを公開した後、DMARCレポートを継続的に確認しない

段階的に導入することで、こうした問題を最小限に抑えながら、確実にポリシーを適用できるようになります。

デジサートとValimailがDMARCポリシーの適用を支援する方法

p=noneからquarantineまたはrejectへの移行は、単なる技術的な設定変更ではありません。移行を成功させるには、すべての正規のメール送信元を把握し、適切に認証されていることを確信できる状態が必要です。

そこで、デジサートとValimailが連携して支援します。現在デジサートの一員となったValimailは、正規の送信元の特定、認証結果の監視、設定上の問題の発見を可能にする可視性を提供し、DMARCポリシーの安全な適用を支援します。手作業による監査やスプレッドシートに頼ることなく、メール環境全体をより明確に把握し、安心して監視からポリシーの適用へと移行できます。さらに、デジサートの包括的なデジタルトラストプラットフォームと組み合わせることで、デジタル通信におけるIDの信頼性を強化し、顧客、従業員、パートナをなりすまし攻撃から保護できます。

その効果は、DMARCポリシーの強化だけにとどまりません。受信側のシステムがドメインの正当な使用を検証できるようにする、よりレジリエンスの高いデジタルトラストの実現につながります。