BIMI、そして未来
BIMI（Brand Indicators for Message Identification）の話については、以前 LT でやったので、今回は BIMI 以降のプロトコルスタックについて少し見てみたいと思います。BIMI の普及と前後して、「既存プロトコルの改訂（DMARCbis）」と「運用の必須化（ARC、MTA-STS）」という2つの動きが進行しているようです。
DMARCbis（DMARCの次世代改訂版）
現在IETF（Internet Engineering Task Force）で策定が進んでいる、DMARC（RFC 7489）の正式な改訂版です。
- 現状: 2025年後半から2026年にかけて「Proposed Standard（提案標準）」としてRFC化される見込み
- 変更点: 劇的な新機能追加ではなく、定義の明確化や、レポート形式（Aggregate Report/Failure Report）の仕様分離、プロトコルの整理が主眼
- 位置づけ: BIMIを利用するためにDMARCの「p=quarantine」以上が必須となった結果、DMARC自体の仕様をより堅牢にする必要が生じたため、実質的な「BIMI後の基盤整備」と言える
ARC (Authenticated Received Chain) - RFC 8617
厳密にはBIMIと同時期または少し前に策定されていますが、「BIMI導入後に必ず直面する課題の解決策」として、現在もっとも転送を行っている側で導入が急がれているプロトコルです。
- 背景: BIMI表示のためにDMARCを「p=reject/quarantine」に設定すると、メーリングリストや転送メールで認証が失敗し、メールが届かなくなる問題が発生
- 機能: 転送サーバー（GoogleやMicrosoftなど）が「認証結果のチェーン」をヘッダーに付与することで、転送経路上での認証切れを防ぐ
- 最新動向: 2024年のGoogle/Yahooの送信者ガイドライン強化に伴い、実質的な標準セットとして運用され始めている
MTA-STS (MTA Strict Transport Security) - RFC 8461
「送信元の身元保証（DMARC/BIMI）」の次に焦点が当たっているのが「経路の暗号化の強制」です。
- 機能: メールの配送経路（SMTP）において、TLS暗号化を強制し、中間者攻撃（MITM）を防ぐプロトコル。DNSにレコードを公開し、HTTPSでポリシーファイルを提供
- BIMIとの関係: 直接的な後継ではありませんが、Gmailなどの大手プロバイダは「DMARC/BIMIによるなりすまし対策」に続く次のセキュリティ要件として、このMTA-STSやDANE（DNSを用いた証明書検証）の推奨度を高めている
まとめ
BIMI以降、業界は「フルスペック実装」を標準化するフェーズ（IETF EMAILCOREワーキンググループの活動など）に移行しているようです。メール送信する方も色々と対策をしていかないと、ますます届かない環境になっているような気はします。BIMI自体は、証明書の料金もあり導入は容易ではないですが、できる範囲での対策はしていかなければならないとは思います。
| レイヤー | プロトコル | フェーズ |
|---|---|---|
| ブランド表示 | BIMI | 最新の可視化層 |
| ポリシー適用 | DMARC (→ DMARCbis) | 改訂作業中 |
| 転送対策 | ARC | 普及拡大期 |
| 経路暗号化 | MTA-STS / DANE | 推奨→必須化への過渡期 |
| 署名・認証 | DKIM / SPF | 基盤（Replay攻撃対策の議論中） |
参照
https://www.emailonacid.com/blog/article/email-deliverability/email-authentication-protocols/
https://datatracker.ietf.org/doc/draft-brotman-ietf-bimi-guidance/
https://dmarcwise.io/blog/upcoming-dmarc-bis
https://coreteamone.com/recent-attacks-using-google-oauth/
https://emailexpert.com/industry-news/antispam/navigating-the-future-of-email-security-a-deep-dive-into-ietfs-emailcore-applicability-statement/
https://www.mailgun.com/state-of-email-deliverability/chapter/email-authentication-requirements/
https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/
https://easydmarc.com/blog/what-is-dmarcbis/
https://www.duocircle.com/email-security/how-do-dkim-replay-attacks-happen
https://mailarchive.ietf.org/arch/browse/tls/
https://datatracker.ietf.org/doc/draft-kucherawy-dkim-anti-replay/02/
https://powerdmarc.com/ja/google-arc-sender-guidelines/
https://powerdmarc.com/introducing-dkim2/
https://baremail.jp/blog/2024/03/28/3779/
https://datatracker.ietf.org/doc/draft-ietf-emailcore-as/20/
https://proton.me/blog/dkim-replay-attack-breakdown
https://blastengine.jp/blog_content/arc/
https://datatracker.ietf.org/list/wg/
https://datatracker.ietf.org/doc/html/draft-ietf-dkim-replay-problem-00