BIMIは認証されたメールを受信トレイでより認識しやすくすることができますが、実際に受信トレイへの配信率を向上させるのでしょうか?

この違いは重要です。

BIMI(Brand Indicators for Message Identification)は、対応しているメールボックスプロバイダーが、認証されたメールと並んでブランドが管理するロゴを表示できるようにします。資格を得るには、送信ドメインが強制適用されたDMARCを含む強力なメール認証要件をすでに満たしている必要があります。一部のメールボックスプロバイダーは、組織がロゴを使用する権利を検証するサードパーティのマーク証明書を要求または認識しています。

BIMIは、より強力なDMARC強制適用と同時に展開されることが多いため、組織は実装後にメールパフォーマンスの向上を確認し、ロゴ自体が配信性を向上させたと考える場合があります。

現実はより複雑です。

主要なメールボックスプロバイダーから、BIMI自体が受信トレイ配信ランキングシグナルとして直接機能するという明確な公開証拠はありません。

より強力な配信性の利点は、通常、BIMIに関連して必要とされる認証、レピュテーション、送信慣行から得られます。その後、ロゴはブランド認知と受信者の信頼を通じて第2の価値層を追加できます。

この記事では、これらの効果を分離します。

I. BIMIが実際に行うこと

BIMIは、対応しているメールボックスプロバイダーが認証されたメールの横にブランドが管理するロゴを表示できるようにする仕様です。

BIMIはSPF、DKIM、DMARCに代わるものではありません。

代わりに、それらの上に構築されます。

BIMI Groupは、BIMIがDMARC認証に依存しており、DMARCが強制適用されている必要があると述べています。その実装ガイダンスでは、p=quarantineまたはp=rejectが必要であり、p=noneはBIMI適格性として受け入れられません。

大まかに言うと、BIMIには以下が必要です:

  1. 適切に認証された送信ドメイン
  2. DMARC強制適用
  3. BIMI DNSレコード
  4. 準拠したSVG Tiny Portable/Secureロゴ
  5. メールボックスプロバイダーが要求する場合、有効なマーク証明書
  6. ロゴ表示のための十分な送信者レピュテーションとプロバイダー固有の適格性

したがって、BIMIは、送信者が基礎となる認証基盤を確立した後に、目に見えるアイデンティティレイヤーを追加します。

II. BIMIはメッセージを認証しない

BIMIがメール認証を実行するという誤解があります。

それは違います。

SPFは、エンベロープドメインに対して送信インフラストラクチャが承認されているかどうかを評価します。

DKIMは、署名ドメインと署名されたメッセージコンテンツに関連付けられた暗号署名を検証します。

DMARCは、通過したSPFまたはDKIMアイデンティティがFromヘッダーに表示されるドメインと整合しているかどうかを判断します。

BIMIは、その認証された基盤を使用してブランドロゴの表示を可能にします。

BIMI Groupは、BIMIを組織によって既に展開されているDMARC保護を活用するものとして説明しており、それを置き換えるものではありません。

つまり:

DMARCはドメインアイデンティティを保護します。BIMIはその認証されたアイデンティティを可視化します。

III. VMC vs CMC:現在のBIMI証明書モデル

BIMI証明書の用語は進化しています。

現在重要な2つの証明書タイプは:

Verified Mark Certificate (VMC)

VMCは、組織が適格な商標登録されたロゴを使用する権利を検証します。

Googleは可能な限りVMCを推奨しており、GmailはVMCで検証された送信者の横に検証チェックマークを表示することを指摘しています。

Common Mark Certificate (CMC)

CMCは、VMCに必要な商標ステータスを持っていない組織が、異なる適格性ルールの下で検証されたロゴを使用できるようにします。

GoogleはGmailにCMCサポートを追加し、VMC適格組織以外にもBIMI参加を拡大しました。

この区別は重要です。なぜなら、BIMIは普遍的にVMCを必要とするものとして正確に説明されなくなったためです。

