ページの先頭です


ページ内移動用のリンクです

  1. ホーム
  2. IIJの技術
  3. セキュリティ・技術レポート
  4. Internet Infrastructure Review(IIR)
  5. Vol.71
  6. 3. フォーカス・リサーチ 国内プロバイダ初、WebメールのBIMI表示対応〜IIJmioセーフティメールの安全対策〜

Internet Infrastructure Review(IIR)Vol.71
2026年9月
RSS

目次

3. フォーカス・リサーチ

国内プロバイダ初、WebメールのBIMI表示対応
〜IIJmioセーフティメールの安全対策〜

3.1 IIJmioセーフティメールにおけるBIMIアイコン表示対応

2025年12月、IIJmioセーフティメールで提供中であるWebメール、"Mailviewer"において、BIMIを用いたブランドアイコンの表示機能が追加されました。

BIMIを利用したアイコンの表示機能に対応しているWebメールは、Google社のGmailが世間によく知られています。IIJで観測した限り、日本国内の各インターネットサービスプロバイダが提供するWebメールが後述するVMC及びCMCを区別してBIMI表示に対応したのはMailviewerが日本国内初です。

本稿では、BIMIの現在の仕様についての解説と、MailviewerでのBIMI表示について紹介をします。

3.2 IIJmioセーフティメールについて

IIJmioセーフティメールは、IIJが個人のお客様に提供しているメールサービスです。IIJでは、IIJmioブランドの前身である、IIJ4Uブランドを提供していた頃より個人のお客様向けにもメールサービスを提供しています。

サービス名が示すとおり、安全性を重視した設計になっており、ウイルススキャンやスパム検知機能、SPF・DKIM・DMARCといった送信ドメイン認証を利用したなりすましメール対策フィルタを、従来から提供しています。そんなIIJmioセーフティメールで提供しているWebメール「Mailviewer」は2000年代に提供を開始した、IIJ謹製のWebメールシステムです。当時はメールを読む、書くという最低限の機能しか備えておらず、名前の由来もそのあたりから来ています。2021年12月にリニューアルをして、現在多くの機能を備えたWebメールとしてMailviewerの名をそのまま受け継ぎ、サービス提供を続けています。

今回のブランドアイコン表示機能は、そんなMailviewerに新たに加わったBIMIという仕組みを使った機能です。

図-2 IIJmio Mailviewerログイン画面

図-1 IIJmioセーフティメール概要ページ

3.3 BIMIについて

BIMIとは、Brand Indicators for Message Identificationの略です。WebメールやMUA(Mail User Agent)でブランドアイコンを表示するための規格であり、IETFでInternet Draftとして2019年2月から公開されています。

BIMIはBIMI groupにて様々な議論がされていますが、RFCとして採番をされているわけではありません。SPF、DKIM、DMARCからなる送信ドメイン認証技術を応用して、ブランドアイコンの表示/非表示をするための仕組みですが、一般のメールユーザがメールを実際に参照するアプリケーションは様々であり、提供している企業によって実装が多様であるため、明確に規格があるわけではなく、あくまでもロゴマーク表示のための指針として議論がされているようです。

BIMIには、表示するブランドアイコンファイル用の電子証明書が存在し、VMC(Verified Mark Certificate)とCMC(Common Mark Certificate)の2種類があります。

  • VMC(Verified Mark Certificate):商標登録されたアイコン用の証明書
  • CMC(Common Mark Certificate):組織による利用実績が認められたアイコン用の証明書

それぞれの違いは表-1のとおりです。

CMCについては、シーズンごとにアイコンの一部を装飾したり、VMCを取得するまでの間利用する、といった用途での利用が想定されているようです。VMCは商標登録したアイコンにしか使えないため、企業が提供するサービスによってはCMCを用いてシーズンごとに切り替えたりすることができれば、ユーザ目線でも分かりやすいかもしれません。

表-1 ブランドアイコンファイル用の電子証明書

図-3 Mailviewer Webメール画面(メール一覧加工処理済み)

例えばIIJmioの場合、青を基調としたデザインとピンクを基調にしたデザインがあるため、CMCを利用することでユーザの皆様に送るメールの種類によってアイコン画面の出し分けが可能です。

VMCを用いた場合は、すべてのアイコンについてそれぞれ個別に商標登録をしなければならないため、アイコンの種類が膨大にあるブランドであったりすると、CMCの方が使い勝手は良いかもしれません。

