[ DMARCとポリシー ]

DMARC隔離と拒否: 影響を受ける可能性のあるメールを評価する

要求されたDMARC障害の処理を、正当なルートの証拠、受信者の裁量、誤った決定の影響と比較します。

EmailAuth研究チームによる · 5 分で読めます

【ポイント】

  • 要求されたポリシーと実際の処理は別の事実です。
  • ポリシーを変更する前に、少量の重大な障害を調査します。
  • ルートレベルの証拠、例外、回復条件を保持します。
このページでは

隔離と拒否は、失敗したメールに対するさまざまなドメイン所有者の評価を伝達します。 DMARC。どちらかを選択するには、ドメインの正当なメッセージと、それらのメッセージが誤って処理された場合の結果に関する証拠が必要です。

この決定を制御された変更として扱います。どのフローが失敗する可能性があるか、失敗する理由、受信システムが実際に何を行うかを特定します。より制限的なように見える記録は、その調査の代わりにはなりません。

評価と取り扱いを分けてください

下 RFC 9989 §5.3.5、 DMARC合格かどうかを評価します。 SPF または DKIM ID は、表示されている From ドメインと一致します。ポリシーは、検証が失敗した場合のドメイン所有者の評価を表します。

下 RFC 9989 §4.7、検疫は失敗した使用を疑わしいものとして分類します。拒否は、失敗した使用は無効であるとの評価を表します。下 RFC 9989 §5.4、受信者は自身の処分決定に対する責任を保持し、他の情報を使用することができます。

したがって、隔離は 1 つの普遍的なスパム フォルダー結果を保証するものではなく、拒否は、参加しているすべての受信者がすべての失敗を拒否したことを証明するものではありません。捜査中の事件に関して実際に受け取った証拠を確認します。

まず正当な障害を調査する

承認されたアプリケーションの場合は、表示されている From ドメインをSPF ID および関連するすべてのDKIM署名ドメインと比較します。サポートされている構成を確立し、同じルートを介して新しいメッセージをテストします。

ポリシーの変更によって障害が明らかになったという理由だけで、広範囲の送信許可を追加しないでください。まず、企業が実際にどのアカウント、ワークフロー、アイデンティティを承認したかを判断します。

転送リストとメーリング リストは、存続する認証パスに影響を与える可能性があります。間接的な障害の場合は、ソース ドメインの別のインクルードではなく、メッセージの変更と受信動作の分析が必要になる場合があります。 SPFレコード.

ドメインの目的を使用してトレードオフを評価する

専用のトランザクション ID では、スタッフ通信ドメインよりも送信人口を少なく、より制御することができます。それぞれを適宜確認してください。

RFC 9989 §7.4 汎用電子メール ドメインの拒否について警告し、ユーザーがインターネット メーリング リストに投稿するドメインについて説明します。その状況の観察と比較のガイダンス、およびユーザー参加への影響を示します。

隔離を自動的に拒否される旅行における強制的な待合室として扱うのではなく、関連するガイダンスを適用してください。の 政策選択ガイド より広範な決定記録を示します。

全体的な割合だけでなく、具体的な失敗を確認する

従業員のメッセージは通過するが、毎月の請求書システムが失敗するという合成例を考えてみましょう。 アライメント。請求書ストリームは全体の料金にほとんど影響を与えないほど小さいです。

受信者がそれらの障害に対処する場合、要求されたポリシーが強力であっても、ビジネスに重大な影響を与える可能性があります。請求書サービスを特定し、サポートされている ID を修正して、実際のワークフローをテストします。

不明な障害トラフィックには別の調査が必要です。証拠が正当なメール、間接ルート、不正使用、または別の原因を表しているかどうかを証明するまで、不確実性を保ってください。すべての未知の行を、防止された攻撃としてカウントしないでください。

変更とその受け入れの証拠を計画する

現在のポリシーを保存し、提案されたスコープを定義します。テストしたサービス、残りの例外、およびエスカレーションまたは復元が必要な条件を記録します。

変更が承認された後、権限のある記録と代表者が受信したメッセージを確認します。レポートの観察結果を、レポート間隔とポリシーのコンテキストとともに調べます。ポリシー変更レポートについては、 RFC 9990 §3.3。現在のDNS 、受信者が以前に見たポリシーを再構築しません。

認証、処理、ビジネスへの影響については個別の証拠を使用します。下 RFC 9990 §3.1.6、レポートの処理およびオーバーライドの理由は便利なコンテキストですが、最終的な受信トレイの配置や、支払いや通知のワークフローの結果を証明するものではありません。

決定後の運用プロセスを維持する

新しいアプリケーション、変更されたルート、および古い権限の監視を継続します。組織がドメインの使用方法を変更すると、有効なポリシー決定が不適切になる可能性があります。

有意義な結果は、検証された正当なフロー、理解された制限、および回復プロセスによってサポートされる文書化された選択です。メッセージレベルの診断には、 アライメントガイド;証拠の解釈には、を使用します DMARC集計レポート.

決定とその限界を記録する