異なるメールボックスプロバイダーは、異なる証明書とレピュテーション要件を適用します。

IV. メールボックスプロバイダーの要件は同一ではない

Gmail、Yahoo、Apple Mail、OutlookにおけるBIMI証明書要件の比較表

BIMIサポートはプロバイダー間で異なります。

Gmail

GoogleはGmail BIMI実装にVMCまたはCMCを要求します。Gmailは、p=quarantineまたはp=rejectでのDMARC強制適用も要求し、該当するポリシーの割合が100%に設定されている必要があります。Gmailは、VMCで検証された送信者に対して追加の検証チェックマークを表示します。

Yahoo

YahooはBIMIをサポートしていますが、YahooアプリケーションにBIMIロゴが表示されるために現在VMCを要求していないと明示的に述べています。ただし、Yahooは全体的なBIMI適格性評価の一部としてVMCを使用する場合があります。

Apple Mail

Apple Mailは、iOS、iPadOS、macOS、およびiCloud.comのサポートされているバージョンでBIMIをサポートしています。AppleはBIMI送信者が強力な認証要件を満たし、ブランドロゴに対する管理を実証する必要があると述べています。

Microsoft

Microsoftの現在のドキュメントによると、Exchange OnlineはGmailやYahooなどの受信プラットフォームと同じ方法でBIMIをまだサポートしていません。MicrosoftはDynamics 365 Customer Insightsを通じてBIMI関連の送信機能をサポートしていますが、Exchange Online自体は現在一般的なBIMIレンダリングを提供していません。

これが、組織がBIMI公開後に普遍的なロゴ表示を想定すべきでない理由です。

V. BIMIが失敗する可能性がある場合

BIMIが機能しない4つの一般的な原因：不十分なDMARCポリシー、証明書の欠如、送信者レピュテーションの低さ、無効なロゴ形式。

BIMI展開は技術的に構成されていても、表示に失敗する可能性があります。

一般的な失敗条件には以下が含まれます:

DMARCが強制適用されていない

BIMIはp=noneをサポートしません。

組織ドメインはBIMIのDMARC強制適用要件を満たす必要があります。

個別メッセージでDMARCが失敗する

BIMI適格性は認証されたメールに対して評価されます。

SPFもDKIMも整合性を持って通過しないため、特定のメッセージがDMARCに失敗した場合、ドメインのBIMI DNSレコードが正しくてもロゴが表示されない場合があります。

マーク証明書の問題

VMCまたはCMCが必要な場合、証明書の有効期限切れ、アクセスできないPEMファイル、ロゴの不一致、または証明書検証の問題により表示が妨げられる可能性があります。GoogleのBIMIトラブルシューティングガイダンスは、ロゴが表示されない場合、証明書の有効性、PEMファイル、および関連するSVGを確認することを特に推奨しています。

SVGの問題

BIMIはSVG Tiny Portable/Secureを使用し、通常のウェブエクスポートされたSVGではありません。

無効なSVG構造、サポートされていない要素、外部参照、スクリプト、または不正な寸法により、ロゴ検証が妨げられる可能性があります。GoogleはGmail向けに追加のBIMI SVG要件も公開しています。

レピュテーションまたはプロバイダー適格性

有効な証明書は、ロゴが表示されることを保証するものではありません。

BIMI Groupは、メールボックスプロバイダーがBIMIロゴを表示するかどうかを決定する際に、レピュテーションやその他の適格性シグナルを考慮できることを指摘しています。

サポートされていないメールボックスプロバイダー

受信プロバイダーがBIMIをサポートしていない場合、メールは正常に認証および配信されますが、BIMIロゴは表示されません。

したがって、通常の失敗は静かです:

メールは配信されますが、ロゴは表示されません。

VI. BIMIは受信トレイへの配信率を直接向上させるか?

