BIMI（Brand Indicators for Message Identification）実装・運用ガイド

BIMI（Brand Indicators for Message Identification）は、メール送信者のブランドロゴをメールクライアント上で表示する仕組みです。企業のブランド認知向上とフィッシング防止に効果的な技術として注目されています。

BIMIとは

BIMIは、適切なメール認証を通過したメールの送信者情報欄に、企業のブランドロゴを表示する技術です。

主要な構成要素

BIMIレコード: DNS TXTレコード
SVGロゴファイル: HTTPS配信必須
VMC証明書: Verified Mark Certificate（オプションだが推奨）

メール認証技術の基礎知識

BIMIを理解するには、まずメール認証技術の基本を理解する必要があります。

Header From と Envelope From

メールには2種類の送信者情報があります：

📧 Header From（From ヘッダー）

From: "会社名" <info@example.com>

ユーザーに表示される送信者情報
RFC5322で定義されるメールヘッダー
返信先として使用
DMARC認証の対象ドメイン

📮 Envelope From（Return-Path）

Return-Path: <bounce-handler@mail-service.example.com>

SMTP配送レベルで使用される技術的な送信者情報
バウンスメールの送信先
SPF認証の対象ドメイン
ユーザーには通常見えない

実際の企業メール配信例

Header From: newsletter@company.com
Envelope From: bounces.marketing-system.company.com

理由:
- Header From: ブランドアイデンティティ維持
- Envelope From: バウンス処理の効率化

SPF（Sender Policy Framework）

目的: 送信元IPアドレスの正当性を検証

仕組み

DNS TXTレコードで許可IPを公開
受信サーバーがEnvelope FromドメインのSPFレコードを確認
送信元IPが許可リストに含まれるかチェック

SPFレコード例

example.com TXT "v=spf1 include:_spf.google.com include:amazonses.com -all"

検証方法

# SPFレコード確認
dig TXT example.com | grep "v=spf1"

# SPF検証（送信元IP: 1.2.3.4、ドメイン: example.com）
# → SPFレコードに1.2.3.4が含まれているかチェック

DKIM（DomainKeys Identified Mail）

目的: メールの内容改ざん検知と送信者認証

仕組み

送信時: 秘密鍵でメールにデジタル署名
受信時: DNS公開鍵で署名を検証
改ざん検知: ハッシュ値の比較で内容の完全性確認

DKIM署名例

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; 
    h=from:to:subject; bh=hash_of_body; b=signature_data

DNS公開鍵レコード

selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=public_key_data"

検証方法

# DKIM公開鍵確認
dig TXT selector1._domainkey.example.com

DMARC（Domain-based Message Authentication, Reporting & Conformance）

目的: SPF・DKIM認証結果に基づく統合的なメール認証

仕組み

Header FromドメインでDMARCレコードを確認
SPFまたはDKIMのいずれか一方が成功
アライメント（ドメインの一致）確認
ポリシーに従って処理（none/quarantine/reject）

DMARCレコード例

_dmarc.example.com TXT "v=DMARC1; p=quarantine; aspf=r; adkim=r; rua=mailto:dmarc@example.com"

パラメータ説明:

p=quarantine: 認証失敗時は迷惑メール扱い
aspf=r: SPF緩和アライメント（デフォルト）
adkim=r: DKIM緩和アライメント（デフォルト）
rua: 集約レポート送信先

アライメント（認証ドメインの一致）

DMARCの核心概念で、Header Fromドメインと認証成功ドメインの関係を評価します。

厳密アライメント（Strict）

Header From: info@company.com
SPF成功ドメイン: info@company.com  ← 完全一致が必要
結果: ✅ アライメント成功

緩和アライメント（Relaxed）- デフォルト

Header From: newsletter@company.com
SPF成功ドメイン: bounces.mail-service.company.com
組織ドメイン: company.com（両方とも）
結果: ✅ アライメント成功

実際の認証フロー例

Amazon メールの認証パターン

Header From: shipment-tracking@amazon.co.jp
Envelope From: bounces.amazon.co.jp
DKIM署名: d=amazon.co.jp

