メールの開封確認ヘッダーの中身｜要求の1行と、返る通知の読み方

メールの開封確認は、送るメールのヘッダーに「Disposition-Notification-To: 返してほしいアドレス」という1行を入れて要求します。受け取った側のメールソフトがこの1行を見つけると、「開封確認を送信しますか」と尋ね、承認されたときだけ「displayed（表示された）」と書かれた通知が送り主に返ります。つまり、ヘッダーの1行は「お願い」にすぎず、相手のメールソフトや相手自身が断れば、何も返ってきません。

この記事では、要求の1行の書き方と、返ってくる通知の中身をどう読むかを、規格書であるRFC 8098と、Google・Microsoftの公式ヘルプで確かめた内容をもとに順に並べます。後半では、応募や問い合わせの受付をしている人が「相手が読んだか」を知りたい場面で、開封確認のヘッダーよりも確実な方法を扱います。確かめた日付はいずれも2026年10月8日です。

開封確認を要求するヘッダーは1行だけ

開封確認の正式な名前は「メッセージ配送状態通知」で、英語ではMessage Disposition Notification、略してMDNと呼ばれます。仕様を決めているのは2017年2月に出たRFC 8098で、それ以前のRFC 3798を置き換えています。

要求の書き方はとても短く、ヘッダーに次の1行を足すだけです。

Disposition-Notification-To: 受付窓口 <[email protected]>

コロンの後ろに書くのは、通知を受け取りたいメールアドレスです。RFC 8098では、この行は1通のメールに1回までしか書けないと定めています。宛先を複数書くこと自体はできますが、その場合は受け取った側で必ず本人の確認を取るか、通知を送らないことになっています。

規格書は、この1行の性格をはっきり書いています。

The presence of a Disposition-Notification-To header field in a message is merely a request for an MDN. The recipients' user agents are always free to silently ignore such a request. 出典: rfc-editor.org

訳すと「この行があることは、通知を求めているというだけのこと。受け取る側のメールソフトは、いつでも黙って無視してよい」という意味です。送る側がどれだけ丁寧にヘッダーを書いても、返ってくるかどうかは相手側で決まります。

古いメールソフトの中には、Return-Receipt-ToやX-Confirm-Reading-Toといった別名のヘッダーを使うものもありました。現在、メールソフトの「開封確認を要求する」の印を付けたときに実際に入るのは、ほぼDisposition-Notification-Toです。プログラムからメールを送るときに自分でヘッダーを書く場合も、この1行を足せば足ります。

受け取った側で何が起きるか

ヘッダーの1行を受け取ったメールソフトの動きも、RFC 8098が細かく決めています。受付の仕事で「なぜ返ってこないのか」と悩む前に、ここを知っておくと話が早くなります。

まず、規格は「通知を送る前に、受け取った本人の同意を取ることを強く勧める」と書き、さらに「既定の値は、通知を送らないにするべき」としています。目的は受け取る人のプライバシーを守ることです。多くのメールソフトで「開封確認を送信しますか」という確認が出るのはこのためです。

次に、自動で送ってはいけない条件があります。

・Disposition-Notification-Toのアドレスと、Return-Pathのアドレスが違うとき ・Return-Pathがメールに無いとき ・Disposition-Notification-Toに違うアドレスが2つ以上書かれているとき

これらに当たる場合は、本人の確認を取れたときだけ送り、取れなければ送らないと決まっています。送信サービスを経由して送るメールでは、Return-Pathが配信サービスの戻り先アドレスになることが多く、Disposition-Notification-Toと食い違います。このとき、受け取った側では自動送信の設定にしていても確認が出るか、通知が出ません。

もう1つ、同じ受信者からの通知は1通までです。いちど「表示した」と返したあとは、そのメールを削除しても次の通知は出ません。また、通知のメールそのものには開封確認の要求を入れてはいけないとされています。通知に通知が返り続けることを防ぐための決まりです。

GmailとOutlookでの実際の挙動は次のとおりです。

Gmailの場合

Googleの管理者向けヘルプには、開封確認は個人のGmail（gmail.com）アカウントでは機能しないと書かれています。使えるのは職場や学校のアカウント、つまりGoogle Workspaceで、しかも組織の管理者が管理コンソールで許可している場合だけです。管理者は、送信を無効にする、組織内と許可リストの外部アドレスだけに限る、送るたびに本人に確認する、すべての宛先に許可する、のいずれかを選びます。すべての宛先に許可した場合は、受け取った人が毎回承認する設定が常に有効になります。

さらに、Gmailからグループやメーリングリストあてに開封確認は送られないとも書かれています。採用窓口の共有アドレスがGoogleグループになっている組織では、そこに届いた要求には通知が返りません。