また、時期によってアイコンを少し変えたい、というようなメール送信側の需要に応える側面もあるため、ブランド広告メールへのシーズンアイコンなどに利用することもCMCを利用することで実現できます。

これらの証明書は、BIMI GroupによるとDigiCert、GlobalSign、SSL.comが対応した証明書を発行しているとのことです(注1)。VMC、CMCは表示するアイコン画像ファイルに対する電子署名であり、受信システムの評価の方法に依存しますが、MVA(Mark Verifying Authority)として広く知られている認証局から発行されたものでないと効果を発揮しない場合が多いです。また、これらの証明書は必須ではありません。証明書を検証するかどうかは、受信したメールを表示する各WebメールやMUAの実装に委ねられています。

前述したように、BIMIは送信ドメイン認証技術の元に成り立っており、ブランドアイコンを表示するための前提として、そのメールの送信元ドメイン(RFC5322.From)と、その親ドメインのDMARCポリシーがquarantineまたはrejectでないと表示ができません。

DMARCポリシーについては以前、IIR Vol.55でIIJで利用しているiij.ad.jpのポリシーをp=rejectにしたことをIIRに書いていますので、参考にしてください(注2)。

図-4 IIJmioアイコン

3.3.1 BIMIの送信者対応について

まずはBIMIの仕組みについて送信側の視点と、受信側の視点で解説をしていきたいと思います。

まず、メールの送信者はRFC5322.Fromに対して下記の対応をします。

  1. (1)FromドメインのDMARCポリシーの宣言(p=quarantineまたはp=reject)とDMARC検証をpassさせるための各種ITリソースの整理
  2. (2)Fromドメインに対するロゴファイル(svgファイル)の準備
  3. (3)ロゴファイル公開に対応した証明書の準備
  4. (4)ロゴファイルと証明書のWebサーバでの公開
  5. (5)BIMIレコードの公開
(1)FromドメインのDMARCポリシーの宣言(p=quarantineまたはp=reject)とDMARC検証をpassさせるための各種ITリソースの整理

DMARCを導入する際に多くの方が検討することだと思いますので、ここでの説明は省きます。が、DMARCは導入して終わり、ではなく継続的な観測と確認、是正が必要です。

BIMIを用いたアイコンの表示をするためにはそのドメインのサブドメインのポリシー(spタグ)もsp=noneを宣言してはいけません。

(2)Fromドメインに対するロゴファイル(svgファイル)の準備

2つ目は、実際にメールを受信したシステムで表示するロゴファイルの用意についてです。

実際に表示するロゴについては、決められた規定を満たしたものでないといけません。BIMIのインターネットドラフトが公開された当初から言われているのが、"商標登録されているロゴマーク"です。また、2024年後半頃から、少し緩和がされていて、"12ヵ月間継続的な利用が第三者機関で認められたロゴマーク"についても使用できるロゴマークとして認められるようになりました。

これらの画像ファイルは、svgというファイル形式かつ、SVG Tiny 1.2をベースとしたSVG P/S(Portable/Secure)という形式のファイルであることが決められています。筆者も画像ファイルの形式についてはあまり明るくはありませんが、いくつか調べたところ下記のような経緯があるとのことです。

  • SVG Tiny 1.2はモバイル端末や組み込み機器などの、大きなファイルのやり取りが難しい端末向けの軽量版SVGファイル規格であり、一部アニメーションやJavaScriptの埋め込み、外部参照が可能
  • SVG P/Sはより機能を制限したプロファイルであり、Tiny 1.2でも可能であったアニメーションやJavaScript、外部参照などの機能も制限されている

BIMIにおいては、公開されたSVGファイルを様々な端末のMUAで表示することを目的としているため、不必要な要素をそぎ落としてファイルサイズも小さくすることができるSVG P/Sが採用されているようです。

(3)ロゴファイル公開に対応した証明書の準備

前述したとおり、ロゴの種類により取得する証明書の種類が異なります。用意したロゴファイルの種類によって、VMCもしくはCMCどちらかを取得します。また、前述したとおりこの証明書はBIMIにおいて必須のものではありません。しかし、証明書の検証をするかしないかは受信システムの実装に依存しており、現状BIMI表示に対応しているいくつかのWebメールやMUAはこの証明書の検証を必須としているものもあるため、準備するに越したことはなさそうです。

(4)ロゴファイルと証明書のWebサーバでの公開

4つ目については、これらのSVGファイルならびに証明書をWebサーバで公開するのみで、特に制約などはありません。