認証フロー:
1. SPFチェック: bounces.amazon.co.jp → ✅ PASS
2. DKIMチェック: amazon.co.jp → ✅ PASS
3. SPFアライメント: amazon.co.jp vs amazon.co.jp → ✅ 成功（緩和）
4. DKIMアライメント: amazon.co.jp vs amazon.co.jp → ✅ 成功（緩和）
5. DMARC判定: ✅ PASS
6. BIMI: ロゴ表示可能

認証技術の重要性

セキュリティ面

なりすまし防止: 偽装メールの検出
フィッシング対策: 悪意のあるメールのブロック
ブランド保護: 企業名を悪用したメールを防止

BIMI実装面

必須要件: DMARC認証の成功がBIMI表示の前提
信頼性向上: 認証されたメールのみロゴ表示
ユーザー体験: 安全なメールの視覚的識別

実装前の準備

1. 商標権確認

対象ロゴの商標登録状況確認
商標権者名の正確な把握
商標の有効期限確認

2. メール認証基盤整備

BIMI実装には、メール認証の適切な設定が必須です。

SPF レコード設定・検証

dig TXT example.com | grep "v=spf1"

DKIM 署名設定・検証

dig TXT selector._domainkey.example.com

DMARC ポリシー設定

_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

重要: p=none では BIMI は機能しません。必須設定は p=quarantine または p=reject です。

3. DMARC認証の仕組み（重要）

BIMI表示の必須条件:

SPF または DKIM のいずれか一方が認証成功
Header From ドメインとのアライメント成功

アライメントの種類:

厳密アライメント（aspf=s, adkim=s）: 完全一致が必要
緩和アライメント（aspf=r, adkim=r）: 組織ドメインレベルで一致すればOK（デフォルト）

実際の企業メール配信例:

Header From: marketing@example.com
Envelope From: bounces.mail-service.example.com
DKIM署名: d=example.com

→ 緩和アライメントで成功
  - Header From: example.com（組織ドメイン）
  - DKIM: example.com（組織ドメイン）
  - 一致 → DMARC PASS → BIMI表示可能

よくある誤解:

❌ Header From と Envelope From が完全一致する必要がある
✅ Header From と認証成功ドメインの組織ドメインが一致すれば十分

4. VMC証明書申請（DigiCert）

VMC証明書は任意ですが、信頼性とロゴ表示率向上のため推奨されます。

申請前準備

商標登録証明書
法人登記簿謄本
申請者身分証明書

発行期間・費用

発行期間: 通常2-4週間
年間費用: 約50-100万円

SVGロゴファイル準備

ファイル仕様

形状: 正方形（1:1比率）必須
ファイルサイズ: 32KB以下
形式: SVG（静的、アニメーション禁止）
外部リソース: 参照禁止

作成例

<!-- 良い例 -->
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
  <circle cx="50" cy="50" r="40" fill="#007bff"/>
  <text x="50" y="50" text-anchor="middle">LOGO</text>
</svg>

<!-- 悪い例: 外部リソース参照 -->
<image href="external-image.png"/>

Webサーバー設定

Apache設定例

<Files "*.svg">
    Header set Content-Type "image/svg+xml"
    Header set Cache-Control "public, max-age=86400"
    Header set Access-Control-Allow-Origin "*"
</Files>

<Files "*.pem">
    Header set Content-Type "application/x-pem-file"
    Header set Cache-Control "public, max-age=3600"
</Files>

Nginx設定例

location ~* \.svg$ {
    add_header Content-Type image/svg+xml;
    add_header Cache-Control "public, max-age=86400";
    add_header Access-Control-Allow-Origin *;
}

location ~* \.pem$ {
    add_header Content-Type application/x-pem-file;
    add_header Cache-Control "public, max-age=3600";
}

DNS BIMIレコード設定

VMC証明書を使用した設定例

default._bimi.example.com TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/company_inc_2025.pem"

TTL設定

初回設定: 3600秒（1時間）
DNS伝播待機: 48時間

実際の実装例

Amazon

