ベストプラクティス：DMARCポリシーの強化

• 2023年4月21日

DMARCプロジェクトの規模、複雑さ、進行段階には大きなばらつきがありますが、どのプロジェクトにも共通する課題として、ポリシーを強化する適切なタイミングを見極めることが挙げられます。本ガイドでは、ドメインを p=rejectへと移行するために必要な、主要な検討事項、マイルストーン検証のヒント、およびDNS構文ガイドラインについて概

DMARCポリシー

まず、DMARCポリシーの概要、従来適用される順序、そしてフィッシング、スプーフィング、およびドメインの不正利用に対する保護機能の違いについて簡単に説明します：

3つのポリシーモードは、「なし」、「隔離」、「拒否」です。
これらのポリシーは、伝統的に上記の順序で適用されます。状況によっては、最も厳格なポリシーである p=reject を最初に適用することが適切である場合があります。例えば、DMARCをパーキングドメインや、廃止されたドメイン、あるいは使用されていないドメインに適用する場合などが挙げられます。
メールを受信する組織は、送信者がメールをどのように扱ってほしいかを尊重するため、DNSに設定されたDMARCポリシーを確認します。
最後に、政策について：
- p=none は、従来のDMARCプロジェクトにおいて最初に適用されるポリシーです。「None」は、メール受信者によるメールの処理に影響を与えたり、操作したりすることなく、ドメインがどのように使用されているかを完全に把握するための手段として使用されます。これは、GmailやYahooに対して「私のメールを普段と変わらず扱ってほしいが、プロジェクトの今後の判断材料とするため、DMARCレポートを送ってほしい」と伝えるようなものです。端的に言えば、「none」は保護機能は一切提供しませんが、他のより制限の厳しいポリシーと同等の可視性を提供します。
- p=quarantine は、従来のDMARCプロジェクトにおいて適用される2番目のポリシーです。隔離ポリシーは、ドメインの不正使用に対する部分的な保護を提供し、DMARCプロジェクトにおける重要なマイルストーンとなります。隔離ポリシーは、メール受信者に対し、メッセージは引き続き受信するものの、その信頼性を格下げし、受信者のスパム/隔離フォルダに振り分けるよう指示します。
- p=reject は、ドメインの不正使用に対する最大の保護を提供します。「Reject」は、DMARCチェックに失敗したメールを完全にブロックするよう受信者に指示します。これとは異なり p=quarantineとは異なり、 p=reject では、送信者に対してメッセージ拒否通知が生成されます。これらのブロックイベントはDMARCデータにも明示されるため、どのメール送信元から何通のメッセージが拒否されたかを容易に確認できます。

DMARCポリシーの段階的導入に向けた準備

DMARCポリシーの導入を進める前に、以下の重要な点を考慮してください：

ポリシーを時期尚早に導入したり、状況を十分に把握しないまま導入したりすると、正当なメールの配信がブロックされたり、品質が低下したりする可能性があります。DMARC規格を適切に理解し、メールの送信元を把握しておくことが重要です。また、対応を行うためには、少なくとも4週間分のデータを確保しておくことをお勧めします。
正当なメール送信元をすべてDMARCアラインメントに適合させます。アラインメントとは、「From」ヘッダーのドメインと、SPFおよびDKIMレコードに関連付けられたドメインとの関係を指します。アラインメントでは、これらのドメインが一致している必要があります。 アラインメントが確立されたメールのみがDMARCを通過できます。
DMARCの遵守率の解釈と、それがDMARCポリシーの段階的強化に与える影響について。多くの場合、コンプライアンス率が98%以上に達したら、ドメインごとにDMARCポリシーを段階的に強化し始めることができます。ただし、特定の発信元について、コンプライアンスに準拠させないことを選択している場合（例えば、そのベンダーが他の社内ポリシーや基準を満たしていないなど）、98%に達する前から準備が整っている可能性も十分にあります。
- シナリオ：DMARCプロジェクトを担当するITセキュリティ担当者は、組織内の誰かが、カート放棄通知の送信にサードパーティのメールベンダーを利用していることを把握した。このサードパーティのメールベンダーは別のチームによって導入されたものだが、組織が定めた基準やポリシーに従って適切に導入・設定されていなかった。このベンダーは、当該組織を代表してメールを送信する権限がないと判断された。 ITセキュリティ担当者は、これらの無許可のメッセージが影響を受けることを十分に承知の上で、DMARCポリシーの強化を継続することを決定した。
DMARCプロジェクトの内容や進捗状況を必ず社内で周知し、メールの配信に支障が出ていると思われる場合は、同僚が問い合わせられる手段を用意してください。