(5)BIMIレコードの公開

5つ目については、下記のフォーマットでBIMIレコードを公開します。

それぞれのタグについては表-2のとおりです。

表-2 タグ

左辺の"default"の部分はDKIMと同様のセレクタとなっており、セレクタとlpsタグを組み合わせて利用することで表示アイコンの出し分けが可能です。

3.3.2 BIMIの受信者対応について

では、次に受信側がどういう対応をするのかを見ていきます。

受信システムでは、受信したメールについて下記の対応が必要です。

  1. (1)各種送信ドメイン認証(SPF、DKIM、DMARC)の検証
  2. (2)BIMIの評価
  3. (3)BIMI評価結果をヘッダに付与
  4. (4)BIMI評価結果に応じてSVGファイルを取得してMUAで表示できるようにする
(1)各種送信ドメイン認証(SPF、DKIM、DMARC)の検証

送信ドメイン認証の検証は、既に多くのメールシステムが対応をしているかと思いますので今回は説明は省略します。

(2)BIMIの評価

続いて、BIMIの評価を実施します。前述した検証のうち、DMARCの検証結果がpassしたメールについて、RFC5322.FromドメインのDMARCポリシーを確認して、p=quarantineもしくはp=rejectが宣言されているメールがBIMI評価の対象となります。DMARCがpassしていなかった場合、転送などを考慮してARCの検証結果を元にBIMIを利用するか否かを選択が可能です。

どのメールをBIMI評価の対象とするかはそのシステムの設計によるとは思いますが、アイコンを表示できるメールはDMARCがpassしたメールに限られますので、すべてのメールについて検証する必要はないかもしれません。

実際のBIMI評価の際には、前述したBIMIレコードの探索から始めます。もし評価対象のメールのヘッダにBIMI-Selectorヘッダがあれば、そのセレクタを利用して宣言されたBIMIレコードの評価を実施します。また、BIMIレコードを参照した際のlpsタグにRFC5322.Fromのローカルパートが存在すれば、その文字列をセレクタとして利用します。もしそのどちらでもなければ、defaultをセレクタとして評価をします。

BIMIレコードに記載のあるSVGファイルならびにVMC/CMC証明書の確認をして、それらのファイルの検証をします。検証の結果、BIMIがpassするとついにMUAやWebメールでのロゴ表示が可能なメールと判断されます。また、BIMIの評価結果によってどのようなメールに対してブランドロゴを表示するか、については明確な決まりはなく、メールを受信したシステムの実装によります。

(3)BIMI評価結果をヘッダに付与

BIMIの評価結果は下記のようなヘッダを用いることが一般的です。

Authentication-Resultsヘッダ

Authentication-ResultsヘッダにBIMIの評価結果を付与します。受信システムによっては、bimi.selectorにBIMIセレクタ、bimi.authorityにvmc/cmcを付与することもあるようです。

BIMI-Locationヘッダ

BIMIの評価がpassになった際、受信サーバがメーラ(MUA)に対して、具体的にどのロゴアイコン(SVG)と証明書(PEM)を表示に使うべきかを指定するためのヘッダです。

各タグの値には表-3の要素が挿入されます。

表-3 タグ

BIMI-Indicatorヘッダ

受信サーバはBIMI検証が成功すると、BIMIレコードに記載のあるlタグに記載のURLから取得したブランドロゴのSVGファイルをBase64エンコードした値をBIMI-Indicatorヘッダに挿入します。これは、メールをMUAで表示する際の通信によるプライバシーへの懸念や、表示の遅延などに考慮し、サーバ側で事前に取得したデータをヘッダに挿入することでメーラはメール表示時に外部と通信することなく、安全に高速にロゴ描写をすることができます。

(4)BIMI評価結果に応じてSVGファイルを取得してMUAで表示できるようにする

こちらについては、MUAでは3にて紹介したBIMI-Indicatorのヘッダの値を参照することで、実際に表示するアイコンを取得します(図-5)。

また、2026年7月現在DKIM2(注3)などメールにおける送信ドメイン認証技術に関する新しい規格についての議論もあり、BIMIについても現在の仕組みから大きな変更がある可能性があります。

図-5 アイコン取得のフロー

3.4 IIJmioセーフティメールでのブランドアイコン表示について

さて、BIMIについて話してきましたが、IIJmioセーフティメールでは2025年12月にMailviewerにてブランドアイコン表示機能を実装しました(注4)。

