APRFとは？ 新しいメール配信率フィードバック基準の解説

現在の状況：APRFは IETFの提案草案として検討中ですが、送信者はすでに実際の日次レポートを受信可能です。Comcast（Xfinity）は、APRF DNSレコードを公開している送信者に対して、本番環境のベータ版レポートを積極的に送信しています。一方、Googleなど他の共同執筆プロバイダーは、まだレポートの生成機能を有効化していません。

組織が一斉メールを送信し始めて以来、配信責任者は根本的な盲点に直面してきました。それは、メールボックスプロバイダーがメッセージを受け入れた後、それが実際にどこに届いたのかを誰も確実に把握できないという点です。これまで、送信者は、人工的なシードリストによるテストや、Google、Microsoft、Yahooなどの各プロバイダーのポストマスターダッシュボードを個別に確認することで、受信トレイへの到達状況について推定値を組み立ててきました。各プロバイダーは互換性のない形式で異なる指標を提供しているため、送信者には統一された信頼できる情報源が一つも存在しない状況が続いています。

新たに提案された仕様は、この長年にわたる業界の課題を解決することを目的としています。APRF（Aggregate Performance Reporting Format）として知られるこの新しいプロトコルにより、メールボックスプロバイダーは、メッセージの配信状況や受信者のエンゲージメントに関する標準化された日次レポートを作成し、送信者に直接送信できるようになります。これにより、送信者はシードリストによる推定値に頼るのではなく、認証済みのメールストリームがどのように分類されたか、また実際の受信者がそれらにどのように反応したかを確認できるようになります。

ここでは、APRFとは何か、その検出メカニズムがどのように機能するか、DMARCなどの既存の標準規格との違い、そして今すぐレポートの収集を開始するために最初のDNSレコードを公開する方法について、詳しく解説します。

APRF（Aggregate Performance Reporting Format）とは何ですか？

APRF（Aggregate Performance Reporting Format）は、メールの配信状況やユーザーの反応について、送信者に構造化された機械可読形式のフィードバックを提供することを目的として提案されたメール報告プロトコルです。従来のプロトコルがゲートウェイでの認証や接続の失敗について報告するのに対し、APRFは、受信サーバーによってメッセージが受理された後の状況に完全に焦点を当てています。

この仕様は現在、IETFのインターネットドラフト「draft-brotman-aggregate-performance-reporting-00」で定義されています。2026年3月17日に公開され、スタンダード・トラックへの移行が予定されているこの文書は、電子メール業界のベテラン3名によって共同執筆されました：

• アレックス・ブロットマン（コムキャスト）
• トム・コーベット（Iterable）
• エミル・グスタフソン（Google）

IETF Datatrackerの公式ステータスページによると、最初の-00リビジョンの公式有効期限は2026年9月18日となっています。 個人による提案として、APRFは依然として初期の評価段階（「I-D Exists」）にあり、IETFワーキンググループによる正式な採択やRFCとしての発行はまだ行われていません。しかし、大手ISP、主要な企業向けESP、そしてGoogleが共同執筆者となっていることから、APRFは近年提案された配信可能性に関する取り組みの中でも最も重要なもののひとつとなっています。

用語に関する注記：電子メール技術以外の分野では、頭字語「APRF」は、医療や生物学の研究において、「Advanced Platelet-Rich Fibrin（高度血小板濃縮フィブリン）」または「Acute-Phase Response Factor（急性期反応因子）」を表す用語として頻繁に使用されます。一方、電子メールのセキュリティ、インフラ、および配信可能性の文脈において、APRFは「Aggregate Performance Reporting Format（総合パフォーマンス報告フォーマット）」仕様のみを指します。

APRF、DMARCレポート、フィードバックループ：実際には何が違うのか？

APRFが企業の電子メール戦略においてどのような位置づけにあるかを理解するには、範囲、データ形式、識別キー、配信方法という4つの主要な側面から、APRFと既存のレポート機能とを比較検討することが役立ちます。

認証とパフォーマンス：その根本的な違い

DMARCの集計レポートとAPRFの主な違いは、認証とパフォーマンスのどちらを重視するかという点に集約されます：