単なる計画例として、9,900 件の従業員メッセージが成功し、100 件の請求書メッセージが失敗したと仮定します。合計の合格率は 99% ですが、請求書ルートの失敗率は 100% です。これらの発明されたカウントは、重要なルートの修復が必要な理由を示しています。これらはキャンペーンの測定値でも、約束された政策の成果でもありません。

[ 取り除く ]

要求されたポリシーと実際の処理は別の事実です。ポリシーを変更する前に、少量の重大な障害を調査します。ルートレベルの証拠、例外、回復条件を保持します。

【役割別】

これがあなたにとって何を意味するか

実際の次のステップに向けて、自分の役割を選択してください。

IT / メール管理者

前後の証拠を保管してください。

複数のコントロールを一度に変更するのではなく、調整、ポリシー検出、実際の受信者の結果を通じて、影響を受ける送信者を追跡します。

次のステップ

  1. 正当なアイデンティティのギャップを修正します。
  2. 有効なポリシーと報告期間を記録します。
  3. 修正後の元の営業ルートを確認します。

CISO / SecOps

適合性と残留リスクを承認します。

ドメイン固有の正当化を要求し、ポリシーの値だけで普遍的な強制または安全性が確立されるという異議申し立てを主張します。

次のステップ

  1. 汎用およびメーリングリストの使用を検討します。
  2. 例外とリカバリの所有権を確認します。
  3. アカウントとトランザクションの独立した管理を維持します。

創業者 / 非技術系

正当なメッセージが誤って処理された場合に何が起こるかを尋ねてください。

誤った決定によるコストは、単にメッセージ量だけではなく、影響を受けるワークフローによって異なります。

次のステップ

  1. 顧客アクセスと財務コミュニケーションを優先します。
  2. 定期的なフローがテストされたかどうかを尋ねます。
  3. 変更前にエスカレーションの所有者に同意してください。

[ よくある質問 ]

よくある質問

検疫は、失敗したすべてのメッセージがスパムに分類されることを保証しますか?

いいえ。これは、失敗したメールに対する所有者の評価を伝えますが、受信システムは独自の処理とフィルタリングの決定を適用します。

RFC 9989 §4.7 RFC 9989 §5.4

拒否するとフィッシングに対する完全な保護が保証されますか?

いいえ。受信者の動作はさまざまであり、ドメイン認証は、すべての類似したアカウント、侵害されたアカウント、欺瞞的な表示名、または安全でないビジネス リクエストをすべてカバーするわけではありません。

RFC 9989 §5.4

隔離を拒否するように変更すると調整が修正されますか?

いいえ。サポートされている送信 ID を修復し、新しいメッセージで調整されたパスの受け渡しを確認します。ポリシーと認証は別のレイヤーです。

RFC 9989 §5.3.5

すべての監視対象ドメインを拒否するために検疫を通過する必要がありますか?

普遍的な進行は適切ではありません。ドメインの目的、正当なフロー、および現在の相互運用性のガイダンスによって評価が決まります。

RFC 9989 §7.4

合格率が高いのに、小さな失敗したサービスがなぜ問題になるのでしょうか?

ボリュームは重要性を隠す可能性があります。健全な従業員のメールが分母を占めている場合でも、少量の請求書またはアクセス回復ストリームが重要になる可能性があります。

ポリシーの変更を承認する前に何が必要ですか?

定義された範囲、クリティカル ルート テスト、評価された間接メール、所有する例外、レポート制限、承認者、および回復条件が必要です。

レポートは受信トレイの最終的な結果を証明できますか?

その性質フィールドだけではありません。認証、調整された評価、コンテキストの処理を個別に読み取り、必要に応じて受信者またはサービスの証拠を取得します。

RFC 9990 §3.1.6 RFC 9989 §5.4

政策決定後は何を継続すべきでしょうか?

新規または変更されたサービスのレポート作成、送信者の所有権、およびレビューを維持します。ドメインの正当な使用または関連する受信者の動作が変化したときを再評価します。

[ 情報源 ]

情報源

  1. RFC 9989

    セクション §4.7 · §5.3.5 · §5.4 · §7.4

  2. RFC 9990

    セクション §3.1.6 · §3.3

[ 用語集 ]

用語集

配置
報告された処理およびオーバーライドの説明は、認証結果およびビジネス結果から区別する必要があります。

RFC 9990 §3.1.6

クリティカルルート
メッセージ量が少ない場合でも、失敗がビジネスにとって重要なワークフロー。

企業の来歴

一流の金融機関と政府が選ばれる理由 電子メール セキュリティ ダッシュボードを廃止しました。

従来の電子メール認証プラットフォームはダッシュボードを販売し、エンジニアに作業を依頼します。一か八かの環境では、手動による監視は適用の遅れ、構成のドリフト、および監視されていないシャドウ ドメインを意味します。

EmailAuthは、エージェントの電子メール来歴プラットフォームです。 当社のエージェントが執行します p=reject、サードパーティの送信者を調整し、ドメインを完全に移動します。 RFC 9989 新しいDMARC標準に準拠し、人間による監査機能を備えています。

政府 大企業 ティア1金融機関

SaaS · 専用テナント · エアギャップオンプレミス · BYOK 暗号化

ナレッジベース