DMARCのパーセンテージ・タグの役割

DMARCレコードにおいてpctタグは任意ですが、この割合を徐々に引き上げていくことで、必要な対策を特定し、100%に設定する前にそれらに対処することができます p=quarantine または p=reject DMARCポリシーを確立する前に、必要な措置を特定し、対処することができます。pctタグに関する推奨事項については、以下のセクションをご覧ください。

DMARCレコードにpctタグを含めない場合、デフォルト値は100%となります。タグの値は1%から100%の範囲です。なぜなら p=none はメールのフローに対して何のアクションも取らない監視ポリシーであるため、pctタグは不要であり、 p=noneと併用すべきではありません。

計画的なDMARCポリシーの段階的導入

DMARCポリシーの強化は段階的なプロセスです。ドメインとメール送信元がDMARCに準拠したら、ポリシーの強化プロセスを開始できます。 p=none から p=quarantine、そして p=rejectとなります。また、オプションのパーセンテージ（pct）タグをうまく活用することで、DMARCの導入をより細かく制御することができます。

ドメインと送信元をDMARC準拠にした後は、以下のようなリスク回避型のポリシー導入手順をお勧めします：

ポリシーを強化し、pctタグを増やす際は、DMARCコンプライアンス率を高い水準で達成・維持できていることを確認するため、メールの送信状況に細心の注意を払う必要があります。一般的に、ドメインごとのDMARCコンプライアンス率は98%以上であることが推奨されます。

特定のドメインのDMARC準拠率を確認するには、「詳細ビューア」を使用し、対象のドメインをフィルタリングすることをお勧めします。なお、DMARC準拠は、SPFまたはDKIMのいずれかを「合格」かつ「整合」となるよう設定することで達成されます。個々のSPF整合スコアやDKIM整合スコアは、DMARC全体の準拠率ほど重要ではありません。

以下はDMARCの例です p=quarantine ポリシーの一例です。ここでは、検証に失敗したメールの25%がスパムフォルダに移動され、残りの75%は p=noneに設定された例です：

以下はDMARCの例です p=reject 100%のDMARCポリシーの例です。受信サーバーは、DMARC認証に失敗したすべてのメールを拒否します：

隔離期間中に何が起こるか p=quarantine DMARCポリシー

で p=quarantine を適用すると、DMARCチェックに失敗したメールを、受信者のローカルスパムフォルダに送信するよう受信者に指示することになります。このポリシーに関して覚えておくべき重要な点が2つあります：

受信者はこれらのメッセージを受け入れ、スパムと同様に扱う可能性が高いです。一般ユーザー向けのメールボックス（例：gmail.com、hotmail.com、yahoo.com）にメッセージを送信する場合、これらのメッセージは受信者のスパムフォルダに振り分けられます。ビジネス向けのメールボックス（例：Microsoft 365、Google Workgroups、Mimecast）にメッセージを送信する場合、これらのメッセージはIT担当者が管理する隔離エリアに振り分けられる可能性があります。いかなる場合でも、隔離された内容を検査するためにこれらの環境にアクセスすることはできません。唯一の例外は、自社組織宛てのメールです。dmarcianなどのDMARCプラットフォームを使用して、どのメールストリームで、どの程度の頻度でメッセージが隔離されているかを特定する必要があります。
の影響 p=quarantine の影響は受信者によって確認されます。送信者には通知は送信されず、メールが突然スパムとして扱われたり、メール隔離システムに隔離されたりしたことに気付くのは受信者だけです。このシグナルはdmarcianの詳細ビューアーに存在し、そこでメールが隔離または拒否される割合を追跡することで、成功事例、認証の不備、送信パターンの特定を支援します。