IIJではお客様に提供する各メールサービスにて、SPF、DKIM、DMARCといった送信ドメイン認証技術にいち早く対応をしてきました。今回のブランドアイコン表示機能についても、IIJmioセーフティメールの利用者向けになりすましメール被害を少しでも防ぐための機能として実装をしています。

図-6はCMCを用いた際の表示例です。MailviewerではVMCに対応したブランドロゴの場合、差出人の右に緑のチェックマークが表示されます。

ブランドアイコン表示はいわば、自宅の表札を出すようなものです。表札(ロゴファイル)と、その表札が本物であることを証明する身分証明書(VMC/CMC)を、誰でも確認できる場所に掲げておく。メールを受け取った側のシステムは、メールが届くたびにこの「表札」を確認しに行き、本物であることが確認できれば、初めてロゴを表示する、という流れになっています。この確認作業はすべて自動で行われるため、利用者が意識することはありません。

これまでMailviewerでは、送信者の情報はメールアドレスや表示名でしか判断できませんでした。本機能により、DMARCを厳格に運用しBIMIレコードと証明書を正しく公開している送信元からのメールであれば、企業のロゴが一覧画面に表示されるようになります。

利用者にとっては、見慣れたロゴが表示されているかどうかが、「本当にその企業から届いたメールか」を直感的に見分ける手がかりの1つになります。もちろんBIMI表示だけで100%の安全を保証するものではありませんが、なりすましメールとの違いに気づくきっかけを増やすという点で、実用的な効果が期待できます。

図-6 ブランドロゴ表示の様子(一部画像加工済み)

BIMIという仕組み自体には、迷惑メールやフィッシングメールを防ぐ根本的な効果はありません。あくまでブランドアイコンを表示することでメールを参照するユーザに対してそのメールが正規の送信元から送信されているメールかどうかの判断を補助する役割を果たします。ただ、ブランドアイコンを表示するためにはDMARC認証をパスする必要があるため結果的に一定のセキュリティが担保されているような形になります。

BIMIは長年、internet draftという形でIETFで各文書が公開されています。メールに限らず、これらは時間を経てRFCに採番されることが多いですが、BIMIについてはメールを表示するアプリケーションの数も多く実装も様々であるため現在はすぐに明確な国際規格として制定せずに、メール関連技術における1つの指針として多くの関係者の間でinternet draftとして継続的に議論がされています。

昨今、迷惑メールやフィッシングメールの被害が急増していることもあり、多くの企業が送信ドメイン認証やBIMIへの対応を進めています。送信ドメイン認証技術を土台としたこの仕組みは、フィッシング対策とブランド保護の両面から、今後更に多くのメールサービスへ広がっていくことが見込まれます。特に、商標登録を必要としないCMCの普及が進めば、これまでコストの面でBIMI導入をためらっていた企業にとっても対応への敷居が下がり、結果として「ロゴが表示されていないメールの方が珍しい」という世の中になっていく可能性もあります。

IIJは今回、国内のプロバイダに先駆けてMailviewerへのBIMI表示機能を実装しました。今後もお客様がより安心してメールをご利用いただけるよう、なりすましメール対策フィルタやウイルスプロテクションといった既存のメールフィルタリング機能と併せて、セキュリティ関連機能の充実に取り組んでまいります。

  1. (注1)BIMI、「Mark Certificate Issuer Information」(https://bimigroup.org/vmc-issuers/)。
  2. (注2)Internet Infrastructure Review(IIR)Vol.55(https://www.iij.ad.jp/dev/report/iir/055/01.html)。
  3. (注3)IETF、"DomainKeys Identified Mail Signatures v2 (DKIM2)draft-ietf-dkim-dkim2-spec-04"(https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/)。
  4. (注4)IIJmio、「なりすまし対策強化のためのブランドロゴ表示機能(BIMI)導入について」(https://www.iijmio.jp/info/iij/1765171401.html)。

執筆者プロフィール

今村 侑輔

今村 侑輔( いまむら ゆうすけ)

IIJ ネットワークサービス事業本部 ネットワーク本部 アプリケーションサービス1部 xSPサービス課 課長代行。
2015年IIJ入社。メールサービスの運用業務に従事。IIJ Europeでの就業経験を活かし、日々グローバルに活躍中。

3. フォーカス・リサーチ
国内プロバイダ初、WebメールのBIMI表示対応〜IIJmioセーフティメールの安全対策〜

ページの終わりです

ページの先頭へ戻る