BIMIが受信トレイへの到達率を直接向上させるという公開された証拠はないことを示す統計カード。DMARCはメールを認証し、BIMIはロゴを表示します。

最も安全な答えは:

主要なメールボックスプロバイダー全体で、BIMI自体が受信トレイ配信ランキング要因であるという確立された公開証拠はありません。

メールボックスプロバイダーは、送信者要件を説明する際に、認証、レピュテーション、ユーザー苦情、送信動作、コンテンツ、悪用シグナル、および関連要因について公に議論しています。

BIMIは主に認証されたブランドロゴ表示のメカニズムとして文書化されています。

この区別は重要です。

送信者は以下を期待してBIMIを実装すべきではありません:

「VMCを追加したので、Gmailはより多くのメールを受信トレイに配置するだろう」

この約束をする信頼できる根拠はありません。

VII. BIMIとより良い配信性がしばしば一緒に現れる理由

組織がBIMIプロジェクトの周りでより良いメールパフォーマンスを観察する可能性がある強力な理由があります:

BIMIは組織に最初に認証基盤を改善することを強制します。

BIMI対応になるために、組織は通常以下を行う必要があります:

  • 正規の送信者を発見する
  • SPFの問題を修正する
  • DKIMを一貫して展開する
  • DMARC整合性を修正する
  • p=noneから移行する
  • DMARC強制適用に到達する
  • 未承認のソースを削除する
  • サードパーティ送信者の問題を解決する
  • ドメインガバナンスを改善する

これらの改善は、BIMIロゴとは独立してメール環境をより健全にすることができます。

したがって、企業は次のことを観察する可能性があります:

BIMI前

  • p=none
  • 不明な送信ソース
  • 弱いDKIMカバレッジ
  • スプーフィング活動
  • 認証失敗

BIMI準備後

  • p=reject
  • 正規の送信者が識別される
  • 整合したDKIM
  • 未承認のソースがブロックされる
  • 安定した認証

受信トレイへの配信率が向上した場合、そのすべての改善をロゴに帰属させることは誤解を招くでしょう。

改善の多くは、基礎となるメール認証環境の修正から来ている可能性があります。

VIII. BIMIは依然として受信者の行動に影響を与える可能性がある

BIMIが興味深くなるのは人間の層です。

認識可能なロゴは、受信者が馴染みのある正規の通信をより迅速に識別するのに役立つ可能性があります。

これは潜在的に以下に影響を与える可能性があります:

  • ブランド認知
  • 受信者の信頼
  • 開封
  • クリック行動
  • スパム苦情
  • ユーザーの信頼

たとえば、MicrosoftのBIMIドキュメントは、基礎となる認証基盤を強調しながら、ブランド認知とエンゲージメントの向上をBIMIの潜在的な利点として説明しています。(Microsoft Learn)

これにより、もっともらしい間接的な関係が生まれます:

BIMI可視性 → より強いブランド認知 → より良い受信者行動 → 時間経過とともにより強いレピュテーションシグナル

しかし、これは保証された配信性向上としてではなく、間接的な経路として説明されるべきです。

IX. 開封率の主張には注意が必要

開封率は完璧なBIMI測定指標ではありません。

プライバシー機能、特にApple Mail Privacy Protectionは、従来の開封トラッキングを歪める可能性があります。そのため、開封率の変化をロゴ表示に直接帰属させることは困難です。

したがって、BIMIを評価する組織は、開封だけに頼るのではなく、複数の指標を使用する必要があります。

以下を考慮してください:

  • 苦情率
  • クリックスルー率
  • コンバージョン率
  • 受信トレイ配信テスト
  • スパムフォルダー配信
  • 配信停止率
  • ドメインレピュテーション
  • 認証失敗率
  • キャンペーンレベルのエンゲージメント
  • プロバイダー固有のパフォーマンス

目標は、BIMIロゴが実際に表示されている場所で受信者が異なる動作をするかどうかを判断することです。