1. DMARCは認証に関するものです。DMARCの集計レポートは、「このメールは、私の公開ドメイン名を使用してSPFおよびDKIMによる認証を適切に通過したか、また、不正な送信元が私のブランドをなりすまそうとしたか」という疑問に答えるものです。
2. APRFはパフォーマンスを重視しています。APRFレポートは、「メールが認証を通過して受信された後、メールボックスプロバイダーはそれをどこに配置し、受信者はそのメールに対してどのような操作を行ったのか」という疑問に答えるものです。

APRFは、DMARCの集計レポートや従来の苦情フィードバックループに取って代わるものではありません。むしろ、それらを補完する役割を果たします。DMARCはなりすましからブランドアイデンティティを保護する一方、APRFはメールボックスのアルゴリズムが送信者のレピュテーションをどのように評価しているかを可視化します。

さらに、APRFはGoogle Postmaster Toolsなどのプロバイダーのダッシュボードとは異なります。こうしたダッシュボードでは、手動でのログインや、特定のプロバイダーに合わせてカスタマイズされたAPI連携が必要となります。一方、APRFは、ベンダーに依存しないオープンな標準を確立しており、パフォーマンス指標を構造化されたJSONペイロードとして、直接受信トレイに配信します。

APRF報告書にはどのような内容が掲載されているのでしょうか？

APRFレポートは、参加しているメールボックスプロバイダーによって1日1回生成されます。各レポートは、UTC基準の24時間（00:00:00 UTCから23:59:59 UTCまで）を網羅しています。レポートは、JSON形式のメール添付ファイルとして、application/json または圧縮された application/gzip のいずれかの形式で送信されます。

JSONペイロードは、「ヘッダー」と「ボディ」という2つの異なるセクションに分かれています。

1. ヘッダーのメタデータ

ヘッダーには、報告期間、レポートを発行したプロバイダー、および送信者のDKIM IDに関する管理情報が含まれています：

• バージョン：APRF仕様のバージョン（現在は1）。
• 出典：報告元のメールボックスプロバイダーの名称または識別子（例：Comcast）。
• dkim_domain:送信時の署名で検証されるDKIMドメイン（d=）。
• dkim_selector:プロバイダによって照合された特定のDKIMセレクタ（s=）。
• report_start / report_end:24時間のUTC期間を正確に定義するUnixエポックタイムスタンプ。
• contact_info：報告主体が提供した管理用メールアドレスまたはURL。
• sdi_used:サブストリームのセグメンテーションのために、署名者定義識別子（Signer-Defined Identifiers）が解析されたかどうかを示します。

2. メトリック・ファミリー（レポート本文）

このデータセットには、2つの主要な指標グループに分類された集計値が含まれています：

分類指標（配置）

分類メトリクスでは、受信プロバイダーが受理したメッセージをどこにルーティングしたかを追跡します：

• 受信トレイ：メインの受信トレイフォルダに配信されたメッセージ。
• 不要なメッセージ：スパム、迷惑メール、または一括受信フォルダに振り分けられたメッセージ。
• プロモーション：セカンダリのプロモーションタブまたはフォルダに分類されたメッセージ。
• 転送済み：受信者のメールボックスルールによって自動的に転送されたメッセージ。

エンゲージメント指標（ユーザーの行動）

エンゲージメント指標は、配信後に実際の受信者が行ったアクションを集計したものです：

• ポジティブ：開封、リンクのクリック、スパムフォルダからのメッセージの移動（レスキューアクション）、メッセージを「重要」としてマークするなど、好ましいユーザーの行動。
• ネガティブ：「スパムとして報告」をクリックしたり、メッセージを読まずに削除したり、購読を解除したりするなど、ユーザーによる好ましくない行動。
• 中立：アーカイブ、カスタムフォルダへの保存、手動での転送など、評価を伴わない操作。

3. きめ細かな追跡のための署名者定義識別子（SDI）

デフォルトでは、APRFはDKIMセレクタレベルで集計データを報告します。しかし、大企業では、単一のDKIMセレクタの下で複数の種類の電子メールを送信することがよくあります。この問題に対処するため、この草案には「Signer-Defined Identifiers（SDI）」と呼ばれるオプション機能が盛り込まれています。

DNSレコードにsdiタグを宣言することで、メールボックスプロバイダーに対し、DKIM署名に含まれている特定のカスタムヘッダー（X-Campaign-IDやSigner-Infoなど）を検査するよう指示できます。これにより、プロバイダーはこれらのサブ識別子ごとに日別の分類およびエンゲージメント指標を細分化し、最大4階層までのネストされたセグメンテーションに対応します。これにより、組織は、効率的なDKIMキーアーキテクチャを維持しつつ、トランザクション通知とマーケティングキャンペーンを個別に評価することが可能になります。