default._bimi.amazon.com TXT "v=BIMI1;l=https://d3frv9g52qce38.cloudfront.net/amazondefault/order_1152306678_logo.svg;a=https://d3frv9g52qce38.cloudfront.net/amazondefault/amazon_web_services_inc_2025.pem"

Apple

default._bimi.apple.com TXT "v=BIMI1;l=https://www.apple.com/bimi/v2/apple.svg;a=https://www.apple.com/bimi/v2/apple.pem;"

Salesforce

default._bimi.salesforce.com TXT "v=BIMI1; l=https://www.salesforce.com/content/dam/web/en_us/www/images/home/bimi-salesforce-logo.svg;"

VMC証明書の特徴

通常のSSL証明書との違い

通常のSSL/TLS証明書

CN = yahoo.co.jp
CN = www.google.com
CN = example.com

目的: ドメインの所有権証明
検証: ドメイン制御の確認

VMC証明書（BIMI専用）

CN = "Amazon Web Services, Inc."
CN = "Apple Inc."
CN = "DigiCert, Inc."

目的: 商標権の証明
検証: 商標権の確認

実際の企業のVMC證明書例

Amazon

CN: "Amazon Web Services, Inc."
組織名: Amazon Web Services, Inc.
商標番号: 6178564

Apple

CN: "Apple Inc."
組織名: Apple Inc.
商標番号: 3679056

証明書の確認方法

# 通常のSSL証明書
openssl s_client -connect yahoo.co.jp:443 | openssl x509 -text | grep "CN ="
# 結果: CN = yahoo.co.jp

# VMC証明書（Apple）
curl -s https://www.apple.com/bimi/v2/apple.pem | openssl x509 -text | grep "CN ="
# 結果: CN = Apple Inc.

構築時の検証作業

1. DMARC認証確認

# テストメール送信して認証状況確認
echo "BIMI test" | mail -s "DMARC Test" test@gmail.com
# Gmail のヘッダー情報で DMARC Pass 確認

2. ファイルアクセス確認

# SVGファイルアクセステスト
curl -I https://example.com/bimi/logo.svg
# 期待値: HTTP/2 200, Content-Type: image/svg+xml

# 証明書ファイルアクセステスト
curl -I https://example.com/bimi/company_inc_2025.pem
# 期待値: HTTP/2 200

3. BIMIレコード確認

# DNSレコード確認
dig TXT default._bimi.example.com

4. 統合テスト

BIMI Inspector: https://bimigroup.org/bimi-generator/
MXToolbox: BIMI Lookup 機能使用
PowerDMARC: BIMI Checker 使用

定常運用時の作業

日次監視作業

1. メール認証成功率監視

# DMARCレポート確認
# - SPF成功率 > 95%
# - DKIM成功率 > 95%
# - DMARC成功率 > 90%

2. ファイル配信状況監視

# SVGファイルアクセステスト
curl -I https://example.com/bimi/logo.svg

# DigiCert証明書ファイルアクセステスト
curl -I https://example.com/bimi/company_inc_2025.pem

年次更新作業（VMC証明書）

DigiCertのVMC証明書は年次更新が必要で、ファイル名が変更されるため、DNSレコードの更新が必須です。

更新スケジュール例

証明書有効期限: 2025年12月31日の場合

10月1日: DigiCert へ更新申請
11月1日: 新証明書受領・検証
11月15日: DNS TTL短縮（3600秒→300秒）
12月1日: 新証明書配備・DNSレコード更新
12月8日: DNS TTL復旧（300秒→3600秒）
1月31日: 旧証明書ファイル削除

DNSレコード更新手順

# 旧証明書
default._bimi.example.com TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/company_inc_2025.pem"

# 新証明書に更新
default._bimi.example.com TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/company_inc_2026.pem"

障害対応

BIMIロゴ非表示時の対応手順

Step 1: 基本確認

# DMARCレポート確認（主要な原因）
# BIMIレコード確認
dig TXT default._bimi.example.com

# ファイルアクセス確認
curl -I https://example.com/bimi/logo.svg
curl -I https://example.com/bimi/company_inc_2026.pem

Step 2: 段階的復旧

