【IETFドラフト解説】従来のFBLはもう限界？「DKIM domain-based FBL」が目指す次世代の迷惑メール報告通知

「迷惑メール報告」の裏側を支えるFBL（Feedback Loop）システムに、今大きな標準化の波が訪れています。

現在IETF（Internet Engineering Task Force）で議論されている

draft-brotman-dkim-fbl（Email Feedback Reports for DKIM Signers）

は、従来IPアドレスと手動登録に頼っていたFBLの仕組みを、「DKIM署名＋DNSによる自動発見・送信ドメイン単位の通知」へと刷新しようとするプロジェクトです。

しかもこのドラフト、2026年に入ってから大きな節目を迎えています。

そもそもIETFとは何かという基礎から、技術的な仕組み、そして最新の標準化ステータス、日本のメール環境への実際の影響までを確認していきます。

そもそも「IETF」とは？

IETF（Internet Engineering Task Force）は、インターネットで使われる技術の「世界共通ルール（標準規格）」を検討している国際的なエンジニアコミュニティです。

私たちが普段使っているTCP/IP、SMTP、DKIMといったメールの基盤技術は、IETFでの議論を経て「RFC」と呼ばれる文書として標準化されてきました（なお、HTTP/HTTPSについてはIETFとW3Cが役割を分担しながら標準化を進めています）。

IETFでの標準化プロセスは大きく分けて、

1. 個人が提案する「個別ドラフト（Individual Draft）」
2. 特定テーマを扱う「ワーキンググループ（WG）」に採択されたドラフト
3. IESG（IETF全体の運営組織）の審査を経て発行される「RFC」

という段階を踏みます。今回のdraft-brotman-dkim-fblは、後述の通りこの②の段階に進みつつある状況です。

検討された背景：なぜ今「DKIMベースのFBL」なのか？

FBL（フィードバックループ）とは、ユーザーがメール画面で「迷惑メール報告」を押した際、その情報をメール送信者（Sender）へ通知し、リスト削除や配信改善に役立ててもらう仕組みです。

しかし、従来のFBLは現代のクラウド・SaaS中心のメール送信環境にそぐわなくなってきています。

従来のFBLが抱える限界

IPアドレス依存の限界（共有IP問題）

従来のFBLは「送信元IPアドレス」を基に通知先を特定していました。

しかし、SendGridやHubSpotなどの配信プラットフォームでは1つの共有IPから多数の企業のメールが送信されるため、IP単位では「どの顧客のメールが通報されたのか」を正確に特定できません。

手動登録・事前申請の手間

送信者は各メール受信事業者ごとに個別フォームから手動で申請する必要があり、仕様もバラバラで自動化が困難でした。

DKIM署名の破損リスク

FBL用の追跡ヘッダーを後から無理に差し込むことで、送信者が付与したDKIM署名が壊れてしまう（＝認証失敗になる）という問題も生じていました。

いったい世界の誰がどのように解決しようとしている？

主導者：Alex Brotman氏（Comcast）

提案者は米国大手通信・ISP事業者ComcastのAlex Brotman氏です。

IETFのDKIM関連メーリングリストに2023年9月、最初のドラフト（-00）を投稿したのが始まりです。受信側の巨大インフラを支える現場エンジニアが、業界全体のメール品質改善のために提案した点が特徴です。

解決メカニズム：DNSによる「自動発見（Discovery）」

draft-brotman-dkim-fblの核心は、送信者が「FBL報告の受け取り先」を自身のDNS（TXTレコード）で公開しておくことです。

【これまでの流れ】
送信者 ──(Webで個別申請)──> 各メール受信事業者 ──(独自形式でIP通知)──> 送信者

【ドラフト提案のフロー】
1. 送信者: DNSに _feedback._domainkey.example.com を公開
2. ユーザー: 迷惑メールボタンを押す
3. 受信側: メールからDKIM署名（d=, s=）を確認
4. 受信側: DNSを引いて送信者のFBL通知先を「自動発見」
5. 受信側: 指定された形式（mailto または HTTPS）で報告を自動送信

DNSレコードの設置場所は、DKIM署名のd=値をもとに次のように決まります（selector単位で分けたい場合はs=値も組み合わせます）。