X. シナリオ1:DMARC強制適用と同時にBIMIを追加

企業が以下から移行したと想像してください:

p=none

から:

p=reject

BIMIも同時に開始します。

その後:

  • スプーフィングが減少
  • 認証が改善
  • 受信トレイへの配信率が改善
  • サポートされている受信トレイにロゴが表示される

BIMIを評価したくなるでしょう。

しかし、複数の変数が同時に変化しました。

配信性の向上は主により強力な認証とよりクリーンな送信インフラストラクチャを反映している可能性があります。

BIMIは依然として追加のブランド可視性に貢献する可能性がありますが、効果をきれいに分離することはできません。

XI. シナリオ2:すでに成熟したドメインにBIMIを追加

次に、すでに以下で運用されている組織を考えてください:

p=reject

以下を伴って:

  • 高いDKIM整合性
  • クリーンな送信者インベントリ
  • 安定したレピュテーション
  • 強力な受信トレイ配信

組織はBIMIを追加します。

この場合、最も可能性の高い即座の変化は視覚的です:

受信プロバイダーがBIMIをサポートしている場所にブランドロゴが表示されます。

認証環境自体が実質的に変化していないため、大きなフィルタリングの改善を想定すべきではありません。

測定可能な利点は、受信者の認識とエンゲージメントに現れる可能性が高くなります。

XII. シナリオ3:適切なDMARC強制適用なしでBIMIレコードを公開

企業が以下を公開します:

v=BIMI1; l=https://example.com/logo.svg;

しかし、以下のままです:

v=DMARC1; p=none;

ドメインはBIMI強制適用要件を満たしていません。

BIMIレコードは存在する可能性がありますが、ドメインはBIMI対応ではありません。

GoogleはGmail BIMIに対してp=quarantineまたはp=rejectを明示的に要求しており、該当する割合が100%である必要があります。

これは、BIMI DNSを公開するだけでは不十分である理由の一般的な例です。

XIII. 組織がBIMIを実装する理由

BIMIは、直接的な配信性向上を約束しなくても価値がある可能性があります。

ブランド認知

検証されたロゴは、サポートされている受信トレイ内に追加の視覚的アイデンティティを作成します。

可視的な信頼

BIMIは、受信者に表示されるブランドを認証された送信環境に接続します。

DMARC成熟度

BIMIは、組織に監視に無期限に留まるのではなく、DMARC強制適用を完了するビジネスインセンティブを提供します。

ブランド検証

VMCおよびCMC発行は、組織と表示されるマークの使用に関する独立した検証を追加します。

Gmail検証インジケーター

適格なVMCベースの実装の場合、Gmailは送信者の横に検証チェックマークを表示できます。

将来への備え

メールボックスプロバイダーのサポートは進化し続けています。BIMIを正しく確立している組織は、追加のプロバイダーがサポートを拡大するにつれて利益を得る立場にあります。

XIV. BIMIが修正しないもの

BIMIは以下の解決策として扱われるべきではありません:

  • 不十分なリスト衛生
  • 高い苦情率
  • 購入したリスト
  • スパムトラップ
  • 弱いドメインレピュテーション
  • 弱いIPレピュテーション
  • 過剰な送信量
  • 疑わしいコンテンツ
  • 安全でないURL
  • 不十分なセグメンテーション
  • 望まれないマーケティングメール

BIMIはこれらの問題を覆すことはありません。

美しく検証されたロゴは、望まれないメールを望まれるものにしません。

XV. BIMIの実際の影響を測定する方法

BIMIを評価する最もクリーンな方法は、認証の改善とロゴの展開を分離することです。

ステップ1:認証ベースラインを確立する

測定:

  • DMARC合格率
  • DKIM整合性
  • SPF整合性
  • 未承認のソース
  • ドメインレピュテーション
  • 受信トレイ配信
  • 苦情率