次の点に留意してください。 p=quarantine ポリシーはデータ収集やDMARC導入のテストに役立ちますが、 p=reject100%に設定したポリシーこそがドメイン保護において最も安全な状態であり、認証されていないメッセージがドメインから配信されるのを防ぎます。DMARCが導入されていなくても、メール受信側は依然として適切と判断した処理を行います。 DMARCが導入されていなくても、一部の不正なメッセージは拒否されることがあります。DMARCを導入すれば、その判断を自身が行うことになり、受信側に決定を委ねることはなくなります。

この製品について p=reject DMARCポリシー

このDMARC適用ポリシーは、受信側にそのメールを恒久的に拒否するよう指示します。多くの場合、5XXシリーズのハードバウンスメッセージが生成され、送信サーバーに通知されます。

拒否されたメッセージを把握するため、DMARCデータを定期的に確認し、パターンの変化を検知することをお勧めします。 p=reject 、シャドーITや悪意のあるメールなど、自社ドメインから送信される認証されていないメールに対する究極の防御策となります。

次のステップ：DMARCのメンテナンス

DMARCポリシーの適用目標である p=rejectというDMARCポリシーの適用目標を達成したら、次のステップは、DMARCコンプライアンスのための長期的な管理プロセスを確立し、DMARCポリシーの適用に関連する潜在的な問題を最小限に抑えることです。DMARCプロジェクトの「Reject後の段階」では、予期せぬ事態や計画的な変更に組織が備えられるよう準備することに重点が置かれます。 p=rejectに到達した後、当社のDMARC管理プラットフォームを活用して確認すべき点は以下の通りです：

SPFレコードの定期的な確認 – 当社の「SPF Surveyor」を活用し、組織を代表してメール送信が許可されているIPアドレスやネットブロックが実際に使用されているかどうかを確認することで、SPFレコードが最新の状態であることを保証してください。利用を終了したベンダーや、過去に誤って追加されたベンダーに関するレコードの内容を見直すことは、常に推奨される慣行です。これは「過剰認証」と呼ばれ、一般的に受信者から好ましく思われていません。
SPFの変更承認プロセス – 組織内のDMARCプロジェクト責任者の承認なしにSPFの変更が行われないよう、必ず確認してください。予期せぬ変更が発生した際に通知されるよう、アラートを設定してください。
DKIMキーの定期的な更新の監視 – DKIMキーは定期的に更新する必要があります。更新の頻度は数か月ごと、あるいは年1回などが考えられます。
DMARCデータの定期的な確認 – 正当なメールの新たな送信元がないか、必ず確認してください。また、ベンダー統合の機会の追跡、メール送信量の変動、特定のベンダーにおけるコンプライアンス違反の発生、予期せぬ配信パターンの分析など、その他の調査を実施することも可能です。
レポート機能 –dmarcian を設定して、ドメインの利用状況や不正利用に関するレポートを送信するようにします。
社内のインシデント管理 – DMARCに関連すると考えられるメール配信の問題が発生した場合は、問題点と解決策を確認してください。DMARCデータをフィルタリングして問題の範囲を把握することで、状況をより詳細に把握することができます。

DMARC管理における「拒否」フェーズ後の対応について読む

dmarcianの使命は、メールエコシステム全体にDMARCを普及させ、メールとインターネットをより安全なものにすることです。DMARCポリシーを p=reject に設定することで、配信率が向上し、犯罪者がお客様のドメインを悪用することを防ぎます。当社の段階的な導入ポリシーは、悪意のある攻撃者がお客様のドメインを乗っ取るのを防ぐ安全な方法です。

あなたのメールを頼りにしている人々を守りましょう