Outlookの場合

Microsoftのサポートページによれば、従来のOutlookでは、新規メールの作成画面で「オプション」メニューの「追跡」グループにある「開封確認メッセージの要求」に印を付けると、このヘッダーが入ります。すべての送信メールに付けたいときは、「ファイル」メニューの「オプション」から「メール」を開き、「追跡」の欄にある「受信者がメッセージを表示したことを確認する開封確認メッセージ」に印を付けます。新しいOutlookとOutlook on the webでは、「設定」の「メール」から「メッセージ処理」を開き、「開封確認」の欄で、要求を受け取ったときの応答のしかたを選べます。受け取る人がここで送らない扱いを選んでいれば、何も返りません。

同じページは、配信確認メッセージ（相手のメールサーバーに届いたことの確認）と開封確認メッセージ（相手がメッセージを表示したことの確認）を分けて説明しています。配信確認は届いたことしか表さず、読まれたかどうかは分かりません。

どちらの場合も、返ってこないことは「読まれていない」ことを意味しません。読まれたが承認されなかった、承認の表示が出なかった、そもそも対応していないメールソフトだった、のどれなのかは、送った側からは区別がつきません。

返ってくる通知の読み方

承認された場合に返ってくる通知は、普通のメールとは中身の形が違います。RFC 8098の例を、項目ごとに読んでいきます。

通知のメールは、Content-Typeが「multipart/report; report-type=disposition-notification」になっていて、中身は3つの部分に分かれています。

1つ目は人が読むための文章です。規格の例では「1995年9月19日に送られた件名○○のメッセージは表示されました」と書かれ、続けて「これは、メッセージが読まれた、または理解されたことを保証するものではありません」と添えられています。メールソフトはこの部分を本文として表示します。

2つ目が機械が読むための部分で、Content-Typeが「message/disposition-notification」です。ここに次の項目が並びます。

3つ目には、元のメッセージやそのヘッダーが入ることがあります。入れるかどうかは任意です。

Dispositionの行がいちばん大事

通知の中で読むべきなのは、Disposition の1行です。規格の例では次のように書かれています。

Disposition: manual-action/MDN-sent-manually; displayed

スラッシュの前は「その操作が人の手か自動か」です。manual-action なら人が操作したこと、automatic-action ならメールソフトが自動で処理したことを表します。スラッシュの後ろは「通知を人が承認して送ったか、自動で送ったか」で、MDN-sent-manually か MDN-sent-automatically のどちらかです。セミコロンの後ろが結果で、規格が定めているのは displayed（表示された）、deleted（削除された）、dispatched（印刷や転送など表示以外で処理された）、processed（自動で処理された）の4つです。

受付の仕事で気にするのは、ほとんどの場合 displayed かどうかです。ただし、displayed は「画面に表示された」ことしか表しません。プレビュー欄に一瞬出ただけでも displayed になるメールソフトがあり、逆に、通知を送らない設定の人がじっくり読んでいても何も返りません。

送ったメールとの突き合わせ方

通知を受け取ったら、Original-Message-ID の値を、自分の送信済みフォルダにあるメールの Message-ID と照らし合わせます。件名は相手のメールソフトが書き換えることがあるので、確実なのは Message-ID です。Gmailなら、送信済みのメールを開き、返信アイコンの横の「その他」から「メッセージのソースを表示」を選ぶと、Message-ID を含む詳細ヘッダーが新しいウィンドウに出ます。Googleのヘルプでも、この手順で詳細ヘッダーを表示し、「クリップボードにコピー」で写せると案内しています。

ヘッダーを自分の目で確かめる手順

開封確認の要求がきちんと入っているか、相手に届いたメールにどう見えているかは、ヘッダーを開けば確かめられます。

送る前に自分あてで試す

1. 開封確認を要求する設定で、自分の別のアドレスあてにメールを1通送る
2. 受け取った側でヘッダーを開く（Gmailなら「その他」から「メッセージのソースを表示」）
3. Disposition-Notification-To の行があるかを探す
4. 同じヘッダーの Return-Path の行と、アドレスが一致しているかを見る

4つ目が食い違っていると、前の節で書いたとおり、相手の側では自動の通知が出ません。送信に外部の配信サービスやメール送信の仕組みを使っている場合は、ここで差が出やすくなります。

返ってこないときに確かめる順番

通知が返ってこないときは、次の順で原因を絞れます。

・自分の送ったメールにヘッダーが入っているか（送信済みのソースで確かめる） ・相手が個人のGmailではないか（個人のGmailは対応していない） ・相手の宛先がグループやメーリングリストではないか ・Return-Path とアドレスが食い違っていないか ・相手のメールソフトの設定で「送信しない」になっていないか（これは送った側からは分からない）

