ベストプラクティス：DMARCポリシーの段階的移行（強化）

• 2023年4月21日

DMARCプロジェクトは、組織の規模、複雑さ、進行ステージによって千差万別ですが、共通する課題が一つあります。それは、「いつ次の段階へポリシーを進めるべきか」の判断です。本ガイドでは、自信を持ってドメインのポリシーを最も厳格な p=reject（拒否）へと移行させるために必要な、重要な検討事項、マイルストーン達成時の確認チップス、およびDNS構文のガイドラインについて解説します。

DMARCポリシーの概要

まず、DMARCポリシーの種類、一般的な適用順序、そしてフィッシングやなりすまし、ドメインの不正利用に対する防御力の違いについて簡単に復習します。

3つのポリシーモードには、「none（監視）」、「quarantine（隔離）」、「reject（拒否）」の3つがあります。
これらのポリシーは、通常上記の順序で段階的に適用されます。ただし、例外として、使用していないドメインや廃止されたドメイン（いわゆるパークドメイン）にDMARCを適用する場合などは、最初から最も厳格な p=reject を適用するのが適切なケースもあります。
あなたのメールを受け取る受信側組織（GmailやYahooなど）は、あなたのDNSに公開されているDMARCポリシーを参照し、あなたが指定した方法に従ってメールを処理します。
各ポリシーの役割は以下の通りです。
- p=none（監視）：
  従来のDMARCプロジェクトで最初に適用されるポリシーです。「none」は、受信側でのメール処理に一切影響を与えることなく、自ドメインがどのように使われているかを完全に可視化するために使用します。GmailやYahooに対し、「メールは通常通りに処理してください。ただし、今後の判断材料にするためにDMARCレポートだけは送ってください」と伝えるようなものです。一言で言えば、「none」は防御力を提供しませんが、他の厳格なポリシーと同じ可視性（レポート）を得ることができます。
- p=quarantine（隔離）：
  プロジェクトの第2段階で適用されるポリシーです。ドメインの不正利用に対して「部分的な保護」を提供し、DMARCプロジェクトにおける重要なマイルストーンとなります。「quarantine」は受信側に対し、「メッセージ自体は受け取ってよいが、信頼性を格下げし、受信者の迷惑メール（隔離）フォルダに振り分けること」を指示します。
- p=reject（拒否）：
  ドメインの不正利用に対して最大の防御力を発揮します。「reject」は受信側に対し、DMARC認証に失敗したメールは完全にブロック（受信拒否）するよう指示します。p=quarantine とは異なり、p=reject ではメッセージが拒否された際、送信元に対してエラー（バウンス）通知が生成されます。また、これらのブロックイベントはDMARCデータ上にも明記されるため、どのメール送信元から何通のメッセージが拒否されたかを容易に監視できます。

ポリシー移行への準備

DMARCポリシーを強化し始める前に、以下の重要なポイントを確認してください。

時期尚早な移行の最大のリスク：
適切な可視化を行わないまま急いでポリシーを進めると、正規の重要なメールがブロックされたり、迷惑メール扱いにされたりするリスクがあります。DMARC規格を適切に理解し、自社のメール送信元を十分に把握しておく必要があります。判断を下す前に、最低4週間分のデータを蓄積して検証することをお勧めします。
正規のメール送信元をすべて「DMARCアライメント」に準拠させる：
アライメントとは、ユーザーが目にする「Fromヘッダー」のドメインと、SPF/DKIMレコードに関連付けられたドメインとの間の整合性のことです。DMARCをパスするには、これらのドメインが一致（または関連）している必要があります。アライメントが成立しているメールだけが、DMARC認証をパスできます。
DMARC準拠率（コンプライアンス率）の数値を指標にする：
ほとんどの場合、対象ドメインのDMARC準拠率が98%以上に達した時点で、ドメインごとにポリシーを次の段階へ進める検討に入ることができます。ただし、認識している送信元であっても、あえてアライメントを通さないと判断した場合（ベンダー側が自社の内部ポリシーや基準を満たせない場合など）は、98%の基準に達する前であってもポリシーを進める準備が整っていると言えます。
- 💡 想定されるシナリオ：
  DMARCプロジェクトを担当するITセキュリティチームが、社内の特定の部署が外部のサードパーティ製メール配信ベンダーを使って「ショッピングカート放棄リマインドメール」を送信していることを突き止めました。このベンダーは他部署が独自に契約したもので、社内のIT導入基準やポリシーに沿ったセットアップが行われていませんでした。このベンダーからの配信は「未承認（許可しない）」と判断されたため、ITセキュリティチームは、これら未承認のメールがブロック等の影響を受けることを承知の上で、DMARCポリシーの強化を断行することにしました。
社内への周知：
DMARCプロジェクトの進捗を社内に共有し、もしメールの到達に影響が出ていると疑われる場合に、同僚や他部署が問い合わせできる窓口（確認ルート）を必ず用意しておいてください。

DMARC「パーセンテージ（pct）タグ」の役割

DMARCレコードの pct（percentage）タグはオプション（任意）ですが、この数値を段階的に引き上げることで、100%の p=quarantine や p=reject を適用する前に、必要な対策をあぶり出して対処することができます。具体的な推奨値については次のセクションで解説します。

なお、レコードに pct タグを記載しない場合のデフォルト値は 100（100%）です。設定値の範囲は 1 から 100 までです。p=none はメールのフローに一切手を加えない「監視専用」のポリシーであるため、 p=none と共に pct タグを使用することは無意味（不要）です。

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

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

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

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

