プロトコルを受信者の適格性から分離する
BIMI 単語を見つけたからといって資格が確立されるわけではありません DMARC DNSレコード内。オペレータは、ロゴを表示する前に、該当する認証ポリシー、実際のメッセージが必要なチェックに合格するかどうか、対象の受信者が現在何を要求しているかを判断する必要があります。これらは関連していますが、別個の質問です。現在のプロトコル仕様とプロバイダーの運用ヘルプ ページでは、用語や移行のタイミングが異なる場合があるため、証拠には日付と明示的な範囲が必要です。
この記事では、保存されている一次資料を比較します。 Google の設定ページは 10 月 26 日に更新されました。 YahooのBIMIページは、同等の表示される改訂日なしで取得されました。 RFC 9989 現在のDMARCプロトコル コンテキストを提供します。この記事では、テナントをテストしたり、プロバイダーが新しい RFC のあらゆる側面を実装していると推測したりすることはありません。 BIMIまだ草稿のままであり、受信機のディスプレイは普遍的なプロトコルを保証するものではありません。
Google が公表している実際の状況を記録する
Google のBIMI設定ページには、メッセージはDMARCとリストによって認証される必要があると記載されています p=quarantine または p=reject、 pct=100.また、 VMC または CMC 文書化された証明書に基づくワークフローのためのものであり、 Gmailでのスタンドアロンの SVG のみの展開はサポートされていません。これらの記述は、 DMARCの完全な定義や特定のメッセージ結果の証明としてではなく、Google が公開した資格に関するガイダンスとして記録してください。 Google のセットアップ要件
その SVG 要件とホスティング手順により、追加のゲートが形成されます。適切なDMARCポリシーは、無効なイメージを適切にしたり、証明書を取得したり、PEM をパブリックにアクセスしたりすることはありません。逆に、有効な証明書は、失敗した送信者の調整された認証を修復しません。別々の行を含むチェックリストを使用して、チームが DNS ポリシーの行だけを完了した後に誤ってプロジェクト全体を準備完了としてマークすることがないようにしてください。
PCT の不一致を隠すのではなく表面化する
RFC 9989 、以前のDMARC仕様が廃止され、pct タグが削除されました。その付録では、歴史的なパーセンテージのメカニズムについて説明し、y 値と n 値を使用したテスト タグ t を紹介します。これはプロトコルの重要な変更ですが、保存されている Google BIMIページには依然としてpct=100.どちらかのソースを黙って書き換えて同一に見えるようにするのではなく、両方の観察を保存する必要があります。 RFC 9989 、付録 A.6
運用上の対応としては、不一致に基づいて運用ポリシーを変更する前に、現在の受信機の適用性を確認することです。現在の証拠がその動作を証明しない限り、Google が特定のタグを無視したり、通信で要求したり、内部翻訳したりしていると主張しないでください。 RFC がそれらの歴史的関係を説明しているというだけの理由で、t を普遍的に証明されたBIMI適格性の pct の代替物として扱わないでください。プロバイダーの実装とプロバイダーのドキュメントは、異なるスケジュールで進化する可能性があります。
したがって、ソース適用性レコードには、RFC バージョン、プロバイダー ページの日付、正確な争点、および未解決の質問が含まれている必要があります。責任あるレビュー担当者に、現在のプロバイダーの証拠、または承認された適切な範囲の観察を使用して問題を解決するよう依頼してください。この記事ではその確認は行っておりません。競合はゲートの理由であり、施行を弱めたり互換性を主張したりする理由ではありません。
Yahooの提示条件を個別に比較する
Yahoo独自のBIMIページでは、隔離または拒否DMARCポリシーが必要です。 BIMIレコード 有効な SVG、バルクメール、および送信アドレスの十分な評判とエンゲージメントを指します。現時点では VMC は必要ありませんが、提供されたVMCによって全体的な資格がわかります。このページでは、組織ドメインの設定を優先しながら、サブドメインのBIMIレコードを尊重します。これらは Yahoo 固有の声明であり、 Gmail同じ証明書や表示ポリシーを共有しているという証拠ではありません。 Yahoo BIMI要件
Yahooがそのページに PCT 条件を欠如していることを、考えられるすべてのタグ処理動作の証拠として解釈しないでください。情報源が実際に述べていることと、不特定のままにしていることを記録します。同様に、その大量メールと評判の状況は、単一の個人テスト メッセージが文書化されたロゴ表示集団を代表していない可能性があることを意味します。レビュー対象のソースが送信しきい値を提供していない場合は、送信しきい値の数値をでっち上げないでください。
ポリシーを実際のメッセージ認証に接続する
DMARC評価する アライメント 表示されている From ドメインと通過ドメインの間 SPF または DKIM そのルールの下でのアイデンティティ。公開された強制設定は、すべての正当な送信者に通過を強制するものではありません。より厳格な処理を提案する前に、送信サービスを一覧表示し、どの ID が認証されているかを特定します。ポリシーの変更は正当なワークフローに影響を与える可能性があるため、ロゴの期限はメール チームの準備と承認のプロセスを迂回してはなりません。 RFC 9989認証と調整
後で制御して観察できるように、実際に受信したメッセージと信頼できる認証結果を保持します。生成システムと信頼境界を特定せずに、任意のヘッダーから要求されたパスを受け入れないでください。ポリシーの検出、メッセージ認証、ロゴの表示を個別の結果として保持します。メッセージは、受信者の追加の表示条件を満たさなくても認証を通過できます。 RFC 8601信頼境界
オリジナルの受信者資格ワークシート
受信者およびメール ストリームごとに 1 行を作成します。以下に提案されているフィールドは、一般的な「 BIMI対応」ステータスが重要な違いを隠すことを防ぎます。このワークシートでは実際の展開は評価されていません。
- ソース: 受信側ページ、取得日、表示される改訂日、およびプロトコル参照バージョン。
- ドメイン ポリシー: 該当する正確な記録と、組織またはサブドメインに関する質問。
- 文書の不一致: タグまたは条件、証拠、および未解決の適用性の所有者に異議があります。
- メッセージの証拠: 表示される From、認証された ID、整合性、および信頼できる結果ソース。
- 資産: 承認された SVG バージョン、受信機の寸法、および構造的所見。
- 証明書: 必要なカテゴリ、発行者のステータス、およびホストされた PEM の依存関係。
- 取得と表示: パブリックエンドポイント証拠、受信クライアント、観察時間と制限。
- 決定: このストリームに適格、不適格、または不明。残りの条件はあります。
監視と強制の決定は、表示実験とは別にしてください。既存の送信者が調整に失敗した場合は、ロゴ ファイルを繰り返し変更するのではなく、送信者の構成とビジネスへの影響を解決します。認証は成功したがロゴが表示されない場合は、グラフィックの欠落だけでDMARC壊れていると宣言せずに、証明書、ホスティング、サポート、および任意の適格性を調査してください。
架空の例: 1 つのチェックリストが 2 人の受信者を隠す
Fictional Silver Orchard は、「 DMARCパス、証明書はオプション」と記載された起動チェックリストを用意しています。この文言は、 Yahooの証明書の立場とGmailの文書化された別のワークフローを統合しています。また、レビュー担当者は、古い内部ガイドでは pct を変更されていないユニバーサル プロトコル要件として扱っているのに、 RFC 9989ではそれを削除しており、Google の現在のページには依然としてpct=100.チームには文書に関する質問が 2 つありますが、いずれかの受信機が故障しているという証拠はありません。
提案されている次のステップは、実稼働DNS変更する前に、チェックリストをソース日付の受信者の行に分割し、タグの適用性に関する質問をエスカレーションすることです。各ストリームには、実際のメッセージ証拠と、独自の資産および証明書のチェックが必要です。 Silver Orchard メッセージ、 DNSレコード、受信者はテストされませんでした。この例は、一般的なチェックリストが未解決の仮定をどのように隠すことができるかを示しています。
カタログには、受信者固有の資格マトリックスと、 DNS 、ロゴ、証明書、およびメッセージ認証の証拠が必要です。この原稿は、運用上の証拠ではなく、提案されたマトリックスと文書化された相違点を提供します。元の証拠、人間の SME、ソースの適用可能性、生産ルート、視覚的なアクセシビリティ、および所有者の公開はすべて未解決のままです。ポリシーの変更、ライブテスト、または資格の保証は含まれません。