DMARCプロジェクトの規模、複雑さ、段階はさまざまですが、ポリシーを進める適切な時期を理解するという共通の課題があります。このガイドでは、ドメインをp=rejectの厳格なDMARCポリシーに自信を持って移行するために必要な、重要な考慮事項、マイルストーン検証のヒント、DNS構文ガイドラインについて説明します。
DMARCポリシー
まず、DMARCポリシーの概要、DMARCポリシーの適用順序、DMARCポリシーのフィッシング、なりすまし、ドメインの不正使用に対する防御の違いについて簡単に説明します。
- 3つのポリシーモードは、「何もしない」、「隔離」、「拒否」である。
- これらのポリシーは最も伝統的に上記の順序で適用される。特定の状況下では、例えば、パーキングドメインや非アクティブドメインにDMARCを適用する場合、より厳格なポリシーを最初に適用することが適切な場合があります。
- あなたのメールを受信する組織は、DNSのDMARCポリシーを、あなたのメールがどのように扱われたいかを尊重する手段として見ます。
- 最後に。
- p=noneは、従来のDMARCプロジェクトで最初に適用されるポリシーです。「何もしない」は、メール受信者があなたのメールをどのように扱うかに影響を与えたり影響を与えたりすることなく、あなたのドメインがどのように使用されているかを完全に可視化する手段として使用されます。これは、GmailやYahooに、”私のメールを通常と同じように扱わないでください、でもDMARCレポートを送ってください。平たく言えば、「none」は保護をゼロにしますが、他のより制限的なポリシーと同じ可視性を提供します。
- p=quarantineは、従来のDMARCプロジェクトで適用される2番目のポリシーです。検疫 “ポリシーは、ドメインの不正使用に対する部分的な保護を提供し、DMARCプロジェクトの重要なマイルストーンとなります。”隔離 “は、メール受信者に対して、メッセージは受け入れるが、メールの信頼性をダウングレードし、受信者のスパム/隔離フォルダに入れるように指示します。
- p=rejectは、ドメインの不正使用に対する最大の防御策となります。”Reject “は、DMARCチェックに失敗したメールを完全にブロックするようメール受信者に指示します。p=quarantineとは異なり、p=rejectではメッセージ拒否通知が送信者に返送されます。これらのブロックイベントはDMARCデータでも明らかにされるため、どのメール送信元から何通のメッセージが拒否されたかを容易に観察することができます。
DMARCポリシー進行の準備
DMARCポリシーを進める前に、いくつか重要な考慮事項を挙げておきます。
- DMARCポリシーの適用が早すぎたり、適切な可視化ができていなかったりすると、正当なEメールの配信がブロックされたり、劣化したりする可能性があります。DMARC標準を適切に理解し、メールソースを可視化する必要があります。また、最低でも4週間分のデータを用意して対応することをお勧めします。
- 各正当なメールソースをDMARCに整合させる。アライメントとは、Fromヘッダーアドレスのドメインと、SPFおよびDKIMレコードに関連付けられたドメインとの関係を指します。アライメントでは、これらのドメインが一致する必要があります。アライメントされたメールのみがDMARCを通過することができます。
- DMARCコンプライアンスパーセント率の解釈と、DMARCポリシーの進行にどのように影響を与えるべきか。ほとんどの場合、コンプライアンス率が98%以上に達した時点で、ドメインごとにDMARCポリシーを進めることができます。しかし、あなたが認識しているにもかかわらず、それを整合させないことを選択したメールソースがある場合（ベンダーが他の社内ポリシー/基準を満たしていない可能性があるなど）、98%に達する前に準備が整う可能性があります。
- シナリオDMARCプロジェクトを担当するITセキュリティスタッフは、組織内の誰かがサードパーティのメールベンダーを使用してショッピングカート放棄メッセージを送信していることを知る。このサードパーティメールベンダーは、別のチームによって購入されたが、組織の標準とポリシーに従ってベンダーのオンボードに失敗した。このベンダーは、この特定の組織に代わって送信する権限がないと判断される。ITセキュリティ担当者は、このような未承認のメッセージが影響を受けることを十分に理解した上で、DMARCポリシーの強化を継続することを決定します。
- DMARCプロジェクトとその進捗状況を社内で共有し、メールが影響を受けていると思われる場合は、同僚が問い合わせることができるようにしましょう。
DMARCのパーセントタグの役割
DMARCレコードのpctタグは任意ですが、徐々にパーセンテージを上げることで、100%のp=隔離またはp=拒否DMARCポリシーを確立する前に、必要なアクションを発見し、対処することができます。pctタグに関する推奨事項は以下のセクションをご覧ください。
DMARCレコードにpctタグを含めない場合、100%がデフォルト値となります。p=noneは、メールフローにアクションを起こさない監視ポリシーであるため、pctタグは不要であり、p=noneと共に使用すべきではありません。
意図的なDMARCポリシーの進行
DMARCポリシーを進めていくプロセスは徐々に進んでいきます。ドメインとメールソースをDMARCに準拠させたら、p=noneからp=quarantine、そしてp=rejectへとポリシーを進めるプロセスを開始することができます。また、オプションのパーセンテージ(pct)タグをうまく利用することで、DMARC展開をより細かくコントロールすることができます。
ドメインとソースをDMARCに準拠させたら、次のようなリスク回避のポリシー進行をお勧めします。
ポリシーを進め、PCTタグを増やす際には、メールの流れに細心の注意を払い、高いDMARCコンプライアンス率を達成・維持していることを確認したいものです。一般的には、ドメインごとのDMARCコンプライアンス率は98%以上が推奨されています。
特定のドメインのDMARCコンプライアンス率を確認するには、Detail Viewerを使用し、該当するドメインのフィルタリングを行うことをお勧めします。注意点として、DMARCコンプライアンスは、SPFまたはDKIMのどちらかをパスおよびアライメントするように設定することで達成されます。個々のSPF-alignmentまたはDKIM-alignmentのスコアは、全体的なDMARCコンプライアンス率ほど重要ではありません。
以下は、DMARCのp=quarantineポリシーが25%の場合の例で、失敗したメールの25%はスパムに移行され、残りの75%はp=noneになります。
受信サーバーは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のDetail Viewerに存在し、隔離または拒否されたメールのレートを追跡して、成功、認証のギャップ、送信パターンを特定するのに役立ちます。
p=quarantineポリシーは、データポイントを収集し、DMARCの展開をテストするのに役立ちますが、100%でp=rejectのポリシーは、ドメイン保護の最も安全な状態であり、認証されていないメッセージがドメインから配信されるのを防ぐことができることを覚えておいてください。DMARCが導入されていない場合でも、メール受信者は適切と思われる処理を行います。DMARCを導入することで、受信者に判断を委ねることなく、あなたがコントロールし、判断することができます。
p=rejectのDMARCポリシーに期待すること
このDMARCエンフォースメントポリシーは、受信者にメールを永久に拒否するよう指示します。多くの場合、5XXシリーズのハードバウンスメッセージが生成され、送信サーバーに通知されます。
拒否されたメッセージを追跡するには、DMARCデータを定期的にチェックし、パターンの変化を発見することをお勧めします。p=rejectポリシーは、お客様のドメインから発信されるシャドーITや悪意のあるメールを含む認証されていないメールからの究極の保護策です。
次のステップDMARCのメンテナンス
DMARCポリシーの実施目標であるp=rejectを達成したら、次のステップは、DMARCコンプライアンスを長期的に管理し、DMARCポリシーの実施に関連する潜在的な問題を最小限に抑えるためのプロセスを確立することです。DMARCプロジェクトのLife after Rejectフェーズでは、計画された変更だけでなく、予期せぬ展開に対する組織の準備に重点を置いています。ここでは、p=rejectに達した後、DMARC Management Platformの助けを借りて注視すべき点をいくつか紹介します。
- SPFレコードの定期的なチェック – SPF Surveyorを使用して、組織に代わってメールを送信することを許可されたIPまたはネットブロックが使用されているかどうかをチェックし、SPFレコードが最新であることを確認します。使用しなくなった、または以前に誤って追加されたベンダーのレコードの内容を確認することは、常に良い習慣です。これは過剰認証と呼ばれ、一般的に受信者に嫌われます。
- SPF変更の承認プロセス – DMARCプロジェクトオーナーの承認なしにSPF変更が行われないようにする。予期せぬ変更が行われた場合に通知するアラートを作成する。
- 定期的なDKIMキーのローテーションの監視 – DKIMキーは定期的にローテーションされるべきである。
- DMARCデータの定期的なチェック – 正規メールの新しい送信元がないか必ずチェックする。また、ベンダーの統合の機会、メール量の変化、特定のベンダーにおけるコンプライ アンスの後退、予期せぬ配信パターンの追跡など、その他の調査を開始することもできます。
- レポーティング – dmarcianを設定して、ドメインの使用と不正使用に関するレポートを送信します。
- 社内インシデント管理 – DMARC関連と疑われるメール配信上の問題が発生した場合、問題と解決策を確認します。DMARCデータをフィルタリングして問題の範囲を把握することで、より詳細な情報を得ることができます。
私たちがお手伝いします
Brandkeeperでは、メールセキュリティの専門家チームによるDMARCの導入から運用サポート及びコンサルテーション行っています。一旦はDMARCの導入をやってみたが運用を断念したお客様、または、導入時点でいくつものハードルであきらめた企業様のサポートも行っています。
お気軽にご連絡ください
