2 番目を追加する DMARC ポリシーは最初のポリシーを更新する方法ではありません。 2 つの値は結合された命令にはならず、 DNSそれらに対して順序付けされた「最新のポリシーが優先」ルールを提供しません。
修理は完全な状態から始まります TXTレコード 影響を受ける名前に設定されます。現在のバージョンのポリシー候補がいくつ存在するかを特定し、その境界を表示形式から区別し、編集前に所有者の意図したポリシーを調整します。
正確なDNS所有者を検査する
メッセージの差出人アドレスのドメインから開始します。該当する_dmarc名をクエリし、信頼できる関連性のある再帰的回答をタイムスタンプ付きで記録します。
ルート ドメイン ポリシーと明示的なサブドメイン ポリシーは、異なる名前で発行されます。両方が存在するというだけの理由で、それらは重複ではありません。彼らの関係は発見と範囲によって決まります。 サブドメイン ポリシー ガイド その関係を評価する方法を説明します。
同様に、ドメイン ルートのポリシーTXT 、関連する_dmarc名の代わりにはなりません。複数の場所にレコードを追加して、受信者が 1 つを選択することを期待するのではなく、対象の所有者を修復します。
レコードを文字列から区別する
1 つのTXTリソース レコードに複数の文字列を含めることができます。 DMARC 、これらの文字列を順番に連結してから解析します。 RFC 9989 §4.5。文字列の周囲に表示される引用符は、通常、検索ツールの表現です。
この合成ゾーン スタイルのフィクスチャは 1 つのTXTレコードです。
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; " "rua=mailto:reports@example.com"連結された値には、p タグと rua タグの間に区切り文字とスペースが含まれています。これは、これらの文字が文字列内に含まれているためです。リゾルバーは、それらを結合するときに欠落しているセパレーターを作成しません。
対照的に、2 つの別個のTXTリソース レコードは 2 つのレコードです。これらをスプレッドシートやインシデントノートに連結して、その発明された価値を分析しないでください。
ポリシー候補をカウントする前にフィルタリングする
の RFC 9989 §4.10 DNSツリーウォーク 現在のバージョンを識別する v タグで始まらないレコードを破棄します。複数のDMARCポリシー レコードが 1 つのターゲットで返された場合、そのターゲットではすべての DMARC ポリシー レコードが破棄されます。
したがって、同じ名前の無関係なTXT値は、自動的に 2 番目のDMARCポリシーにはなりません。元の各レコードを保存し、定義されたフィルタリングを適用した後、関連する候補をカウントします。
以下は合成フィクスチャであり、ライブ ルックアップ結果ではありません。
- 1 つのターゲットに設定されたレコード: 1 つの現行バージョンのDMARC候補。調査する解釈: その候補とそのポリシーのセマンティクスを解析します
- 1 つのターゲットに設定されたレコード: 1 つのDMARC候補と無関係な記述TXT 。調査すべき解釈: 無関係なTXTは 2 番目のDMARCポリシー候補ではありません
- 1 つのターゲットに設定されたレコード: v=DMARC1;調査すべき解釈: 競合する政策候補。マージや最終レコードの選択はありません
- 1 つのターゲットに設定されたレコード: 2 つの文字列からなる 1 つのレコード。調査する解釈: 文字列を順番に連結してから解析する
下 RFC 9989 §4.7の場合、バージョン タグは正確な値DMARC1で最初に出現する必要があります。後でそのテキストに言及するだけの文字列は、定義されたレコード ID の代わりにはなりません。
1 つのエラー ラベルを約束するのではなく、結果を追跡する
最初の検索時に複数のポリシー候補がその名前に有効なポリシーを残さない可能性があります。下 RFC 9989 §4.10.1、現在の検出は、該当するDNSツリー ウォークを通じて続行される場合があります。他の場所で見つかった使用可能なポリシーがメッセージに影響を与える可能性があります。
たとえば、架空のサブドメイン フィクスチャでは、 _dmarc.alerts.example.comにある 2 つの候補が破棄されます。その後、ディスカバリーによって該当する有効なポリシーが見つかった場合、 組織ドメイン、そのポリシーが適用される可能性があります。完全な検出で何も見つからなかった場合、 DMARCメッセージに適用されません。
すべての重複が同じものを生成することを約束しないでください Authentication-Results 実装間でのラベルまたはSMTP応答。受信者の実際の結果とその適用可能な検出パスを保存します。
DNS変更する前に、承認された 1 つのポリシーを調整します
どの値が意図的なものであるかを判断します。 2 つのレコードは、異なるチーム、古いレポート統合、またはデータを置き換えるのではなく追加した移行によって作成された可能性があります。
1 つの一貫した承認済みの価値を構築します。意図したレポートの宛先を保存して確認する アライメント、サブドメインのスコープとテスト設定。複数の集約受信者が承認されている場合は、次のように定義されたカンマ区切りの rua 宛先リストが使用されます。 RFC 9989 §4.7 1 つのポリシーでそのリクエストを表現できます。複数のポリシーTXTレコードは必要ありません。
必要な外部レポート権限を個別に確認します。 RFC 9990 §4。宛先アドレスを結合しても、制御できない宛先にはアクセス許可が付与されません。
修正を行って確認する
前の状態、完全に承認された後の状態、所有者名、TTL を保存し、承認を変更します。競合する候補を、その名前の目的の単一ポリシーに置き換えます。
次に、権限のあるサーバーで新しいレコード セットを確認し、関連する再帰ビューを調べます。キャッシュされた以前の値はしばらく残る可能性があるため、現在の 1 つの信頼できる回答は、すべての受信者が古いセットを破棄したという証拠ではありません。
代表的なメッセージ テストを実行し、その信頼できる認証とポリシーの結果を検査します。 DNS修正により、有効な構成の依存関係が確立されます。無関係にはならない DKIM署名 アプリケーションのエンベロープ ID を調整または修正します。
使用 記録のワークフロー パブリケーションとメッセージ検証を接続します。
次回の統合時に同じ競合が発生しないようにする
ドメインにポリシー所有者を与え、別のポリシーをやみくもに追加するのではなく、既存のレコードとの差分を提案する統合を要求します。各報告先のビジネス目的とライフサイクルを保持します。
有用な移行ハンドオフでは、誰が古い構成を削除し、誰が結果のレコード セットを検証するかを指定します。永続的な修正は、検出、レポート、および実際のメールの動作が理解された、関連する名前ごとに 1 つの意図的なポリシーです。
決定と証拠を分けて保管する
分割文字列フィクスチャの場合、最初の文字列はセミコロンとスペースで終わるため、これを rua で結合すると 1 つの一貫した値が得られます。表示順序に関係なく、2 つの別々のレコードが 2 つの候補のままになります。完全な検出結果を単一名の欠陥とは区別してください。 RFC 8767 §4 また、TTL の有効期限は、キャッシュされたデータのグローバルな削除期限として保証されていないことも意味します。フィクスチャは公開またはクエリされませんでした。