メールの開封確認ヘッダーを調べる人は、たいてい何かがうまくいっていない状態にいます。開封確認を付けたのに返ってこない、逆に身に覚えのない開封確認が届いた、あるいは受信したメールのヘッダーに見慣れない行が並んでいて意味が分からない。どの場合も、答えはヘッダーの数行に書かれています。開封確認は魔法ではなく、決められた書式の文字列をやり取りしているだけの仕組みです。ここでは要求を出す側の1行から、返ってくる通知の中身、そして読み違えやすい点までを順に見ていきます。
開封確認を要求しているのは、ヘッダーのたった1行
メールで開封確認を要求するとき、送信されるメッセージに足されるのは1行だけです。Disposition-Notification-To: [email protected] という形の行がそれに当たります。この仕組みを定めた RFC 8098 は、次のように書いています。
A request for the receiving user agent to issue message disposition notifications is made by placing a Disposition-Notification-To header field into the message. 出典: rfc-editor.org
同じ節には、このヘッダーは1通のメッセージに1回までしか置けないと書かれています。複数の宛先に別々の開封確認を返させるような使い方は、規格上できません。
開封確認そのものは MDN と略されます。Message Disposition Notification の頭文字で、日本語にすると「メッセージの処理結果の通知」に近い意味です。「開封」という日本語訳が定着していますが、規格が扱っているのは開封に限らず、表示、転送、処理、削除といった処理の結果全般です。この違いは後で効いてきます。
RFC 8098 は2017年2月に公開された標準化過程の文書で、それ以前の RFC 3798 を置き換えています。古い解説記事が RFC 3798 を参照していることがありますが、現在の規格は 8098 のほうです。ヘッダー名や基本の考え方は引き継がれているので、書式そのものが変わったわけではありません。
もうひとつ、要求側が付けられるヘッダーに Disposition-Notification-Options があります。こちらは、返す通知にどのような情報を含めるかを細かく指定するためのもので、実務で目にする機会はほとんどありません。日常的に扱うのは、最初に挙げた1行だけだと考えて差し支えありません。
似た名前のヘッダーが複数ある理由
メールのヘッダーを眺めていると、開封確認に関係しそうな行がいくつも見つかることがあります。Return-Receipt-To、X-Confirm-Reading-To、Confirm-Reading-To といった名前です。これらは規格で定義されたものではありません。
理由は歴史にあります。開封確認に相当する機能は、インターネットのメールが普及する前から、社内向けのメールシステムや別の規格の中に存在していました。RFC 8098 の冒頭にも、この機能が X.400 や独自の社内システムでよく見られたものだという説明があります。各社がそれぞれ独自のヘッダーを実装し、後から標準が決まったという順番なので、古い名前が残っているわけです。
実務上の意味はこうです。Disposition-Notification-To は標準に定義があるので、多くのメールソフトが認識します。X- で始まる名前のヘッダーは、そもそも独自拡張であることを示す接頭辞で、相手のソフトが知らなければ無視されます。開封確認が返ってこないという相談の中には、送信側のソフトが独自ヘッダーしか付けていなかったというものが混じっています。
Return-Receipt-To は、開封ではなく配送の通知を求めるものとして実装されてきた経緯があり、こちらも標準ではありません。配送の成否を伝える仕組みは別の規格で定義されていて、送信元に返る不達通知がそれに当たります。開封確認と配送確認は、規格の上でも別々に扱われています。混同すると、「サーバーまでは届いた」という通知を「読まれた」と読み違えることになります。
自分が使っているメールソフトがどのヘッダーを付けているかを知りたい場合は、自分宛てに1通送って、受け取ったメールのヘッダーを表示させれば分かります。手順は後の節で触れます。
もうひとつ知っておくとよいのが、ヘッダーの名前に大文字と小文字の区別がないことです。disposition-notification-to と書かれていても Disposition-Notification-To と同じものとして扱われます。ヘッダーを検索して見つからないときは、大文字小文字を区別しない検索に切り替えてください。値の側についても、処理の種類を表す語は大文字と小文字のどの組み合わせで書かれていてもよいと規格に書かれています。ログを機械的に集計する仕組みを作る場合、この点を踏まえないと取りこぼします。
なお、受信側が知らないヘッダーを見つけたときの扱いも規格に定めがあります。理解できない値が入っていた場合、そのまま無視するか、特別な解釈をせず利用者のメールボックスに置くことは許されていますが、送信元にエラーを返してはいけないことになっています。つまり、独自のヘッダーを付けて送っても、相手から「そんなヘッダーは知らない」という返事は来ません。何も起きないという形で失敗します。この静かな失敗の仕方が、原因の切り分けを難しくしています。
返ってくる開封確認は3つの部分でできている
開封確認が返ってきたとき、それは普通のメールとして受信箱に入ります。ただし中身の構造は決まっていて、multipart/report という形式で3つの部分が入っています。
・1つ目は人が読むための文章です。「あなたが送ったメッセージが表示されました」といった意味の文が入っています。文面はメールソフトによって違い、言語も相手の環境に依存します。
・2つ目が message/disposition-notification という部分で、機械が読むための情報が並んでいます。開封確認の中身と呼べるのはここです。
・3つ目には、元のメッセージのヘッダー、あるいはメッセージ全体が入ります。どのメールに対する通知なのかを照合するためのものです。
2つ目の部分に入っている行のうち、必ず存在するのが Disposition です。書式は Disposition: manual-action/MDN-sent-manually; displayed のように、スラッシュとセミコロンで区切られた3つの値からできています。
前半の2つは、どうやってその処理が起きたかを示します。manual-action は利用者が明示的に操作した結果、automatic-action は自動処理の結果です。後半の MDN-sent-manually は利用者が「この通知を送ってよい」と明示的に許可したこと、MDN-sent-automatically はあらかじめ自動で送る設定になっていたことを表します。規格は、利用者のプライバシーを守るため、この2つとも手動側を既定にしなければならないと書いています。
セミコロンの後ろが処理の種類で、ここが実質的な結論に当たります。Original-Message-ID という行も含まれることが多く、どのメールに対する通知かを機械的に突き合わせるために使えます。件名で照合すると、同じ件名のやり取りが複数あるときに取り違えます。
この構造を知っていると、届いた開封確認から何を読み取ればよいかがはっきりします。1つ目の人が読む文章は、相手のメールソフトが用意した定型文にすぎず、書いてある日本語や英語のニュアンスに意味はありません。2つ目に入っている Disposition の行だけが、規格に沿った事実です。相談を受けたときに1つ目の文章だけを見て判断すると、ソフトごとに違う言い回しに引きずられます。
3つ目の部分については、元のメッセージ全体が入る場合と、ヘッダーだけが入る場合があります。全体が入っていれば、自分が送った本文がそのまま返ってくることになります。機密性の高い内容を扱っている場合、この点は覚えておく価値があります。開封確認を要求するということは、条件によっては自分が送った内容が別の経路でもう一度流れることを意味します。
なお、開封確認そのものに対して、さらに開封確認を要求することはできません。規格は、開封確認のメッセージ自身が要求のヘッダーを持ってはならず、開封確認に対して開封確認を生成してはならないと定めています。通知が無限に往復する事故を防ぐための決まりです。
dispositionの4つの値は「読んだ」を意味しない
処理の種類として定義されている値は4つです。それぞれの意味を規格の説明に沿って整理すると、開封確認という日本語訳がいかに実態から離れているかが分かります。
・displayed は、受信者のメールボックスを見ている誰かに対して、メッセージが表示されたことを意味します。規格は、内容が読まれたことや理解されたことを保証するものではないと明記しています。
・dispatched は、表示されないまま、印刷、ファクス送信、転送などの形でどこかに送られたことを意味します。利用者が後で読むかどうかは分かりません。
・processed は、何らかの規則やサーバーによって処理されたが、利用者には表示されていないことを意味します。そもそも人が対応していないメールボックスである場合も含まれます。
・deleted は削除されたことを意味します。受信者が見たかどうかは分からず、後で復元して読むこともありえます。
つまり displayed が返ってきても、それは「プレビュー画面に一瞬映った」という状態と区別がつきません。逆に deleted が返ってきたからといって、内容を確認したうえで消したのか、開かずに消したのかは判別できません。開封確認の数字を根拠に「相手は読んだのに返信しない」と判断するのは、この時点でかなり無理があります。
さらに、規格は1人の受信者に対して発行できる通知は1回までと定めています。同じメールを2回開いても2回目の通知は出ません。開封の回数を数える用途には使えない仕組みだということです。回数を数えているのは、配信サービスが埋め込む画像を使った別の仕組みで、こちらはヘッダーとは無関係に動いています。
例外として、メールが転送された場合には、転送した人について1通、転送先の人について1通と、通知が2つ生まれることがありえます。窓口宛てのメールを担当者に転送する運用をしていると、この形になります。開封確認の件数を数えて対応状況を把握しようとしても、転送の有無で数がずれるため、そもそも指標として使えません。
もうひとつ、同じメールボックスを複数の機器から見ている場合の話があります。規格は、同じメッセージが複数のメールソフトからアクセスされると、同じ受信者について複数の通知が生成されうると認めたうえで、それを防ぐために接続方式が備えている仕組みを使うべきだとしています。パソコンとスマートフォンで同じメールを見ている人は珍しくないので、ここでもずれが生じます。
こうした事情を積み上げると、開封確認の集計値を業務の判断に使うのは現実的ではないと分かります。1件ごとに「返ってきたか、返ってこなかったか」を見る使い方までが限界で、それ以上の分析には耐えません。
差出人と返信先が食い違うと、自動では返らない
開封確認が返ってこない原因としてよく見落とされるのが、ヘッダーの整合性です。規格は、自動で通知を返してよい条件をはっきり制限しています。
Disposition-Notification-To に書かれたアドレスと、メッセージの Return-Path に書かれたアドレスが違う場合、通知を自動で送ってはいけないことになっています。この場合は利用者に確認を取らなければならず、確認が取れないなら送ってはいけないとされています。Return-Path がそもそも存在しない場合や、Disposition-Notification-To に異なるアドレスが複数書かれている場合も同じ扱いです。
これは受付の実務で頻繁に起きる状況です。配信システムや問い合わせフォームから送られるメールは、差出人の表示アドレスと、実際の送信経路上のアドレスが異なることがあります。転送を挟んでいる場合も同様です。ヘッダーの上で不一致が生じていれば、相手のメールソフトは規格どおりに自動送信を止めます。相手が拒否したわけでも、設定を間違えたわけでもありません。
この制限には理由があります。規格の安全性に関する節には、偽装されたメールが Disposition-Notification-To を含んでいて、受信者をだまして通知を返させる攻撃がありうると書かれています。通知を返すという行為は、そのアドレスが実在して人が使っていることを送信元に教える行為でもあります。迷惑メールの送信者にとっては価値のある情報です。だからこそ、自動で返す条件は厳しく絞られています。
開封確認が返ってこないときは、拒否されたと考える前に、自分が送ったメールのヘッダーを確認してください。配信経路の途中でアドレスが書き換わっていれば、その時点で自動送信の条件から外れています。
切り分けの順番としては、次の3段階で見ると早く済みます。
・まず、自分が送ったメッセージに Disposition-Notification-To が実際に付いているかを確認します。付いていなければ、送信側の設定が効いていません。
・次に、そのアドレスと Return-Path のアドレスが一致しているかを見ます。ここが食い違っていれば、相手側で自動送信が止まる条件に当たります。
・最後に、宛先がメーリングリストや転送用のアドレスになっていないかを確認します。個人のメールボックスに直接届いていない場合、通知の扱いは経路の設定次第になります。
この3つを潰しても返ってこない場合は、相手のメールソフトが返さない設定になっているか、そもそも開封確認に対応していない環境だと考えるのが自然です。ここから先は、こちらの操作でどうにかできる範囲を出ています。何度も送り直すより、本文で受領の連絡を頼むほうが確実に早く終わります。
ヘッダーを実際に見る手順と、見るときの注意
ヘッダーを表示させる操作は、どのメールソフトにもあります。Gmailであればメッセージのメニューからソースを表示させる項目があり、Outlookではプロパティのインターネットヘッダーとして見られます。項目の名称は版によって変わるため、手順を人に案内するときは、そのときの公式ヘルプで名前を確かめてください。古い名称で書かれた手順書は、案内された側が画面を探し回る原因になります。
見るときの注意が3つあります。
ひとつ目は、ヘッダーは上から下に向かって古くなるという点です。メールがサーバーを経由するたびに Received の行が先頭に追加されていくので、いちばん下にある Received が最初の経路です。配送に時間がかかっている場合、どのサーバーで滞留したかはここを追えば分かります。
ふたつ目は、ヘッダーは偽装できるという点です。規格自身が、開封確認は普通のメールと同じくらい簡単に偽造できると書いています。届いた開封確認が本物である保証はありません。身に覚えのない開封確認が届いた場合、それは自分のアドレスを差出人に見せかけた迷惑メールへの反応である可能性があります。
みっつ目は、ヘッダーには社内の情報が含まれることがあるという点です。返ってくる開封確認の3つ目の部分には元メッセージのヘッダーが入り、そこには社内のサーバー名や経路の情報が残ります。規格のプライバシーに関する節も、この部分がファイアウォールの内側のホスト名やネットワーク構成を明かしてしまう可能性を指摘しています。ヘッダーを外部に貼り付けて相談するときは、この点に注意してください。
同じ節には、開封確認を返すかどうかという動作自体が、受信者の環境について情報を漏らすという指摘もあります。手動で返しているのか自動で返しているのかが Disposition の値から読み取れるためで、それを避けたい場合は手動で返した形の値を使えばよいと書かれています。開封確認は、送る側だけでなく受け取る側にとっても、情報を出す行為なのだという前提を持っておくと、社内の方針を決めやすくなります。
メーリングリストに関わる注意もあります。要求のヘッダーがそのまま残った状態でリストの購読者に配送されると、購読者が通知を返すことで、リストに誰が登録されているかが元の送信者に知られる可能性があると規格は指摘しています。社内の配布リストや窓口の共有アドレスを使っている組織では、この点を把握したうえで設定を決めてください。
なお、開封の記録を業務の中で保存する場合、それは特定の個人がいつメールを見たかという情報になります。何のために残し、誰が見られて、いつ消すのかを先に決めておくのが安全です。取り扱いの考え方は個人情報保護委員会が公開している資料が参考になりますが、自分たちの場合にどう当てはまるかの判断は、所管の窓口や専門家に確かめてください。
ヘッダーで分かることと、分からないこと
ここまでを整理すると、ヘッダーから分かることは限られています。
分かるのは、要求が出されていたかどうか、通知が手動で返されたか自動で返されたか、どの種類の処理が起きたか、そしてどのメールに対する通知かの4つです。これは機械的な事実なので、争いになりません。日時が記録に残る点も、後から経緯を説明するときに役に立ちます。
分からないのは、内容が読まれたか、理解されたか、誰が読んだか、何回見たか、返信する意思があるかどうかです。これらはすべて人の側にあり、ヘッダーには一切現れません。共有のメールボックスであれば、そもそも通知を返した人と本来の宛先の人が別人だという可能性すらあります。
受付の現場で本当に知りたいのは、後者のほうです。応募書類が相手に届いたかどうかより、相手が次の手続きに進むつもりがあるかどうかを知りたい。ヘッダーはその問いに答えられません。答えられないものを追いかけて、設定を変えたり再送を繰り返したりすると、時間だけが減っていきます。
一斉配信の開封率として表示される数字は、ヘッダーとはまったく別の仕組みで計測されています。本文に埋め込んだ画像が読み込まれた回数を数えているもので、画像を表示しない設定の相手ではゼロのまま、逆にセキュリティ機器が自動で読み込むと開封として立ちます。ヘッダーの開封確認とは、数字の性質も精度もまったく違います。同じ「開封」という言葉で会話していると、話がかみ合いません。
社内で話をするときは、どちらの話をしているのかを先に決めてください。1通ずつのやり取りで相手が見たかどうかを知りたいのがヘッダーの話、案内メールを何人が開いたかを知りたいのが画像の話です。前者は返ってこないことが多く、後者は数字が出るものの精度が低い。どちらも判断の根拠としては弱いという点だけが共通しています。
判断の根拠を強くしたいなら、相手が何かを押したか、何かを送り返してきたかという行動を見るほうが確実です。案内した先のページを開いたか、申込みのフォームに入力したか、返信が届いたか。これらは受け取った側が実際に手を動かした結果なので、環境によるぶれがほとんどありません。開封の数字を追う時間を、この行動の記録を残す仕組みに使うほうが、結果的に早く答えが出ます。
ヘッダーを追わずに、届いたかどうかを分かる形にする
開封確認のヘッダーを調べる目的は、突き詰めれば「相手との間で、いまどこまで進んだかを共有したい」ということです。それをメールのヘッダーに求めるから難しくなります。
受付の側で持てる情報は、実はもっと確かです。いつ受け取ったか、誰が担当しているか、どの段階まで進んだか、次に誰が動く番か。これらはすべて自分たちの側にある事実なので、相手の環境に左右されません。この4つを1か所にまとめて、相手にも見える形で返すだけで、開封確認の必要はほとんどなくなります。
実際、開封確認を熱心に調べている窓口ほど、この4つが決まっていないことが多いという話をよく聞きます。誰が担当かが決まっていないから返信が遅れ、遅れているうちに相手から催促が来て、催促に答えるために「読んだかどうか」を知りたくなる。順番が逆になっているわけです。担当と期限が決まっていれば、相手が読んだかどうかは大きな問題ではなくなります。決めた期限に返していれば、相手は待てるからです。
受け取ったことを相手に知らせる仕組みも、開封確認より確実です。フォームで受け付けた時点で受付番号を発行し、その番号を書いた確認メールを自動で返す。相手はその番号を持っているので、後から問い合わせるときも話が早く進みます。こちらも番号で照合できるので、同じ人から複数回届いた場合の重複に気づけます。開封確認の要求を1行足すより、この仕組みのほうが投じた手間に見合います。
送信されたあとに何が起きるかを設計できているかどうかが分かれ目で、フォームを配って回答を集めるところまでは多くの道具ができます。送信されたあとの道具がそろっているかどうかを見るときは、できることに並ぶ項目と、いま毎日やっている作業を突き合わせてください。実際の動きは動くところを見るで確かめられます。
いまGoogleフォームで受け付けていて、回答が増えたあとの返信で詰まっているなら、その境目の話はGoogleフォームとの比較にまとまっています。WordPressのプラグインで問い合わせを受けている場合はContact Form 7との比較、Microsoft 365の環境ならMicrosoft Formsとの比較が近い内容です。
窓口の種類ごとに、必要になる情報は少しずつ違います。応募者と何度もやり取りする採用なら採用の応募受付、期限が厳格な公募なら助成金・公募の受付、不特定多数から届く窓口なら問い合わせの受付、修理の依頼のように写真や型番が必要なら修理・サポートの受付が、それぞれ参考になります。費用の考え方は料金に、判断の途中で出てくる細かい疑問はよくある質問にまとまっています。
Q1. 開封確認を要求するヘッダーは何という名前ですか？
Disposition-Notification-To です。RFC 8098 で定義されていて、1通のメッセージに1回までしか置けません。Return-Receipt-To や X-Confirm-Reading-To といった似た名前のヘッダーも見かけますが、これらは標準に定義されたものではなく、相手のメールソフトが知らなければ無視されます。
Q2. 開封確認が返ってこないのは、相手が拒否したからですか？
拒否とは限りません。規格では、要求に書かれたアドレスと Return-Path のアドレスが違う場合、自動での送信が禁じられています。配信システムや転送を経由すると、この不一致は簡単に起きます。相手の設定を疑う前に、自分が送ったメールのヘッダーを確認してください。
Q3. displayed が返ってきたら、相手は内容を読んだということですか？
そうとは言い切れません。規格は displayed について、メールボックスを見ている誰かに表示されたことを示すだけで、内容が読まれたことや理解されたことを保証しないと明記しています。プレビュー画面に一瞬映った場合と区別がつかないため、読んだかどうかの根拠には使えません。
Q4. 身に覚えのない開封確認が届くことがあるのはなぜですか？
開封確認は普通のメールと同じくらい簡単に偽造できると、規格自身が書いています。自分のアドレスを差出人に見せかけた迷惑メールに対して、どこかの受信者のメールソフトが通知を返した結果として届くこともあります。中身のリンクは開かず、送信経路のヘッダーだけを確認してください。