二者が報告関係を結ぶ
ドメイン内のレポート宛先の公開 DMARC ポリシーはドメイン所有者の要求を表します。無関係な宛先に、結果として得られるレポートを受け入れるよう一方的に要求するものではありません。 外部宛先検証 受信者が不本意なレポート対象として選択されるのを防ぎます。受信側はDNSを通じてアクセス許可を公開し、レポート側は外部宛先を使用する前にそのアクセス許可を確認します。
RFC 9990 関連する場合に検証手順を適用します。 組織ドメイン 比較は、集計レポートの外部宛先を示しています。このルールを、From アドレスとレポート アドレスの文字列が異なるかどうかの単純なテストに置き換えないでください。検証を実行する決定を再現できるように、検出されたポリシー ドメイン、宛先ホスト、および組織ドメイン コンテキストを保持する必要があります。 RFC 9990 、セクション 4
所有者名を正しい順序で作成する
レポート URI から宛先ホストを抽出します。 _report を先頭に追加します。 _dmarcに続いて、ポリシーの取得元のドメイン名を先頭に追加し、必要に応じてそのドメインを A ラベルに変換します。結果として得られるDNS所有者は、policy-domain._report という形式になります。 _dmarc.destination-host.問い合わせられるのは、 TXTレコード。構築された名前がDNS制限を超えている場合、肯定的な承認の決定を行うことはできません。
この構築では、ポリシーが取得された実際のドメインを使用します。親が組織のブランドに似ているという理由だけで、よく知られた親を短縮してその名前を付けないでください。同様に、mailto アドレスのローカル部分はDNS所有者名に挿入されません。元の URI と解析された宛先ホストを保存して、レビュー担当者が入力からどのように名前が構築されるかを確認できるようにします。 RFC 9990 、セクション 4
見慣れた文字列を認識するのではなく、応答を検証する
返されたレコードは、タグ値リストとして解析されます。必須のv=DMARC1タグは最初に指定する必要があり、末尾のセミコロンはオプションです。指定された解析テストに失敗したレコードは破棄されます。少なくとも 1 つの適格な記録が残っていると、この手順に基づく外部報告の取り決めが確立されます。空の回答、無関係なTXT値、または 記録 間違ったバージョンの配置では、権限が確立されません。
DMARCバージョン値では大文字と小文字が区別されます。DMARC1 DMARC1必須の値であり、小文字の近似値や新しく作成されたプロトコル バージョンではありません。 DNS名の比較ルールをバージョン値の大文字と小文字の要件と混同しないでください。レビューでは、検証前に詳細を正規化するのではなく、正確な回答バイトと記録境界を保存する必要があります。 RFC 9990 、セクション 4; RFC 9989 、セクション 4.7 および 4.8
オーバーライドと失敗時の動作を尊重する
承認レコードは、手順に基づいてレポート宛先オーバーライドを提供できます。オーバーライド URI は、最初に抽出されたのと同じ宛先ホストを使用する必要があります。この制限により、承認応答が無関係な受信者のチェーンにプロセスをリダイレクトすることが防止されます。確認に別のホストによるオーバーライドが含まれる場合、レポート ジェネレーターは元の URI またはオーバーライド URI へのレポートを生成してはなりません。
検証で承認が確認されない場合は、外部 URI を無視する必要があります。一時的なDNSエラーには独自の対処法があります。受信者は、検証テストを後で繰り返すことができるように、配信を一時的に失敗することを選択できます。その許可は普遍的な再試行保証やテストされた実装の説明ではなく、「MAY」として保持してください。 DNSチェックが成功しても、宛先メールボックスが存在すること、レポート サイズを受け入れること、または目的の顧客ダッシュボードにフィードすることは証明されません。 RFC 9990 、セクション 4
集計レポート要求と失敗レポート要求を区別する
のために 集計レポート、手順は rua に関連付けられています。障害レポートは別途指定されます。 RFC 9991。外部の障害レポートの宛先の場合、そのドキュメントでは、rua が表示される場合は必ず ruf に置き換えた同じ外部検証手順が必要です。集約レポートがフローしているからといって、失敗レポートを自動的に有効になったものとして扱ったり、個別のレポート タイプを認識せずに集約宛先処理をコピーしたりしないでください。
障害レポート その内容は集計概要よりも詳細である可能性があるため、さらなるデータ漏洩の懸念が生じます。正しいDNS認証レコードは、どのデータを誰と、どのような目的で共有するかについての組織の決定に代わるものではありません。この原稿には、実際のレポートを要求、送信、またはアップロードする許可は与えられていません。実際のセットアップは、該当するプライバシー、受信者、および運用上の承認を満たしている必要があります。 RFC 9991セクション 5 および 7
架空の構築と受け入れワークシート
架空のポリシーがblue.example.comから取得され、 mailto:reports@red.example.net.構築された認可所有者はblue.example.com._report._dmarc.red.example.netです。完全な値がv=DMARC1;である仮想のTXT応答。図示されているバージョン優先の要件を満たしています。 DNSクエリは実行されず、この例では、名前に公開されたレコードがあるとは主張していません。
ワークシートには、ポリシー検索結果、検出されたポリシー ドメイン、元のレポート URI、宛先ホスト、組織ドメインの比較、構築された所有者、クエリ タイプ、タイムスタンプ、返された正確なレコード、および解析結果が保持される必要があります。オーバーライド用に別のフィールドを追加し、そのホスト制限を確認します。レビュー担当者は、プロバイダーのスクリーンショットやDNSエディターの短縮表示に依存せずに名前を再構築できる必要があります。
収集には 2 番目の承認セクションを使用します: 対象のアカウント、宛先メールボックス、承認されたレポートの種類、パイプライン所有者。これらのフィールドは、完了した取り込み証拠ではなく、計画された検証ワークフローを説明します。 DNS関係の結果を、受信、解析、テナントの属性、ダッシュボードの表示とは区別してください。コレクション パスの別の部分が未解決のままでも、アクセス許可のチェックは成功する可能性があります。
発行と実装は保留されます
カタログでは、送信元ドメインと宛先ドメインからの正確な認証ルックアップの構築と、その答えの検証が必要です。この草案は架空の構造のみを提供します。実際の回答、元のクエリのトランスクリプト、および受信ドメインの実装は未解決のままです。 DNSレコードは公開されず、メールボックスへのアクセスも、レポートの送信も行われませんでした。
運用ウォークスルーとしてリリースする前に、正確な運用関係に関する承認された証拠を入手し、資格のあるレビュー担当者にポリシー検出コンテキスト、バージョン解析、およびオーバーライド処理を確認してもらいます。ソースの日付を保持し、標準要件とプロバイダー固有のアカウントのオンボーディングを区別します。元の証拠、人間によるレビュー、ソースの適用性、生産ルート、視覚的なアクセシビリティ、所有者の解放を含む 6 つのリリース ゲートはすべて開いたままです。
宛先ドメインまたはポリシー検出ドメインを後で変更すると、必要な承認所有者が変更される可能性があります。古い肯定的なチェックが将来のすべてのレポートアドレスをカバーすると仮定するのではなく、検証するための新しいスコープ付き関係として扱います。有用な結果は、単なるTXT値のコピーではなく、監査可能なアクセス許可チェーンです。