DMARC認証率改善（SPF/DKIM設定見直し）
ファイル配信問題解決（Webサーバー復旧）
DNS設定問題解決（レコード修正）
48時間待機後、表示確認

メールクライアント対応状況

クライアント	対応状況
Gmail	完全対応
Yahoo Mail	対応
Outlook	限定対応
Apple Mail	未対応

よくある質問

Q: Header From と Envelope From は完全一致が必要ですか？

A: 不要です。BIMI/DMARC仕様では以下が正しい理解です：

Header From と 認証成功ドメイン の組織ドメインが一致すればOK
Envelope From の完全一致は不要
SPF または DKIM のどちらか一方が成功すれば十分

Q: 実際の企業メール配信での成功例は？

A: 以下のような配信でもDMARC認証が成功し、BIMI表示されます：

Header From: newsletter@company.com
Envelope From: bounces.mailservice.company.com
DKIM署名: d=company.com

→ 緩和アライメント（デフォルト）で成功
  組織ドメイン「company.com」で一致

Q: Gmail自身はBIMIを実装していますか？

A: Gmailは受信側として他社メールのBIMIロゴを表示しますが、送信側として自社メールにBIMIは実装していません。

Q: 大手企業でBIMIを導入していない理由は？

A:

VMC証明書の高額な年間費用（数十万円）
ROI（投資対効果）の測定困難
技術リソースの優先度

Q: BIMIロゴ表示の条件は？

A: 以下の両方が必要です：

ロゴファイルがHTTPSで正常配信されている
メール認証（特にDMARC）が成功している

Q: DMARC認証の詳細確認方法は？

A: 実際の企業のDMARCレコードを確認できます：

# 企業のDMARCレコード確認例
dig TXT _dmarc.amazon.co.jp
# 結果: "v=DMARC1; p=quarantine; pct=100; rua=mailto:report@dmarc.amazon.com"

# aspf, adkim 記載なし = 緩和アライメント（デフォルト）

Q: SPF・DKIM・DMARCの設定確認方法は？

A: 以下のコマンドで各認証技術の設定を確認できます：

# SPF確認
dig TXT example.com | grep "v=spf1"

# DKIM確認（セレクターが必要）
dig TXT selector1._domainkey.example.com

# DMARC確認
dig TXT _dmarc.example.com

# 実際のメールヘッダーで認証結果確認
grep "Authentication-Results:" email.eml

Q: メール認証が失敗する主な原因は？

A: よくある失敗原因と対策：

SPF失敗:

送信IPがSPFレコードに含まれていない
SPFレコードの構文エラー
DNS伝播の遅延

DKIM失敗:

公開鍵と秘密鍵の不一致
セレクター名の間違い
署名対象ヘッダーの改変

DMARC失敗:

SPF・DKIM両方の認証失敗
アライメントの失敗
DMARCレコードの設定ミス

Q: アライメントが失敗する場合の対処法は？

A: アライメント設定の見直しが必要です：

# 現在の設定確認
dig TXT _dmarc.example.com

# 緩和アライメントに変更（推奨）
_dmarc.example.com TXT "v=DMARC1; p=quarantine; aspf=r; adkim=r; rua=mailto:dmarc@example.com"

# 厳密アライメントが必要な場合
_dmarc.example.com TXT "v=DMARC1; p=quarantine; aspf=s; adkim=s; rua=mailto:dmarc@example.com"

まとめ

BIMIは企業のブランド認知向上とメールセキュリティ強化に有効な技術です。特に重要なポイント：

DMARC認証が必須: p=quarantine または p=reject 設定が必要
アライメントは柔軟: 組織ドメインレベルでの一致で十分
SPFまたはDKIM: どちらか一方の成功で認証可能
VMC証明書は任意だが推奨: 信頼性と表示率向上のため
年次更新作業: DigiCert証明書更新時はDNSレコード更新も必要
定常監視: DMARC成功率とファイル配信状況の監視が重要

実装には技術的な複雑さと運用コストが伴いますが、正しい理解に基づいて構築すれば、企業の複雑なメール配信環境でも十分に機能する技術です。

※この記事は2025年6月時点の情報に基づいています。BIMI仕様や各社対応状況は変更される可能性があります。