DMARCbis準備: DNS変更する前に確認すべきこと

DMARCbis の部分がどのように変化するか DMARC が指定され実装されています。レコードの名前を DMARC2 に変更するように要求されることはありません。コア仕様は、 RFC 9989は2026年5月に出版されましたが、 RFC 9990 そして RFC 9991 集計レポートと障害レポートを個別に扱います。

実際の作業は、どの変更がドメイン、送信サービス、認証データを処理するソフトウェアに影響を与えるかを解明することです。まず現在の仕様を理解し、それをすでに使用されている構成やプロセスと比較します。その結果、証拠、所有者、各発見事項に対する決定を含む明確な準備記録が得られるはずです。

3 つの仕様をシステムにマッピングする

それぞれのジョブに現在のドキュメントを使用します。

既存のレコードと構成履歴から始めます。古いガイドに引用されているという理由だけで操作記録を削除しないでください。 RFC 7489。変更された命令とそれを実装するソフトウェアを特定します。

主なレビュー分野には次のようなものがあります。

• ドメインの検出: RFC 9989セクション 4.10 DNSツリー ウォーキングを定義します。古いパブリックサフィックスリスト検出モデルを前提とするシステムを検討します。
• ポリシータグ: 現在のIANAレジストリを確認してください。の パーセント, RF そして リ タグは歴史的なものです。評価 t, NP そして psd アップグレード チェックリストとして追加するのではなく、実際の範囲によって。
• テスト: 関連する評価者がバイナリを実装する方法を確立する t 信号。宣言されたテスト状態と受信者の最終的な性質は異なる観察です。
• 報告： 関連する従来の観察結果を失うことなく、コレクターとパーサーが、受信すると予想されるレポート形式とフィールドを処理していることを確認します。

バージョンマーカーは残ります v=DMARC1。代用しないでください DMARC2 または、古いパーセンテージをテスト フラグに機械的に置き換えます。

変更されたタグをテストに変換する

の t フラグのデフォルトは n、宣言された評価をDMARC障害に適用することを要求します。設定 t=y これは、所有者が宣言された評価を直接適用することを要求するのではなく、テストしていることを示します。 RFC 9989セクション 4.7 失敗したメッセージに対する 1 レベルの削減を定義します。拒否は隔離になり、隔離はなしになります。実装には、関連する特別な処理がある場合もあります。

このフラグは、失敗した認証結果を合格に変更したり、レポート生成を変更したり、none ポリシーに影響を与えたりすることはありません。これはバイナリであり、メールの任意の割合をサンプリングする要求ではありません。実際のトラフィックに依存する前に実装サポートを確立し、受信側ローカル フィルタリングをポリシー レベルのテスト結果から切り離してください。

他の 2 つのタグは評価の範囲に影響します。

• NP: 一般的なドメインの存在しないサブドメインの評価を指定します。 組織ドメイン。存在しない場合、該当するフォールバックは、存在する場合は sp、それ以外の場合は p です。行方不明 MXレコード それだけでは非存在を確立するものではありません。
• psd: 検出中に使用されるドメイン境界情報をマークします。デフォルトの u では、境界の決定は検出ルールに委ねられます。 y はパブリック サフィックスを識別し、n はそれ自体とそのサブドメインの非パブリック サフィックスの組織境界を識別します。どちらの明示的な境界値も、ドメインを正しく記述することを確認するまでは設定しないでください。

通常の組織は、準備が整っていると主張するためだけに、そのドメインをパブリック サフィックスとしてラベル付けするべきではありません。実際の検出の前提条件と委任された名前空間を確認します。の サブドメインポリシーガイド より狭い継承の問題をカバーします。

動作し続ける必要があるメールを特定する

ドメインは従業員の電子メール以上のものを表す場合があります。これは、請求書、ログイン リンク、顧客への警告、外部機関から送信されるメッセージに表示されることがあります。標準の更新は、急いで構成を変更して依存関係が中断される前に、依存関係を確認する機会となります。

あなたの ID を使用するサービスの一覧表、あなたに影響を与える具体的な変更の説明、重要なメッセージのテスト計画の 3 つの成果物を求めます。答えは、公開された仕様と、特定の受信機またはソフトウェア サービスによってすでに展開されている機能を区別する必要があります。

予算だけでなく所有権も割り当てます。レポート処理の変更には、レポート パイプラインの責任者が必要です。送信者が正しく認証できない場合は、ビジネス オーナーの関与が必要です。両方の項目をDNSアップグレードと呼ぶと、作業が隠蔽されます。

準備登録簿を作成する

以下は計画登録の例であり、実際のドメインの評価ではありません。

次の合成フィクスチャはRFC 9989を実装する制御されたエバリュエーターに対して期待される結果を指定します。これらはテスト入力であり、運用記録テンプレートやすでに実行されたテストではありません。有効な適用可能なポリシーが検出され、テスト メッセージがDMARCに失敗したとします。

評価者のバージョン、入力、観察された検証、選択された評価、および最終処理を個別に取得します。制御されたフィクスチャは、テストされた動作を確立します。すべてのインターネット受信者が同じルールを実装していることを証明するものではありません。ポリシーレベルの隔離観察は、スパムフォルダーの配置を普遍的に約束するものではありません。

ポリシーの適合性も確認します。 RFC 9989セクション 7.4 メーリング リストを含む正規の間接ルートが破損する可能性があるため、汎用電子メール ドメインを拒否しないことをお勧めします。準備状況のレビューでは、より強力なポリシーを提案する前に、これらのルートを特定し、適用される相互運用性のガイダンスを評価する必要があります。

構成の変更は、ソフトウェアまたはプロセスの変更とは別にしてください。検出結果によっては、すぐにDNS編集する必要がないものもあります。その他には、プロバイダーの更新、パーサーの修正、または制御された実装テストが必要です。

相互運用性と Readiness Claim の制限を確認する

Readiness Claim では、その範囲を指定する必要があります。ドメイン ポートフォリオ、ポリシー評価者、レポート プロセッサのみを対象としていますか? 記録 チェック？これらは異なる評価です。

レジスタを使用して、実装バージョンと未解決の相違点を追跡します。既存および存在しないサブドメイン、アライメント モード、間接メール、 DNS障害から該当するケースを選択します。

受信者の裁量を運用モデルの一部として扱います。仕様が公開されたからといって、すべての受信機が同じように動作するわけではありません。公開された拒否設定は、すべての受信者が失敗したすべてのメッセージを拒否したという証拠でもありません。

侵害されたアカウント、虚偽の表示名、類似ドメイン、機密性の高いビジネス承認に対して独立した制御を維持します。 DMARC対応は、ドメイン認証をメッセージのコンテンツの安全性の判断に変えるものではありません。

必要な変更を加えて確認する

運用を変更する前に、以前の状態を保存し、影響を受けるフローを特定し、適切な承認を得て、回復条件を定義します。次に、公開された設定と代表的なメッセージの両方を、完全な送信ルートを通じて検証します。

結果が予期した動作と一致しない場合は、他のドメインへの拡張を一時停止し、互換性の検出結果を解決するか明示的に受け入れます。

基礎となる ID については、 アライメント診断ガイド。初期設定については、次のとおりです DMARC作成と検証のワークフロー。レポート層の場合は、次を使用します。 集計レポートのウォークスルー.

実践的なポイント

該当する各所見に所有者、裏付けられた決定、および再現可能な証拠がある場合、評価を終了します。未解決の実装の相違点を常に表示し、重要なメッセージとレポート処理を検証し、承認された回復条件を保持します。準備ラベルは、そのレコードを置き換えるのではなく、そのレコードを指す必要があります。