直接配送が成功しただけでは、より厳格な規制を行うには十分な証拠にはなりません。 DMARC ポリシー。転送サービスは送信パスを変更し、メーリング リストは署名されたコンテンツを変更する可能性があります。ビジネスが実際に必要とするルートを表す小さなテスト セットを構築します。認証を配信とは別に評価して、1 つの受信者での例外が普遍的な互換性があるように見えないようにします。
ベースラインを確立する
参考文献: RFC 9989 §4.4, RFC 9989 §5.3.5.
承認された送信者および受信者のアカウントと無害なコンテンツを選択してください。 From ドメインを記録します。 封筒の差出人、IPの送信、 DKIMセレクター そして署名ドメイン。直接配信のコピーと信頼できる受信者の認証結果を保管します。該当するDMARCポリシーを取得し、 アライメント テスト時のモードです。ベースラインがすでにずれている場合は、転送を診断する前にその送信者を修復します。
下 RFC 9989、整列したパス SPF または DKIM 機構はDMARCを満たすことができます。フォワーダーのドメインのSPFパスは、作成者のドメインと自動的に調整されません。 RFC 6376 署名付きコンテンツの保存がDKIMにとって重要である理由を説明します。全体的に緑色の結果を説明として扱うのではなく、どのメカニズムが生き残るかを記録します。
意味のあるバリエーションを練習する
参考文献: RFC 6376 §3.4, RFC 8617 §7.2.1.
未変更の転送、エンベロープの書き換え、リスト フッターの挿入、件名の変更、および実際のサービスが実行するMIME変換が含まれます。複数の正当なメッセージ タイプ、特に添付ファイルまたはサードパーティの送信パスを含むメッセージ タイプをテストします。関連する質問は、変換によって実際の署名の対象となる内容が変更されるかどうかです。 正規化メッセージがクライアントで同一に見えるかどうかではありません。
整列したシグネチャが意図的に無効になっているネガティブ コントロールを隔離された研究室に保管します。有効なケースと無効なケースの両方を受け入れる受信者は、ローカル ポリシーを適用している可能性があります。この観察は役に立ちますが、両方のメッセージが認証されることを証明するものではありません。もし ARC が存在する場合、レコードチェーンの検証、スケーラーと受信者の信頼決定を個別に行います。 RFC 8617 、すべての有効なチェーンを配信コマンドにするわけではありません。 2026 年 11 月 8 日に確認されたように、RFC は実験段階のままであり、アクティブなドラフトでは歴史的ステータスが提案されています。新しいARC依存関係を作成する前に、その提案を検討してください。
再現可能なフィクスチャを読む
参考文献: RFC 6376 §6.
保持されたラボは、一時的な RSA キーを使用して 1 つの無害な author.test メッセージに署名し、dkimpy で検証します。直接のケースは合格します。変更されていない転送コピーは引き続き検証されます。 SRS スタイルのエンベロープ変更により、簡素化されたSPF ID が forwarder.test になり、整合していませんが、 DKIM有効なままになります。署名された本文に追加されたフッターは検証に失敗し、正確なドメインのDMARCモデルに失敗します。
各ケースには、メッセージ ダイジェスト、ルート IP、エンベロープ ID、署名ドメイン、および判定が保持されます。検証キーは公開されています。秘密キーは保持されません。元のキー生成フィクスチャを再実行すると、新しいキーが作成され、したがって新しいメッセージ ハッシュが作成されます。ここでは再放送されていませんでした。予想される判決は依然として安定している。これは再現可能なローカル テストであり、完全なSPFリゾルバー、 DMARC実装、 ARC検証ツール、または商用メールボックス プロバイダーのテストではありません。
続行するかどうかを決定する
参考文献: RFC 9989 §8.
テストされた送信者、仲介者、受信者、メッセージのバリアント、認証結果、および最終的な処理を示すルート マトリックスを作成します。テストされていない組み合わせを不明としてマークします。サンプル マトリックスには、事後的に選択された成功したメッセージだけでなく、直接制御と失敗した変更も含める必要があります。ラボのフッターの障害は、そのルートを修復または別途承認された例外として保留する理由になります。
指定されたロールバック権限を備えた制御されたロールアウトと、プロバイダーのレポート遅延に応じた適切な監視を使用します。過去のパーセンテージ ポリシー レシピが現在のDMARC仕様に引き続き適用されると想定しないでください。現在の受信者とプラットフォームの動作を確認し、前後のポリシーとメッセージの証拠を保存します。ポリシーの変更は、 DNSチェッカーがより厳密な値を確認した場合だけでなく、正規の重要なルートが引き続き機能し、組織が残りの障害を理解している場合に成功します。
制御された転送ルートの保持
参考文献: RFC 7208 §4, RFC 6376 §6, RFC 8601 §5.
保持されている 2026 年 11 月 7 日の21:32:53 UTC のキャプチャには、実際のループバックSMTP接続を通じて署名付きメッセージを送信する別のフィクスチャが記録されています。これらのネットワーク セッションは検査されたものであり、このレビューのために再実行されたものではありません。オリジンは127.0.0.2にバインドし、フォワーダーは127.0.0.3から送信し、最終受信者は各メッセージを保存します。これらのアドレスはローカル マシンに限定されます。直接、変更なし、転送、書き換えられたエンベロープおよびフッターのケースにはそれぞれ、タイムスタンプ、エンベロープ ID、および最終的な受け入れを含む実際のトランザクション追跡があります。この書き換えは、このラボ用の SRS スタイルのドメイン置換であり、完全な書き換えではありません。 SRS 実装。
各受信境界は、明示的に挿入されたローカルTXT応答を使用して pyspf 2.0.14 を使用してSPF計算し、保持された公開キーを使用して dkimpy を使用してDKIM計算します。受信者は独自のを追加します Authentication-Results および評価後に受信したフィールド。これらの結果は、挿入コードと境界がわかっている、この制御されたフィクスチャ内でのみ信頼されます。任意の埋め込みパス テキストを独自の判定として受け入れません。 DNSポリシーは静的なローカル入力であり、パブリックDNSに関する要求ではありません。
最終受信側では、 SPF結果はそれぞれ合格、不合格、合格、合格となります。 DKIM結果は、合格、合格、合格、不合格です。したがって、正確なドメイン アライメント モデルは、最初の 3 つのケースではDMARC認証を保持し、フッターのケースでは失敗します。これは完全なDMARCポリシー検出ではありません。ラボでは、検査のために失敗したメッセージさえも意図的に保存しているため、その 250 応答は、強制的な運用プロバイダーがそのメッセージを配信するという証拠にはなりません。
例外の例とロールアウト ホールドは、その履歴フッター ルートに関連付けられています。変更されていないルートは署名を保持しますが、制御された仲介者のフッターは署名を破ります。実際の範囲、所有者、有効期限、および受信者の動作がレビューされるまで、許可は未承認のままにしておきます。これらの履歴管理トランザクションは、ローカル ルートの比較を文書化します。運用メールボックスとプロバイダーの互換性、実際のビジネス フローの承認、および操作上の例外の承認は実行されないままになります。