いくつかのメッセージ DKIM 署名には署名ごとの評価が必要です。署名を数えたり、最初に合格した結果を選択したりすると、表示されている作成者を認証したドメインを誤って識別する可能性があります。下 RFC 9989 §4.4.1、作成者ドメインと一致する、渡された DKIM 認証された識別子は、次のDKIMパスを提供できます。 DMARC 合格。
各結果の同一性を保持する
承認されたプロセスを通じて生のメッセージをエクスポートします。表示されている From ドメインと、署名ごとにそのドメインを記録します。 d= 署名ドメイン、 s= セレクタ, a= アルゴリズムと関連する 正規化 設定。信頼できる受信システムの結果をその署名に関連付けます。 2 つの署名は同じドメインを使用できますが、異なるセレクターまたはアルゴリズムを使用するため、ドメインだけではそれらを区別できない場合があります。
恣意的なものを信用してはいけない Authentication-Results このフィールドは、単にメッセージ内に表示されるという理由だけで使用されます。 RFC 8601 §1.2 これらのフィールドの信頼境界について説明します。評価を調査している受信システムに起因する結果を使用し、証拠をエクスポートするときにそのソースを保存します。送信者は誤解を招くヘッダー テキストを挿入する可能性があります。コピーされたステータス ラベルは独立した検証ではありません。
検証と調整は別個の決定として行う
検証により、署名がその署名ドメインに対して検証されるかどうかが確立されます。 位置合わせ 該当するDMARCルールに基づいて、認証されたドメインと作成者ドメインを比較します。無関係なプロバイダーの署名は、作成者のDMARCの可視ドメインを認証しなくても、完全に有効である可能性があります。
DKIM厳密に調整するには、ドメイン名の大文字と小文字を以下のように比較して、ドメインが正確に一致する必要があります。 RFC 1035 §2.3.3。緩和された調整では、該当するDMARCプロセスによって決定される組織とドメインの関係が使用されます。 RFC 9989 §4.10.2 この決定のためにDNSツリー ウォークを定義します。 2 つのドメイン名の一般的な単語から配置を決定しないでください。また、すべての受信者が最新の検出実装を採用していると黙って仮定しないでください。
合成メッセージを処理する
有効な適用可能なDMARCポリシー、作成者ドメインが example.com そして整列していない SPF 合格。署名 A が使用するもの d=example.net、検証は成功しましたが、一致しません。署名 B は使用します d=example.com しかし、ダウンストリームのコンテンツ変更後の検証は失敗します。どちらも調整された受け渡しDKIM ID を提供しないため、この組み合わせではDMARCパスは生成されません。
ここで署名 C を追加します d=example.com それは正常に検証されます。正確に位置合わせされるため、 DMARCパスにDKIMパスが提供されます。無関係な合格および不合格の署名は C を自動的にキャンセルしません。これは例示的な評価であり、キャプチャされた顧客メッセージやメールボックスの配置の保証についての主張ではありません。
この例を、調査記録の別の列 (署名識別子、検証結果、調整結果、およびDMARCへの貢献) に書き込みます。署名 A のパスと署名 B の整列されたドメインを組み合わせて、個々の署名が達成されなかった結果を作成しないでください。
複数の署名がある理由を説明する
並列アルゴリズム、プロバイダーの運用署名、および仲介者のその後の署名はすべて、複数の結果を作成する可能性があります。これらは、ルートと署名者の構成によって理由が確立されるまでの仮説です。 RFC 8463 §6 RSA の個別のセレクターについて説明し、 Ed25519 移行署名。結果は個別に追跡する必要があります。
ゲートウェイが変更されたメールに再署名する場合は、その新しいドメインを検査します。ゲートウェイ署名を通過しても、元の作成者の認証は自動的に修復されません。組織が最終署名段階を管理している場合は、承認された ID で意図した後処理コンテンツに署名していることを確認します。運用上の目的を確認せずに、明らかに冗長な署名を削除しないでください。
メッセージレベルの結論で終わります
関連するすべてのDKIM署名を評価した後、 SPFの認証された識別子とアラインメントを個別に評価します。該当するDMARCポリシーが見つからない場合は、その状況を通常のDMARC障害として再分類しないでください。追加のポリシーまたはフィルタリングを反映する可能性がある、受信者の最終的な性質から認証結果を区別します。
元のメッセージ、信頼できる検索先、署名ごとの分析、および最終結論の理由を保持します。レポートツールが異なる方法で署名を集計する場合は、異なる要約をプロトコルの矛盾として扱う前に、生の証拠を比較してください。有用な結果は、単に多数の緑の指標ではなく、説明可能なアイデンティティ パスです。
ID を混在させずに例を記録します
上記の合成メッセージの場合、署名ごとに 1 行を保持します。
- A: example.net ;検証パス。アライメント番号。 DMARCへのDKIM貢献
- B: example.com ;検証は失敗します。ドメインは一致しますが、認証されていません。 DKIM貢献No.
- C: example.com ;検証パス。アライメントはい。 DKIM貢献はあります。
C が存在する前は、整列したSPFが存在しないと述べられているため、パス パスが残されません。 C が存在する場合、 DMARC想定される適用可能なポリシーの下に合格します。実際の受信者の結果や受信箱への配置結果は要求されません。
関連書籍
DKIMアラインメント: d= を表示されている From ドメインと比較します。 · RSA および Ed25519 DKIM署名: 導入に関する質問と相互運用性.