特定のドメインの準拠率を確認するには、dmarcianの [Detail Viewer] を使用し、該当ドメインでフィルタリングすることをお勧めします。おさらいですが、DMARCの準拠は、SPFまたはDKIMのいずれかが「パス（Pass）」かつ「アライメント（一致）」することで達成されます。個別のSPFアライメントやDKIMアライメントのスコアそのものよりも、全体の「DMARC準拠率」が基準を満たしているかどうかが重要です。

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

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

p=quarantine （隔離）ポリシーで起きること

p=quarantine を強制適用すると、DMARC認証に失敗したメールをローカルの受信者の迷惑メールフォルダに送るよう受信側に指示することになります。このフェーズでは以下の2つの詳細を覚えておいてください。

受信側の処理：
受信側はこれらのメッセージを受け取りますが、スパムと同様に扱います。一般消費者向けのメーラー（Gmail、Hotmail、Yahooなど）宛ての場合、メールはユーザー自身の迷惑メールフォルダに直行します。企業向けの環境（Microsoft 365、Google Workspace、Mimecastなど）宛ての場合、IT管理者が管理する「隔離ホールドエリア」に留め置かれる可能性があります。自社宛てのメールを除き、送信者側からはこれら外部の隔離環境の中身を直接検査することは一切できません。だからこそ、dmarcianのようなDMARCプラットフォームを使用して、どのメールストリームがどれだけの頻度で隔離されているかをデータとして特定・把握する必要があります。
影響の可視化：
「隔離」の影響は受信側でのみ発生し、送信元にエラー通知などは返されません。受信側で突然メールがスパム扱いされたり隔離システムに隔離されたりするだけです。この動きはdmarcianの [Detail Viewer] でトラッキング可能で、隔離または拒否されたメールの割合を追跡し、認証の成功、ギャップ（設定漏れ）、送信パターンを特定するのに役立ちます。

p=quarantine ポリシーはデータ収集やテストに役立ちますが、ドメイン保護の観点で最も安全な最終状態は p=reject（100%）です。 これにより、自社ドメインを騙った未認証のメッセージの配送を完全に防ぐことができます。DMARCが設定されていない状態であっても、受信サーバーは独自の判断で怪しいメールを拒否することがありますが、DMARCを導入すれば、その判断を受信側に委ねるのではなく、ドメイン所有者であるあなた自身がコントロールし、決定を下すことができるようになります。

p=reject（拒否）ポリシーで起きること

このポリシーは、受信側に対して認証失敗メールを永久に拒否するよう指示します。多くの場合、送信元のサーバーに対して「5XX系」のハードバウンス（不達）メッセージが返されます。

拒否されたメッセージを把握するために、定期的にDMARCデータをチェックしてパターンの変化を検知する運用フロー（ルーティン）を確立することをお勧めします。p=reject ポリシーは、自社ドメインから発信されるシャドーIT（未承認のツール）や悪意ある不正メールを含む、未認証メールに対する究極の防御策です。

次のステップ：DMARCの維持・運用（メンテナンス）

最高目標である p=reject の適用を達成した後のステップは、DMARC準拠を長期的に維持し、トラブルを最小限に抑えるための運用プロセスを確立することです。この「Life after Reject（拒否ポリシー適用後の世界）」フェーズでは、予期せぬ事態や、計画された変更（新しいツールの導入など）に組織が柔軟に対応できるようにすることに焦点を当てます。
p=reject 到達後は、[dmarcian 管理プラットフォーム] を活用し、以下の項目に目を光らせてください。

SPFレコードの定期的なチェック：
弊社の [SPF Surveyor] を使用して、組織を代表してメール送信を許可しているIPやネットブロックが、現在も実際に使われているかを確認し、SPFレコードを最新に保ちます。すでに使っていないベンダーや、過去に誤って追加された記述を削除するクレンジングは良い習慣です。不要な記述が残っている状態は「過剰認証（over-authentication）」と呼ばれ、受信側からも好ましく思われません。
SPF変更の承認プロセスの確立：
組織内のDMARCプロジェクト所有者の承認なしに、勝手にSPFが変更されないような仕組みを作ってください。予期せぬ変更が行われた際に通知を受け取れるよう、[アラート機能] を設定しておくと安心です。
DKIM鍵の定期的なローテーションの監視：
DKIM鍵は、数ヶ月ごと、あるいは年に1回などの頻度で定期的にローテーション（更新）されるべきです。
DMARCデータの定期的な監視：
新しく導入された「正規のメール送信元」がないかをチェックします。また、ベンダーの集約機会の検討、メール送信ボリュームの変動、特定ベンダーにおける準拠率の低下、予期せぬ配信パターンの発生などを調査するのにも役立ちます。
レポート機能の活用：
自社ドメインの正当な利用や悪用に関するレポートを定期的に配信するよう、[dmarcianのレポート設定] を行います。
社内のインシデント管理：
メールの到達性に問題が発生し、それがDMARCポリシーに起因すると疑われる場合は、原因の特定と解決を迅速に行います。[DMARCデータのフィルタリング] を行うことで、影響の範囲を正確に把握し、全体像をクリアに確認できます。

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

dmarcianの使命は、メールエコシステム全体にDMARCを普及させ、メールとインターネットをより安全にすることです。DMARCポリシーを p=reject へと進めることは、メールの到達率を向上させ、犯罪者があなたのドメインを悪質な目的で使用することを阻止します。弊社の段階的なランプアップ（強化）ポリシーは、悪意ある第三者によるドメインの乗っ取りから安全に自社を守るための確実なアプローチです。

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