APRF JSON ペイロードの注釈付き例

以下は、draft-brotman-aggregate-performance-reporting-00 仕様に基づいて構成された、例示用の JSON レポートです。

[
  {
    "header": {
      "version": 1,
      "source": "Comcast/Xfinity",
      "dkim_domain": "example.com",
      "dkim_selector": "s1024",
      "report_start": 1773705600,
      "report_end": 1773791999,
      "contact_info": "[email protected]",
      "sdi_used": "none",
      "extra_info": "https://postmaster.comcast.net/aprf-info"
    },
    "body": [
      {
        "classification": {
          "inbox": 45000,
          "unwanted": 120,
          "promotional": 0,
          "forwarded": 15
        },
        "engagement": {
          "positive": 14200,
          "negative": 18,
          "neutral": 850
        }
      }
    ]
  }
]

APRFの仕組み：DNS検出からレポート配信まで

APRFは、DMARCやTLS-RPTといった確立されたプロトコルをモデルとした、DNSベースの検出フローを採用しています。レポート機能はメッセージの署名と直接連動しているため、メールボックスプロバイダーは、ポータルを個別に設定することなく、ユーザーのレポート設定を把握することができます。

ステップバイステップの流れ

1. メールの送信：お客様のインフラストラクチャからは、有効なDKIM署名が付与された送信メールが送信されます。
2. 署名の検証：受信プロバイダはメールを受信し、DKIM署名を検証して、ドメイン（d=example.com）とセレクタ（s=s1024）を抽出します。DNSクエリ：プロバイダは、s1024._aprf._domainkey.example.com にあるTXTレコードについてDNSにクエリを実行します。
3. レコードの解析：プロバイダーはTXTレコードを解析し、必須のv=APRFv1タグを確認するとともに、ruaタグで定義された宛先メールアドレスを取得します。
4. 集計と配信：今後24時間にわたり、プロバイダーはそのセレクターに関する掲載およびエンゲージメントデータを集計します。UTC基準の1日の終了時に、JSONレポートを生成し、SMTP経由で指定されたruaアドレスに送信します。

プライバシー保護措置と処理量の閾値

個々のユーザーのプライバシーを保護するため、APRF草案では、メールボックスプロバイダーに対して送信量抑制の閾値を適用することを明示的に推奨しています。ある日に送信者がプロバイダーに対してごく少数のメッセージしか送信しない場合、生のパフォーマンス指標から、送信者が特定の個人の行動を推測できる可能性があるからです。

APRFのプライバシーフレームワークに基づき、プロバイダーは、送信量が少ないストリームについては、レポートを完全に非表示にするか、ノイズ追加型バケッティングアルゴリズムを適用します。特定のメールボックスプロバイダーへの1日あたりのメッセージ送信量が、そのプロバイダーのプライバシー閾値を下回った場合、その日のレポートは表示されません。

今すぐAPRFレポートの収集を始める方法

APRFは現時点では、確定したRFC規格ではなく、IETFの草案として検討中ですが、Comcast（Xfinity）は、DNS TXTレコードを公開している送信者向けに、本番環境（ベータ版）で毎日APRFレポートを生成しています。

APRFレコードの公開にはほんの数分しかかからず、ソフトウェアのインストールやメールインフラの変更も一切必要ありません。以下の4つの手順に従って、レポートの受信を開始してください。

ステップ 1: 有効な DKIM セレクタを特定する

ご自身のドメインから最近送信されたメッセージのメールヘッダーを確認してください。DKIM-Signatureヘッダーを見つけ、セレクタ（s=）とドメイン（d=）をメモしておいてください。

たとえば、ヘッダーに「d=example.com」と「s=s1024」が表示されている場合、APRFレコードは次のURLでホストされます：s1024._aprf._domainkey.example.com

ワイルドカードのサポート：数十ものセレクタを管理しており、それぞれに対して個別のレコードを作成することを避けたい場合、この仕様ではアスタリスク（*）を使用して包括的なレコードを公開することができます：*._aprf._domainkey.example.com

受信プロバイダーは、まず特定のセレクターレコードを確認します。それが見つからない場合は、ワイルドカードレコードに切り替えます。