最後の項目は確かめようがありません。開封確認のヘッダーは、ここで行き止まりになります。

開封確認の行と一緒に見ておきたいヘッダー

ヘッダーを開くと、開封確認の1行のほかにたくさんの行が並んでいて、どれを見ればよいか迷います。開封確認がらみで意味のある行は、次の5つに絞れます。

・From：送り主として表示される名前とアドレス。受け取った人が目にするのはここです ・Return-Path：届かなかったときにエラーが戻る先。開封確認を自動で返すかどうかの判断に使われます ・Message-ID：そのメール1通ごとに付く固有の番号。返ってきた通知の Original-Message-ID と照らし合わせる相手です ・Disposition-Notification-To：開封確認の要求先 ・Received：どのサーバーを経由して届いたかの記録。下から上へ読むと、送り出したサーバーから受け取ったサーバーまでの順になります

このうち、送った側の設定で変わりやすいのは Return-Path です。自社のメールサーバーから直接送るときは From と同じアドレスになることが多い一方、外部のメール配信サービスを通すと、配信サービス側の戻り先アドレスが入ります。この場合、受け取った側では「要求先と戻り先が違う」と判断され、自動の通知は出ません。開封確認を使いたい送信と、配信サービスを通す送信を、同じ設計で考えないことが大切です。

もう1つ、ヘッダーに Authentication-Results という行があれば、SPF、DKIM、DMARCという送信元の確認の結果が書かれています。ここが fail になっているメールは、相手の側で迷惑メールに振り分けられていることがあり、その場合は開封確認どころか、本文も読まれていない可能性があります。通知が返ってこないことが続くときは、開封確認の設定より先に、この行を確かめる価値があります。

開封確認を付ける前に、窓口で決めておくこと

それでも開封確認を使う場面はあります。社内の決裁の依頼、取引先との契約書の送付など、相手が承認してくれる関係で、記録として残したいときです。窓口で使うなら、次の3つを先に決めておくと混乱が減ります。

1つ目は、付ける対象です。すべての送信に付けると、受け取る人は毎回確認を求められ、断ることに慣れてしまいます。「書類の提出期限を知らせるメールだけ」のように、対象を絞ったほうが承認されやすくなります。

2つ目は、返ってこなかったときの次の手です。通知が返らないまま期限の前日になったら電話をする、本文の期限を過ぎたら再送する、といった手順を決めておかないと、通知を待つだけで日が過ぎます。

3つ目は、通知の置き場所です。担当者個人の受信箱に届いた通知は、その人が休むと誰も見ません。共有の窓口なら、通知を受け取ったら該当する案件の記録に「何日に表示の通知あり」と書き写す、という決まりが要ります。この書き写しが続かないことが、窓口で開封確認が使われなくなるいちばんの理由です。

応募や問い合わせの受付で、開封確認を当てにしない理由

採用の連絡、助成金の書類の不備連絡、面接の日程の案内。受付の仕事では「相手が読んだか」を知りたい場面がたくさんあります。そこで開封確認を付けたくなりますが、受付の仕事には向かない理由が3つあります。

1つ目は、返ってこないことが何も意味しないことです。ここまで見てきたとおり、返らない理由は相手の設定、メールソフト、アカウントの種類、送信経路など複数あり、送った側からは区別できません。「通知が返ってこないから読んでいない」と判断して催促すると、相手にとっては読んだのに催促された形になります。

2つ目は、受け取る側に手間と不快感を与えることです。開封確認の要求を受け取った人には「送信しますか」と確認が出ます。応募者の立場では、断ってよいのか迷う問いです。採用の担当からは、開封確認付きのメールを嫌がる応募者がいるという話がよく聞かれます。

3つ目は、通知が担当者個人の受信箱に戻ることです。共有の窓口で複数人が対応していると、通知を受け取った人しか「読まれた」ことを知りません。誰に何を送り、何が返ってきたかが、窓口全体の記録に残りません。

代わりに使える方法

相手が読んだかを確かめたいなら、次のほうが確実です。

・本文の中で返事を求める。「◯日までに、このメールにご返信ください」と期限を書く ・確認のためのリンクを置き、押されたかで判断する ・メール配信の仕組みが持つ開封とクリックの計測を使う

1つ目の「返事を求める」は、書き方で返ってくる率が変わります。「ご確認ください」で終わる文面は、読んだ人も返事をしません。返事をしてほしいときは、何を、いつまでに、どう返せばよいかを1文で書きます。

例：面接日程のご案内を受け取られましたら、10月15日（木）までに、このメールへ「受け取りました」とだけご返信ください。日程の変更をご希望の場合は、ご都合のよい日時を2つお書き添えください。

