結論から言えば：機能しません。メールの開封確認は、主要なメールクライアントのいずれにおいても、安定して動作しません。「より優れた代替手段」として各種メールトラッキングツールが売り込むピクセルトラッキングも同じです。この記事では、何が壊れているのか、なぜそうなのか、そして本当に必要なデータを得るにはどうすればいいかを具体的に解説します。
メールの開封確認の仕組み
仕組み自体はシンプルで、RFC 8098 が公開されて以来、変わっていません。メールクライアントが送信メッセージに Disposition-Notification-To ヘッダーを付加します。受信側のクライアントがこのヘッダーを検出し、受信者に確認を促します。受信者が承認すれば、送信者に通知が返されます。
仕様には明記されています。開封確認のリクエストは「完全に任意」です。受信者は常に拒否でき、拒否したこと自体が送信者に伝わることもありません。フォールバックも、リトライも、無言の確認もありません。拒否された場合、あるいはメールクライアントがリクエストを無視した場合、送信者には何も届きません。
Gmail の開封確認——実態のすべて
無料の Gmail アカウント
対応していません。作成ウィンドウにオプションはなく、隠し設定も Labs 拡張機能も存在しません。Google が対応を追加する予定もありません。無料の Gmail アカウントでは、開封確認をリクエストすることはできません。
Mailtrack や Streak などのサードパーティ拡張機能はネイティブの開封確認を使用しているわけではなく、ピクセルトラッキングを利用しています。こちらにも固有の問題があります（後述）。
Google Workspace アカウント
開封確認はデフォルトで無効です。管理者が管理コンソール → アプリ → Google Workspace → Gmail → ユーザー設定 → メールの開封確認 から明示的に有効にする必要があります。
設定には 4 つの段階があります：
- 完全に無効（デフォルト）
- 内部のみ——同じ組織内のメンバー間でのみ機能
- 内部＋許可リスト——内部メンバーに加え、最大 100 件の特定外部アドレスを対象に設定可能
- すべてのメールアドレス——任意の受信者に対してリクエスト可能。ただし受信者には常に確認プロンプトが表示され、拒否することができる
有効にした場合、デスクトップでの操作手順は以下のとおりです：
- ウェブブラウザで Gmail を開く（デスクトップのみ——iOS / Android のモバイルアプリでは非対応）
- 新規メールを作成する
- 作成ウィンドウ下部の「その他のオプション」（3点メニュー）をクリックする
- 「開封確認をリクエスト」を選択する
- メールを送信する
受信者側には「返信する」または「後で」という選択肢が表示されます。「後で」を選ぶと、次回メールを開いたときに再度プロンプトが表示されます。リクエストが拒否されたことは、送信者には一切通知されません。
開封確認はメールごとに設定する必要があります。グローバルのデフォルト設定はありません。BCC やメーリングリストには対応していません。また、送信後にリクエストを追加することもできません。
すべてがうまくいった場合——管理者が開封確認を有効にし、リクエストを忘れずに設定し、受信者も承認した場合——でも、わかるのはメールが開かれたという事実だけです。添付ファイルが開かれたかどうか、どれくらい読まれたか、どの部分が重要だったかは、一切わかりません。
Outlook の開封確認——2025 年のモバイル対応を含む全容
Outlook は主要なメールクライアントの中で最も充実した開封確認の実装を持ちます。一方で、最も断片的でもあります。
Classic Outlook for Windows
最も完成度の高い体験を提供します。メールごとのリクエストのほか、グローバルのデフォルト設定（オプション → 開封確認 → 「送信したすべてのメッセージに開封確認を要求する」）も利用可能です。管理者はグループポリシーや Exchange ルールを使って確認処理を自動化できます。
New Outlook for Windows および Outlook on the web（OWA）
メールごとの開封確認は機能します。ただし、グローバルのデフォルト設定はなくなりました——Classic からの後退として広く報告されています。毎回手動でリクエストする必要があります。
Outlook モバイル（iOS / Android）
2025 年春のアップデートで、Outlook モバイルが開封確認と配信確認の両方に対応しました。メールを作成し、「+」メニューから「開封確認」アイコンをタップして種類を選択するだけです。これは最近追加された機能で、多くの競合記事ではまだモバイル非対応と記載されています。
開封確認と配信確認の違い
混同されがちですが、本質的に異なります：
- **配信確認（DSN）**はサーバーサイドの処理です。メールサーバーがメッセージを受信者のメールボックスに届けたことを確認します。受信者の操作は不要です。
- **開封確認（MDN）**はクライアントサイドの処理です。受信者のメールアプリがメッセージの開封時に通知を送信しますが、受信者は常に拒否できます。
配信確認でわかるのはメールが届いたこと、開封確認でわかるのはメールが開かれたこと。どちらも、その中身については何も教えてくれません。
管理者向けの設定
テナント全体に適用できる単一のキルスイッチはありません。エンタープライズ IT チームは通常、以下を組み合わせて対応します：
- Exchange トランスポートルール——
Disposition-Notification-Toヘッダーを削除するのが最も効果的な一括対応策 - Set-MailboxMessageConfiguration——OWA 設定向け
- グループポリシー——Classic デスクトップ向け
- リモートドメイン設定——外部送信者の処理向け
トランスポートルールによる対応は、組織全体での自動拒否に最も近い方法です。多くのエンタープライズ IT チームがこれを採用しています。受信者の組織がサーバーレベルで開封確認ヘッダーを削除している場合、リクエストは誰の目にも触れることなく、静かに破棄されます。
結論は Gmail と同じです： 最善のケースでも、わかるのはメールが開かれたという事実だけ。コンテンツについては何もわかりません。
Apple Mail——最大の問題
Apple Mail は開封確認のリクエストに対応していません。しかし本当の問題は、他者のトラッキングに対して Apple Mail が何をするかにあります。
Mail Privacy Protection（MPP）
2021 年 9 月に iOS 15 および macOS Monterey で導入された Mail Privacy Protection は、ユーザーが実際にメールを開いたかどうかに関わらず、すべてのメールコンテンツをバックグラウンドでプリフェッチします。画像が読み込まれ、トラッキングピクセルが発火し、送信者には誤った「開封」シグナルが届きます。
通信は 2 つの独立したリレープロキシを経由します。最初のプロキシはユーザーの IP アドレスを把握できますが、メールの内容は見えません。2 番目のプロキシはコンテンツを見られますが、誰のものかはわかりません。この二重リレー構造により、送信者が IP アドレスを使って開封と受信者を紐づけることは不可能になっています。
Apple Mail ユーザーの間での採用率はおよそ 97%——デフォルトで有効になっており、ほとんどのユーザーは無効にしません。
Link Tracking Protection（iOS 17 以降）
iOS 17 以降、Apple Mail は URL から UTM パラメーターやクリックトラッキング ID を除去するようになりました。これにより、開封トラッキングに加えてクリックアトリビューションも機能しなくなります。
市場シェア
Litmus のメールクライアント市場シェアデータによると、2026 年 1 月時点で Apple Mail は全メール開封の約 47% を占めています（11 億件の開封実績に基づく）。この数字は過去 12 か月で 46〜67% の間で推移しています。
最低値でも、MPP のプリフェッチにより全メール開封の約半分は信頼性がありません。これが「開封確認が機能しない」から「ピクセルトラッキングも機能しない」へとつながる理由です。
メールのピクセルトラッキング——「より優れた代替手段」も機能しない
多くの記事はここで終わり、「開封確認は不安定なのでピクセルトラッキングツールを使いましょう」と推奨します。私たちはピクセルトラッキングについても正直に話します。
ピクセルの仕組み
メール本文に <img> タグを使って 1×1 ピクセルの透明な画像を埋め込みます。受信者のメールクライアントがメールをレンダリングして画像を読み込むと、ピクセルがサーバーからフェッチされます。サーバーはそのリクエストを記録し、IP アドレス、ユーザーエージェント、タイムスタンプ、固有の受信者識別子を保存します。
この仕組みは 2000 年代初頭から変わっていません。そして対抗措置も着実に進化しています。
Apple Mail Privacy Protection
前述のとおり、MPP はすべての画像をプリフェッチします。すべてのメールが「開封済み」に見えてしまいます。Apple Mail がメール開封の約 47% を占めることを考えると、あなたの「開封」の約半数は幽霊リードかもしれません。
Gmail の画像プロキシとレピュテーションベースのブロック
2013 年以降、Gmail はすべての画像を Google のプロキシサーバー経由でルーティングしており、受信者の IP アドレスやデバイス情報を隠蔽しています。開封トラッキング自体は技術的に機能しますが、位置情報やデバイスデータは失われます。
2024 年 8 月以降、Gmail は評判の低い送信者からの画像を完全にブロックするようになりました。表示される警告バナーには「このメッセージの画像は非表示になっています。このメッセージは迷惑メールの可能性があります。」と記載されます。これは一律のブロックではなく、送信者の評判、SPF/DKIM/DMARC 認証、スパム報告率、エンゲージメント指標に基づく機械学習による判断です。
評判の良い正規のマーケティングメールへの影響は基本的にありません。しかし、開封トラッキングが最も必要な冷たいアウトリーチメールは、不均衡に影響を受けます。画像がブロックされると、トラッキングピクセルは読み込まれず、開封は完全に検知されません。
企業のセキュリティスキャナー
Barracuda、Mimecast、Proofpoint、Microsoft Defender for Office 365 はいずれも、受信メールのスキャン時に画像をプリフェッチし、リンクを先回りしてクリックします。これにより、人間が見る前に偽の開封とクリックが生成されます。
Microsoft Defender の Safe Links 機能は、Microsoft 365 のエンタープライズ市場シェアを考えると特に影響が大きいです。偽の開封を生成することが確認されているツールには、Cisco Secure Email、Check Point Avanan、Trend Micro、Sophos、CrowdStrike なども含まれます。
ボットの特徴は予測可能です。配信から 60 秒以内の開封やクリック、複数リンクへのサブ秒単位の連続クリック、既知のセキュリティベンダーの IP レンジからのリクエスト。記録されたケースでは、あるキャンペーンのエンゲージメントの 80% がボットトラフィックだったことが判明しています。
セキュリティボットがビュー数を水増しする仕組みは Why Your Deck Analytics Are Wrong（英語）でも解説しています——デッキのビューを偽装するボットは、メール開封も偽装します。
AI インボックスエージェント——2026 年の新たな問題
Google Gemini などの AI アシスタントが受信メールをスキャンして要約を生成したりアクションを提案するようになり、トラッキングピクセルを含む埋め込み画像を読み込みます——人間がメールを見ることなく。
これは現在どのメールトラッキングツールも確実にフィルタリングできていない、偽の開封の新たな発生源です。「午前 3 時 47 分に開封」という通知は、ユーザー本人ではなく Gemini がスキャンした結果かもしれません。
2026 年時点での画像ブロックのデフォルト設定
主要なメールクライアントの現状：
- デフォルトで画像をブロック： Outlook デスクトップ（Classic および新バージョン）、Thunderbird、Proton Mail、Tuta（旧 Tutanota）
- デフォルトで画像を表示（プロキシ経由）： Gmail、Apple Mail、Yahoo Mail、Outlook モバイル
本質的な限界
ピクセルトラッキングが完璧に機能したとしても——Apple MPP もなく、ボットもなく、画像ブロックもない状態であっても——わかるのはメールが開かれたということだけです。添付ファイルが開かれたかどうかはわかりません。添付ファイルを開いてもピクセルは発火しませんし、添付ファイルを開かなくても発火することがあります。
ピクセルトラッキングが答えるのは、封筒に関する問いであって、手紙の中身についてではありません。
追跡しているのは封筒であって、手紙ではない
誰もメールが開かれたかどうかを本当に気にしているわけではありません。気にしているのは、見込み顧客が提案書を読んだかどうか、候補者がオファーレターを確認したかどうか、クライアントが契約書に目を通したかどうかです。
メールトラッキング——開封確認もピクセルも——が答えるのは「封筒を見たか？」という問いです。ドキュメントトラッキングが答えるのは「手紙を読んだか、どのページに線を引いたか？」という問いです。
実際に機能する方法：メールではなくコンテンツをトラッキングする
解決策は漸進的な改善ではなく、構造的な変革です。提案書をメールに添付して開封確認を待つのではなく、トラッキングリンクで共有しましょう。受信者がリンクをクリックすると、ドキュメントがサーバーから読み込まれます。そのサーバーはすべてを記録できます：誰がいつ開いたか、各ページにどれくらい時間をかけたか、何をクリックしたか、再訪したかどうか。
これは回避策ではありません。この記事で取り上げたすべての制限を根本から回避する、まったく異なるアプローチです。Apple Mail は、まだクリックされていないドキュメントをプリフェッチできません。セキュリティボットはエンゲージメント分析を水増ししません。トラッキングがメール層ではなくコンテンツ層に存在するため、画像のブロックは何の影響も与えません。
添付ファイルからトラッキングリンクへのワークフロー移行については Can You Track If Someone Opened Your Email Attachment?（英語）で詳しく解説しています。提案書に特化したトラッキングについては How to See Who Viewed Your Sales Proposal（英語）をご覧ください。信頼性の高いトラッキングツールを検討中なら、提案書トラッキングソフトウェア比較で主要な選択肢を並べて比較しています。現在DocSendをお使いの場合は、DocSendの代替ツール比較をご覧ください。
メールトラッキングがまだ有効なケース
メール開封トラッキングが無意味だと言いたいわけではありません。個人の重要な意思決定を判断する目的では無意味だということです。
大量アウトリーチとキャンペーン
数百〜数千通のメールにわたる集計開封率は、ノイズがあっても方向性を示す指標として有効です。火曜日送信で 34%、木曜日送信で 22% の開封率であれば、絶対値がボットや Apple MPP によって水増しされていたとしても、火曜日のほうが良いタイミングである可能性が高いでしょう。
Mailchimp や HubSpot などのマーケティングオートメーションツールは、件名の A/B テスト、送信時刻の最適化、リストの健全性モニタリングにキャンペーンレベルの開封率を使用しています。この規模になると、ノイズは平均化され、十分な有用性が生まれます。
使い分けの基準
- 集計メール指標はキャンペーン最適化に有効
- 個別メールのトラッキングは重要な意思決定には不向き
火曜日のバッチが木曜日より良かったかを知りたい場合、メール開封トラッキングで十分です。木曜日の電話の前に「Acme Corp の Jane があなたの提案書を読んだか」を知りたい場合は役に立ちません。
業界の動向
Apple の MPP が転換点でした。開封の半数が信頼できなくなった時点で、この指標は権威を失いました。返信率、クリック率、コンバージョンが、ほとんどのメールプラットフォームでの主要エンゲージメント指標として開封率に取って代わっています。メールインフラの変化について詳しくは Email Deliverability in 2026（英語）をご覧ください。
メールトラッキング手段の比較
| 機能 | 開封確認（MDN） | ピクセルトラッキング | トラッキング付きドキュメントリンク |
|---|---|---|---|
| メールが開かれたかを知る | 場合による——受信者が拒否できる | 場合による——Apple MPP、Gmail、セキュリティスキャナーでブロックされる | 非対応——ドキュメントをトラッキング（メールではない） |
| 誰が開いたかを知る | あり（確認通知が返ってきた場合） | おおよそ——プロキシで隠蔽された IP / ユーザーエージェント | あり——名前とメールアドレスで特定 |
| いつ開いたかを知る | あり（確認通知のタイムスタンプ） | あり（ピクセルが読み込まれた場合） | あり——リアルタイム通知 |
| どのくらい時間をかけたかを知る | なし | なし | あり——ページごとの閲覧時間 |
| 何を読んだかを知る | なし | なし | あり——ページごとのエンゲージメント |
| リンクのクリックを知る | なし | なし | あり——クリックトラッキング |
| 無料 Gmail での動作 | なし | 低下——プロキシ、レピュテーションブロック | あり |
| Apple Mail での動作 | なし | なし——MPP がすべてをプリフェッチ | あり |
| 受信者がブロック可能か | あり——通知なしで拒否可能 | あり——画像ブロック | なし |
| 法的ステータス（EU） | おおむね許容 | 議論が増加——CNIL ドラフトガイダンスが個別同意を要求する方向 | 標準的なデータ処理 |
よくある質問
Gmail でメールが読まれたかどうかを確認できますか？
確実にはわかりません。無料アカウントは開封確認に対応していません。Workspace アカウントは管理者による有効化が必要で、デスクトップウェブのみ対応し、受信者は通知なしで拒否できます。ピクセルトラッキング拡張機能は機能しますが、Gmail の画像プロキシ（位置情報やデバイス情報が得られない）やレピュテーションベースの画像ブロック（冷たいアウトリーチメールはシグナルがゼロになる場合がある）によって精度が低下します。
Gmail と Outlook の間で開封確認は機能しますか？
不安定です。クロスプラットフォームでの開封確認の処理は、クライアントのバージョン、管理者設定、受信者の構成によって異なります。Gmail Workspace ユーザーが開封確認をリクエストしても、Outlook の受信者が自動拒否または無視することがあります。送信者はまったく返答を受け取れないことが多く、その理由も一切わかりません。
メールのトラッキングピクセルは合法ですか？
議論が増えています。フランスの CNIL は 2025 年 6 月に画期的なドラフトガイダンスを公表し、トラッキングピクセルを ePrivacy 指令のクッキーと同等に扱うよう提案しました。個人レベルの開封トラッキングには、メール受信への同意とは別に、明示的な個別同意が必要になる可能性があります。英国の ICO も、トラッキングピクセルにはクッキーと同じルールが適用されると述べています。1 対 1 のビジネスメールのピクセルを対象とした執行措置はまだ出ていませんが、規制の方向性は明確です。これは法的アドバイスではありません。
Mailtrack でメールが 10 回開封されたと表示されるのはなぜですか？
セキュリティスキャナーとボットによるものです。Microsoft Defender、Proofpoint、Mimecast、Barracuda などの企業向けメールセキュリティツールは、受信メールのスキャン時に画像を先読みしてリンクを先回りでクリックするため、それぞれが独立した「開封」イベントを生成します。Google Gemini のような AI インボックスエージェントもスキャン中に画像を読み込みます。「3 か国から 15 回の開封」は、1 つのセキュリティスキャナーと 1 つの AI エージェントによるものかもしれません。
メールの添付ファイルをトラッキングする方法はありますか？
ありません。メールの添付ファイルはローカルにコピーされるものであり、送信者とつながる仕組みはありません。詳しい説明と代替アプローチについては Can You Track If Someone Opened Your Email Attachment?（英語）をご覧ください。
Superhuman、Hey、その他の開封トラッキング機能を持つメールクライアントはどうですか？
Superhuman（2025 年に Grammarly が約 8 億 2500 万ドルで買収）は引き続き「Read Statuses」を提供しています——いつ、何回、どのデバイスでメールが開かれたかをピクセルベースで表示する機能です。位置情報トラッキングをめぐる2019 年の論争（位置情報機能はその後恒久的に削除）を受け、この機能は現在デフォルトでオフになっています。
Hey.com はまったく逆のアプローチを取っています。受信メールからすべてのトラッキングピクセルを積極的に削除し、どのサービスがトラッキングを試みたかを特定してユーザーに知らせます。
どちらも同じ事実を示しています：基盤となるピクセルの仕組みは同じであり、Apple MPP、Gmail プロキシ、セキュリティスキャナーといった前述の制限と無縁ではありません。UI が洗練されても、信頼性の問題は解決しません。