ステップ 2：専用の報告用メールボックスを設定する

受信するレポートを集約するための専用メールボックスまたはメールエイリアスを作成してください（例：[email protected]）。レポートには自動生成されたJSONファイルが含まれているため、専用のエイリアスに送信することで、メインの受信トレイが毎日の添付ファイルで溢れかえるのを防ぐことができます。

ステップ 3: DNS TXT レコードを公開する

DNS管理コンソールにログインし、以下のパラメータを使用して新しいTXTレコードを追加してください：

• ホスト／名前：s1024._aprf._domainkey.example.com（ワイルドカードの場合は *._aprf._domainkey.example.com）
• レコードタイプ：TXT
• TTL：3600秒（1時間）
• 値：v=APRFv1；rua=mailto:[email protected]；

キャレット（^）を区切り文字とする「X-Campaign-ID」という名前のヘッダーについて、Signer-Defined Identifiers によるサブストリーム追跡を有効にしたい場合は、値を次のように構成してください：

v=APRFv1; rua=mailto:[email protected]; sdi=X-Campaign-ID,^;

ステップ4：公開の確認

DNS 検索ツールまたはコマンドラインユーティリティ（dig や nslookup）を使用して、新しいレコードがパブリックに解決されることを確認してください：

dig TXT s1024._aprf._domainkey.example.com +short

現時点での現実的な見通し

APRFレコードを導入する際には、現実的な運用上の期待値を設定することが重要です：

• ベータ版での運用状況：現在、主要なメールボックスプロバイダーの中で、ベータ版として本番環境向けのAPRFレポートを実際に生成しているのはComcast（Xfinity）のみです。
• Googleの役割：Googleはこの草案の共同作成者であり、標準化されたパフォーマンス報告に対する強い長期的な関心を示しています。ただし、Gmailでは現在、APRFレポートは生成されていません。送信者は、Gmailの現在の要件について引き続き「Gmailメール送信者ガイドライン」を参照してください。
• 公開にかかる費用はゼロ：現在、APRFレコードを公開するのに費用は一切かからず、パフォーマンス上のオーバーヘッドも発生しません。公開されると、お客様のドメインは自動的にComcastからのレポートを受け取り始めるほか、今後この規格を採用するその他のプロバイダーからのレポートも受け取るようになります。

APRFが重要な理由（そして、それが解決できない問題）

APRFに対する業界の反応は概ね好意的です。Spam Resourceでの分析において、配信率の専門家であるアル・アイバーソン氏は、APRFが人為的なシードリストによる推定値ではなく、「実際のユーザー行動に基づく、リアルで集計されたデータ」を提供している点を高く評価しました。アイバーソン氏は、APRFを、既存のプラットフォームと連携して運用状況をより明確に可視化する補完的なツールとして位置づけました。

主なメリット

7. 実際の受信者データ：シードリストは、現実的なエンゲージメント履歴を持たない人工的なアカウントに依存しています。APRFは、実際のユーザーアカウントにおける実際の配信結果を反映しています。

8. 標準化されたオープンフォーマット：送信者は、複数のプロバイダーからのJSONメトリクスを単一の社内分析パイプラインに取り込むことができるため、さまざまなポスマスターポータル向けにカスタムWebスクレイパーやAPIコネクタを構築する必要がなくなります。

9. サブストリームの粒度：SDIタグを使用することで、エンジニアリングチームは、メインのDKIMキーアーキテクチャを分割することなく、特定のトランザクションメッセージタイプに影響を及ぼす配信に関する問題を特定することができます。

既知の制限事項

その利点があるにもかかわらず、APRFには明確な限界がある：

• 本日のプロバイダー対応状況：ベータ版ではComcastのみがレポートを生成しているため、APRFでは現時点ではグローバルな配信状況の可視化は提供されていません。
• 診断用の根本原因データがない：APRFレポートには、一定割合のメッセージがスパムフォルダに振り分けられたことが示されていますが、その理由は明記されていません。問題がIPのレピュテーションの低下、URLのブロックリスト登録、あるいはスパムフィルターのコンテンツトリガーによって引き起こされたものなのかは、このレポートからは判断できません。
• 仕様草案の変更：これはIETFの現行草案であるため、タグの構文およびJSONスキーマのフィールドは、最終的な標準化に至るまで変更される可能性があります。

認証は依然として前提条件である