この形なら、返事が来た人は「読んだ」と確定し、来ない人は期限の翌日に電話で確かめる、という切り分けができます。開封確認の通知と違い、相手のメールソフトや設定に左右されません。返事の手間も1行で済むため、応募者の負担も小さく抑えられます。

2つ目の「確認のリンク」は、書類のダウンロードや日程の選択など、相手にしてほしい行動そのものをリンクにする方法です。リンクが押されたことが、そのまま読まれた証拠になります。受付の側では、押した人と押していない人を名簿で分けられるようにしておくと、催促の対象がすぐに分かります。

3つ目の計測は、ヘッダーの1行ではなく、本文に見えない小さな画像を入れて、その画像が読み込まれたかで判断する方式です。受け取った人に確認の画面は出ません。ただし、画像を読み込まない設定のメールソフトや、プライバシー保護のために画像を先に取得する仕組みがあるため、開封の数字は目安として扱い、リンクのクリックや返信と合わせて見るのが安全です。

受付の窓口で「送った」と「読まれた」を記録する

受付の仕事で本当に必要なのは、通知の1通1通よりも、「誰に、いつ、何を送り、相手がどう反応したか」が、応募や問い合わせの1件ごとに残っていることです。開封確認の通知を担当者の受信箱で受け取っても、それをどの応募の記録に貼るかは手作業になります。

応募や問い合わせをフォームで受けている窓口なら、届いた1件の画面から直接メールを送り、送った履歴と開封・クリックの結果をその1件の記録に残す、という形にできます。回答管理のできるフォームの中には、届いた回答ごとに担当者とステージ（対応状況）を持たせ、その画面からメールを送ると、送信の履歴が時系列で残るものがあります。できることのページでは、一件を開くと回答、対応履歴、メモ、メールの送信がひとつの画面にまとまる様子と、一斉送信での開封とクリックの計測が説明されています。料金のページによれば、開封・クリック計測付きの一斉メールは月額7,800円（税抜）のチームプランからで、フォームの数と回答の数はどのプランでも無制限です。詳しくは料金で確かめられます。

この形の利点は、開封の数字が「誰の、どの連絡か」と結び付いて残ることです。面接の案内を送った10人のうち、開いていない3人にだけ電話をする、といった判断が、担当者の記憶ではなく記録から出せます。採用の受付での使い方は採用の応募受付に、問い合わせ窓口での使い方は問い合わせの受付にまとめられています。

いま使っているフォームがGoogleフォームで、返信をGmailから個別に送っている場合は、開封確認がそもそも個人のGmailでは使えない点も合わせて考える必要があります。どこまでをフォームの側に任せるかは、Googleフォームとの比較が判断の材料になります。

開封確認のヘッダーは、1対1のやりとりで、相手が同じ組織の中にいて、承認してもらえる関係のときには役に立ちます。外部の応募者や問い合わせの相手に対しては、ヘッダーの1行で相手の行動を知ろうとするより、返事の期限を書き、送った記録を1件ごとに残すほうが、取りこぼしが確実に減ります。

Q1. 開封確認を要求するヘッダーは何と書けばよいですか？

ヘッダーに「Disposition-Notification-To: 通知を受け取りたいメールアドレス」の1行を入れます。RFC 8098で定められた書き方で、1通のメールに1回までしか書けません。メールソフトの「開封確認を要求する」に印を付けると、この行が自動で入ります。受け取った側は要求を無視してもよいことになっているため、必ず返ってくるわけではありません。

Q2. 個人のGmailで開封確認は使えますか？

使えません。Googleの管理者向けヘルプには、開封確認は個人のGmail（gmail.com）アカウントでは機能しないと書かれています。職場や学校のGoogle Workspaceアカウントで、組織の管理者が許可している場合だけ、要求と返信ができます。グループやメーリングリストあてにも通知は送られません。

Q3. 開封確認の通知が返ってこないのは読まれていないからですか？

そうとは限りません。受け取った人が承認しなかった、メールソフトが対応していない、個人のGmailだった、Return-Pathと要求先のアドレスが食い違っていて自動で送られなかった、などの理由でも返りません。送った側からはどれなのか区別できないため、返ってこないことを根拠に催促するのは避けたほうが安全です。

Q4. 通知の「displayed」は、相手が読んだという意味ですか？

画面に表示されたという意味で、読んで理解したことまでは表しません。RFC 8098の例文にも、通知はメッセージが読まれた、または理解されたことを保証するものではないと書かれています。プレビュー欄に表示されただけでも displayed になるメールソフトがあるため、返信や期限付きの確認と合わせて判断するのが確実です。