証明書が何を達成する必要があるかを決定する
A ベリファイドマーク証明書 プロジェクトは、購入ではなく、ターゲットとなるエクスペリエンスと証拠の計画から始める必要があります。インジケーターが重要となるブランド、法的所有者、ドメインの送信およびサービスの受信を特定します。送信者の横にあるロゴと受信者固有のロゴを区別する 確認済みのチェックマーク。発行者は、すべての受信者のインターフェイスや受信箱の配置を保証することなく、証明書の内容を検証して発行できます。その結果として得られる決定は、権利、技術的な準備、および継続的な所有権を結び付ける必要があります。
この記事はドキュメンタリーの準備ガイドです。実際の申請者の適格性を確立したり、法的アドバイスを提供したり、申請を提出したりするものではありません。 BIMI 確立されたIETF Standards Track RFC ではなく、草案作業が残っています。以下のソースは発行者と受信者の文書であり、その主張は実際の範囲内に保たれています。発行者の確認が欠けているため、明示的なリリース ゲートが残ります。
マーク権をドメイン制御から分離する
2026 年 10 月 30 日に変更された DigiCert のVMCページには、登録商標の要件、適切な SVG-P/S ロゴ、および DMARC 準備完了。その比較資料では、 VMCオプションとして政府マークも特定されています。この区別は、ドメインの所有によって適格なマークの権利が確立されると想定するのではなく、発行者の現在のカテゴリ固有のチェックリストを取得する理由として扱います。ドメイン登録、会社設立、商標登録は別の証拠となります。 DigiCert VMC要件 DigiCert 証明書の比較
正確な商標、登録者、管轄権、登録ステータス、および出願人との関係を特定する権利参照を準備します。子会社が親会社のマークを使用している場合、または最近の買収により所有権が変更された場合は、発行者にどのような認可と組織記録が必要かを問い合わせてください。視覚的に類似したロゴや係属中の商標出願から受諾を推測しないでください。法務担当者および発行者の審査担当者は、証明書が利用可能として扱われる前に、これらの疑問を解決する必要があります。
組織と代表者の確認を慎重に準備する
DigiCert では、組織レベルの検証と、本人確認書類や対面またはビデオでのやりとりを含む、申請者の代表者に対する追加チェックについて説明しています。そのページには、確認会議と並んで、公証文書やライブウェブカメラの検証ルートについて言及されています。リストされているすべてのオプションを普遍的な必須の順序に組み合わせるのではなく、現在のプロセスが申請者に適用されるものを発行者に尋ねてください。 DigiCert 検証の説明
準備ワークシートには、パスポートやその他の身分証明書を一般的なプロジェクト フォルダーに収集するのではなく、誰が応答できるか、承認された安全な送信チャネルがどこにあるかを記録する必要があります。組織を代表する権限を確認し、欠席時の代替連絡先が存在することを確認します。証拠の保存とアクセス制御を適切に保ちます。この原稿に関して機密文書は収集または送信されておらず、提案されたチェックリストは発行者によって承認されたものではありません。
正確な資産と認証の前提条件を確認する
証明書申請では、記録されたダイジェストとブランド所有者の承認とともに、承認された SVG 候補 1 つを参照する必要があります。 DigiCert には SVG-P/S プロファイルが必要です。 Google は、各方向に少なくとも 96 ピクセルの Gmail 固有の絶対サイズを追加します。準拠しているように見える輸出と法的に適格なマークには、依然として個別の技術審査と権利審査が必要です。便利なプレースホルダーを送信したり、発行後にそれが証明書にどのような影響を与えるかを尋ねずに置き換える計画を立てたりしないでください。 Google SVG と証明書のワークフロー
Google の現在のセットアップ ページにはVMCまたは CMC と書類 DMARC施行 p は隔離または拒否に設定され、pct は 100 に設定されます。これらの正確な値は、現在のDMARCプロトコルの完全な仕様としてページを提示するのではなく、受信機のドキュメントに帰属します。メール チームは、送信者に対する実際の認証の準備を確立する必要があります。証明書の調達期限は、未確認の施行変更を行う理由にはなりません。
ソースの日付が記載された受信機マトリックスを構築する
Gmail行については、保存されている Google ページには、VMC で検証された送信者にはチェックマークが表示されると記載されており、証明書に基づく PEM の展開について説明されています。ロゴ パスとしてCMCも受け入れます。それらは異なる結果です。他のすべての受信者については、独自の現在の一次文書を入手し、証明書のカテゴリ、資産要件、および約束されたまたは任意の表示動作を記録します。サポートされていない行は、ベンダーのマーケティング比較に基づいて埋めるのではなく、不明なままにしておきます。 Google 受信機の要件
マトリックスには、受信者とクライアント、文書化の日付、受け入れられた証明書クラス、必要なインジケーター、必要な展開資料、および残りの検証を含める必要があります。 Gmailに関する声明は、Apple Mail またはYahoo動作を確立するものではありません。同様に、過去のスクリーンショットは現在のサポート契約ではありません。 DigiCert の比較ページには、受信機の変更に遅れる可能性があるモバイル チェックマークの注記が含まれています。受信機固有の表示クレームについては、受信機独自の文書を使用してください。
オリジナルの発行者対応ワークシート
以下に提案されているチェックリストは発行者によって確認されるように設計されていますが、ここでは発行者は申請者に対してそれを確認していません。各アイテムに、「はい/いいえ」の推測ではなく、責任ある所有者と日付の付いた証拠の参照を与えます。
- アプリケーション ID: 法人、認定代表者、および安全な発行者の連絡ルート。
- マーク カテゴリ: 正確に登録された、または発行者がサポートするその他のカテゴリおよび権利証拠の参照。
- ドメインの範囲: 要求されたドメイン、コントロールの所有者、および未解決の組織関係。
- ロゴ候補: 承認されたファイルのダイジェスト、構造的所見、および視覚的な承認。
- メールの準備: ターゲット受信者の要件と実際の認証証拠が引き続き必要です。
- 発行者のプロセス: 現在要求されているドキュメント、検証手順、および未解決の質問。
- レシーバー マトリックス: サポートされているカテゴリと、名前付きサービスごとに意図されるエクスペリエンス。
- 継続性: 更新所有者、交換連絡先、ホスティング責任、およびブランド変更手順。
調達は、重大な不確実性についての明確な決定を待つ必要があります。資格が権利譲渡に依存する場合は、暫定的な回答を購入の前提に変換しないでください。対象の受信者が選択したカテゴリに必要なインジケーターを提供していない場合は、支払う前に要件を解決してください。これはガバナンスに関する提案であり、払い戻しの権利や保証された発行時期に関する声明ではありません。
架空の例: 子会社が親会社の商標を使用する
架空の Willow Transit は、地域子会社の検証済み送信者インジケーターを望んでいます。ロゴは親会社に属し、メール ドメインは子会社に属し、アプリケーションを準備する従業員は共有サービス チームに所属しています。提案されたレビューでは、正確な商標に対する権利、出願人の権限、およびドメインの範囲という 3 つの異なる問題が見つかりました。 Web サイトにロゴが表示されていることを示すだけでは、何も答えることはできません。
次のステップは、発行者が確認した、発行元の日付が記載された受信者マトリックスを伴う、許容可能な組織および認可の証拠のリストです。チームはまた、承認された SVG 候補を凍結し、エンティティ全体に更新所有権を割り当てます。これは架空の計画例です。商標登録、発行者の申請、証明書、またはメッセージ配信のテストは行われず、適格性の判断も行われていません。
実際の確認次第でリリースを残す
カタログには、発行者が確認した証拠チェックリストと対象プロバイダーのサポート マトリックスが必要です。この原稿では、構造と文書化されたGmail例を提供しますが、申請者固有の発行者の確認や実際の展開のための完全なマトリックスは提供しません。したがって、人間のSME、ソースの適用性、生産ルート、視覚的なアクセシビリティ、および所有者の公開と並んで、元の証拠はオープンなままです。 1 つの文書が到着した時点でプロジェクトの完了を宣言するのではなく、発行、展開、受信者の観察を個別のマイルストーンとして維持します。