APRFの指標は、受信サーバーがメールを受け入れた後にのみ算出されます。送信メッセージが基本認証のチェックに失敗した場合、受信サーバーがゲートウェイでそのメッセージをブロックする可能性があり、その結果、配信レポートは意味をなさなくなります。

配信率に関するフィードバックを確認する前に、主要な認証設定が適切に構成されていることを確認してください：

• すべての正規の送信元において、有効なDKIMレコードを設定してください。
• ドメインがDMARCによって保護されており、SPFおよびDKIMの署名が整合していることを確認してください。
• 一元化されたDMARCレポート分析ツールを使用して、認証の状態や、強制ポリシー（p=reject）への移行状況を確認します。

今すぐAPRF記録を公開すべきか？

はい、大量のメールを送信する組織にとってはそうです。貴社がComcast/Xfinityの個人向けメールアドレス宛に大量のメールを送信している場合、APRFレコードを公開することで即座にメリットが得られます。他の主要プロバイダーがこの標準に参画する前に、実際の毎日の配信データにアクセスできるようになり、自動化されたレポート作成の仕組みを構築することができます。

送信量が少なかったり、純粋にB2B向けの送信者である場合、APRFレコードの公開は任意ですが、推奨されます。プライバシーに関する基準により、日次レポートを即座に受け取れない場合もありますが、ワイルドカードTXTレコード（*._aprf._domainkey.example.com）の公開には5分もかからず、セキュリティ上のリスクは一切なく、業界全体での採用が進むにつれて、ドメインが対応できる状態を確実に保つことができます。

よくあるご質問

メールの中で「APRF」とは何の略ですか？

APRFは「Aggregate Performance Reporting Format」の略称です。これは、メールボックスプロバイダーからメール送信者に対して、標準化された日次のパフォーマンスデータおよび受信者のエンゲージメントデータを提供することを目的として提案されているオープンスタンダードです。

APRFはすでにIETFの公式標準となっているのでしょうか？

いいえ。APRFは現在、有効な個別インターネットドラフト（draft-brotman-aggregate-performance-reporting-00）です。IETFのワーキンググループによって正式に採択されたり、RFC規格として公開されたりしてはいません。

APRFはDMARCの集計レポートとどう違うのですか？

DMARCの集計レポート（RUA）は、表示されている「From」ドメインに対する電子メール認証（SPFおよびDKIMの検証）の適合度を測定します。APRFは、DKIMの署名ドメインおよびセレクタに対する受信後のパフォーマンス（受信トレイへの到達率およびユーザーエンゲージメント）を測定します。

現在、どのメールプロバイダーがAPRFに対応していますか？

現在、本番環境でベータ版のAPRFレポートを送信しているメールプロバイダーは、コムキャスト（Xfinity）のみです。Googleはこの仕様の策定に共同で携わりましたが、Gmailでは現時点ではAPRFの生成に対応していません。

APRFレポートを受信するには、DKIMが必要ですか？

はい。APRFディスカバリーレコードは、DKIMドメインキーネームスペース（_domainkey）の下で公開されており、レポートは送信メッセージの署名に使用されるDKIMセレクタに直接紐付けられています。

APRFは、従来のフィードバックループ（FBL）に取って代わるものなのでしょうか？

いいえ。従来のフィードバックループでは、個々のユーザーがメッセージをスパムとしてマークすると、ほぼリアルタイムでARFレポートが送信されます。APRFでは、メールストリーム全体における配信状況やユーザーエンゲージメントをまとめた日次集計指標を提供します。

次の手順：ドメインの基盤を確認する

APRFはメッセージの配信状況に関する貴重な知見を提供しますが、その有効性は健全なメールインフラに完全に依存しています。認証レコードの設定に誤りがあったり、整合性が取れていなかったりすると、配信指標が記録される前に、メールボックスプロバイダーによってメッセージが拒否されてしまいます。

ドメインがAPRFに対応できるよう、以下の点をご確認ください：

• すべての送信メールストリームが、有効でアラインメントが正しいDKIMキーで署名されていることを確認してください。
• PowerDMARC ドメインアナライザーを使用してDMARC ポリシーを確認し、認証の整合性を検証してください。
• 参加プロバイダーがサービスを開始し次第、パフォーマンスに関するフィードバックを受け取れるようになるため、キャッチオールAPRFレコード（*._aprf._domainkey.yourdomain.com）を公開してください。