_feedback._domainkey.example.com TXT
"v=DKIMRFBLv1;ra=<mailto:fbl@example.com>"

主なタグは以下の通りです。

• 事前申請が不要：DNSレコードを追加するだけでFBLが有効化される
• mailto／HTTPS両対応：メール（ARF形式）だけでなく、WebシステムへのHTTPS POSTでリアルタイムに報告を受け取ることも可能
• マルチ署名対応：SaaS（d=saas.com）と自社（d=company.com）の両方で署名している場合、両社にそれぞれ正確な報告を届けられる

なりすまし防止の仕組み：外部宛先の検証

見落とされがちですが重要なのが、報告の送付先（ra）が署名ドメインと異なる場合の検証手続きです。

例えばSaaS事業者が自社ドメイン宛にFBL報告を転送してほしいケースでは、送付先ドメイン側にも

「この送信元からの委託を受け入れる」

という確認用DNSレコードを追加で公開する必要があります。これにより、第三者が勝手に他社宛の報告フローを乗っ取るリスクを防いでいます。

3. 標準化はどこまで進んでいる？（2026年時点の最新状況）

ここが今回特に押さえておきたいポイントです。

• 2023年9月：Brotman氏が初版（-00）をIETFのDKIM関連メーリングリストに投稿
• 2024年：メール分野の小粒な提案を扱うワーキンググループ「MAILMAINT（Mail Maintenance）」がIETF内に発足
• 2025年：IETF会議（バンコク、モントリオール）のMAILMAINT WGセッションで継続的に議論
• 2026年：ドラフトは現在-06版まで更新され、IETF datatracker上のステータスは「Candidate for WG Adoption（WG採択候補）」

正式なRFC化にはまだ距離があります。

MAILMAINT WGの憲章では、標準化トラックの文書化には「独立した2者以上による実装コミットメント」や「相互運用性の実証」が要件とされており、Google・Microsoftなど主要メールプロバイダーの実装意向が今後の重要な焦点になりそうです。

4. 日本国内におけるリアルな影響と展望

日本国内のメール受信環境を見ると、携帯キャリアメールの利用が減少し、GoogleとMicrosoft）が個人・ビジネス双方で圧倒的なシェアを握っています。

この現状を踏まえると、本標準化の影響は以下のようになります。

 Google／Microsoftの独自ポータルからの脱却・ポータビリティ向上

これまでGoogleは「Gmail Postmaster Tools」、Microsoftは「SNDS」といった独自ポータルで配信品質データを提供してきました。

もし両社のような巨大プラットフォームがこのIETF標準（DKIM-FBL）を採用すれば、送信者は自社システムやWebhookで各社の迷惑メール報告を一括してリアルタイム受信できるようになる可能性があります。

SaaSを利用する国内企業の配信リスト健全化

日本国内でも多くの企業がクラウド型メール配信SaaSを利用しています。

「共有IPを使っているためFBL通知が届かず、自社の送信ドメインがいつの間にかレピュテーション低下を起こしていた」という事故を防ぎ、ドメイン単位での正確な不達・苦情管理が可能になります。

 DMARC必須化時代における運用統合

Google等の送信者ガイドライン強化により「DMARC」「DKIM」の設定は事実上必須となりました。

DKIMドメインを軸にしたFBLが普及すれば、「なりすまし対策（DMARC）」と「迷惑メール率の監視（FBL）」を同じドメイン設定の延長線上で一元管理できるようになる可能性があります。

最後に

draft-brotman-dkim-fblは、複雑化した現代のメールインフラを「IPからドメインへ、手動から自動へ」とアップデートしようとする試みです。

2023年の個人提案から始まり、2026年にはIETFの正式ワーキンググループでの採択候補という段階まで進んでおり、単なる「アイデア段階のドラフト」ではなくなりつつあります。

一方で、正式なRFC化にはまだ実装実証などのハードルが残っており、GoogleやMicrosoftをはじめとするグローバル巨大プラットフォームの動向とセットで、インフラエンジニアやSaaS開発者は今後の議論を注視しておくべきでしょう。

[参考リンク]
draft-brotman-dkim-fbl（IETF Datatracker）
MAILMAINT Working Group Charter