ステップ2:DMARC強制適用に到達する

BIMIを評価する前に、認証の問題を修正し、安定した強制適用態勢に到達します。

これにより、DMARC修復の効果がBIMI自体と混同されるのを防ぎます。

ステップ3:BIMI前のパフォーマンスベースラインを確立する

代表的な送信期間にわたってパフォーマンスを測定します。

固定の30日間のウィンドウを必須として扱わないでください。通常の送信サイクルとキャンペーンのバリエーションをキャプチャするのに十分な長さの期間を使用してください。

ステップ4:BIMIを展開する

構成:

  • BIMI DNS
  • SVG Tiny-PSロゴ
  • 必要に応じてVMCまたはCMC
  • 証明書ホスティング
  • プロバイダー固有の要件

ステップ5:実際のロゴ表示を確認する

BIMIをサポートするメールボックスプロバイダーに対してテストします。

DNS有効性がロゴが表示されていることを意味すると仮定しないでください。

ステップ6:プロバイダー別にパフォーマンスをセグメント化する

BIMIが表示される環境と表示されない環境でパフォーマンスを比較します。

サポートするプロバイダーを使用している受信者の間でのみエンゲージメントが向上する場合、BIMIが貢献している可能性があります。

受信トレイへの配信率がどこでも同様に向上する場合、原因は他の場所にある可能性があります。

XVI. Skysnag Certify:推測なしのBIMI

BIMI実装には、ロゴの公開以上のことが含まれます。

組織は以下を調整する必要があります:

  • DMARC強制適用
  • SPFおよびDKIM整合性
  • SVG Tiny-PS準備
  • 商標またはマーク適格性
  • 該当する場合のVMCまたはCMC要件
  • 証明書発行
  • BIMI DNS
  • メールボックスプロバイダー適格性
  • 継続的な証明書とロゴの監視

Skysnag Certifyは、これらの要素を管理された実装プロセスにまとめます。

Certifyは、組織がDNS、証明書、ロゴ、および検証要件の調整に関わる運用作業を削減しながら、信頼されたブランド表示に必要な認証と検証の基盤を確立するのに役立ちます。

VMCベースの検証を追求する組織の場合、Skysnag Certifyは、より広範な商標、検証、証明書、およびBIMI展開プロセスもサポートできます。

Skysnag Certifyの詳細については、こちらをご覧ください:

XVII. 重要なポイント

  • BIMIはSPF、DKIM、DMARCに代わるものではありません。認証されたメール環境の上に構築されます。
  • BIMIはDMARC強制適用を必要とします。p=noneは十分ではありません。
  • Gmailは現在、BIMIにVMCとCMC証明書の両方をサポートしています。VMC検証された送信者は、Gmailの追加検証チェックマークを受け取ることができます。
  • YahooはBIMIをサポートしていますが、VMCを普遍的に要求していませんが、証明書は適格性決定に貢献できます。
  • Apple MailはサポートされているAppleプラットフォームでBIMIをサポートしていますが、Microsoft Exchange Onlineは現在一般的なBIMIレンダリングを提供していません。
  • 主要なメールボックスプロバイダー全体で、BIMI自体が受信トレイ配信ランキングシグナルであるという確立された公開証拠はありません。
  • BIMIプロジェクト中に観察される配信性の改善は、多くの場合、BIMIを展開する前に必要なDMARC強制適用と認証修復から来ています。
  • BIMIは、サポートされている場合、ブランド認知、受信者の信頼、およびエンゲージメントを通じて間接的な利点を提供する可能性がありますが、これらの効果は仮定されるのではなく測定されるべきです。
  • BIMIは、不十分なレピュテーション、苦情、悪いリスト衛生、または望まれないコンテンツを補償することはできません。
  • BIMIを実装する最も強力な理由は、自動的な受信トレイ配信の約束ではなく、成熟したメール認証プログラムの上に検証されたブランド可視性を得ることです。