開封確認メールの送り方を調べているとき、必要な情報は手順だけではありません。手順そのものは数クリックで終わります。難しいのは、その数クリックが実を結ぶ条件のほうです。開封確認は、送る側が正しく操作しても、受け取る側の環境や設定によって何も返ってこないことが普通にあります。手順を知っただけで送り始めると、返ってこなかったときに原因が分からず、無意味な再送を繰り返すことになります。ここでは、送る操作、届く条件、返ってこないときの次の手を順に整理します。
送る前に、何を確かめたいのかを決める
最初に決めるべきは、確かめたいのが「届いたこと」なのか「読まれたこと」なのかです。この2つには別々の仕組みが用意されていて、送信時に選ぶ項目も違います。
届いたことを確かめる仕組みは配信確認と呼ばれます。相手のメールサーバーがメッセージを受け取った時点で通知が返るもので、人が見ているかどうかは関係ありません。宛先のアドレスが間違っていないか、途中で止まっていないかを確かめたい場合はこちらです。なお、宛先が存在しない場合に返ってくる不達の通知は、これとはさらに別の仕組みで、送信の失敗を知らせるために自動で返ります。
読まれたことを確かめる仕組みが開封確認です。相手のメールソフトでメッセージが表示されたときに通知が返ります。ただし、この通知が伝えるのは「表示された」という事実だけで、内容が読まれたことや理解されたことは保証しません。開封確認の規格である RFC 8098 も、表示を示す値について、内容が読まれたことや理解されたことの保証にはならないと明記しています。
3つ目の選択肢として、本文で受領の連絡を頼む方法があります。機械の通知ではなく、人が文章で返す形です。相手が何をするつもりなのか、いつ返事が来るのかまで分かるので、実務ではこれがもっとも役に立ちます。
送る前にこの3つのどれが必要なのかを決めておくと、返ってこなかったときの判断が変わります。宛先の誤りを疑うなら配信確認、相手の対応状況を知りたいなら文面での依頼です。開封確認を選ぶのは、その中間の、届いたことだけを軽く確かめたい場面に限られます。
実際の場面に当てはめると、次のようになります。
・請求書を送ったが宛先が正しいか不安: 配信確認、あるいは電話1本で確かめる ・締切のある書類を送り、相手が処理を始めたか知りたい: 本文で受領の連絡を依頼する ・社内の周知メールを出し、誰が見たか大まかに把握したい: 開封確認だが、返ってこない人が出る前提で使う ・応募者に選考結果を送り、確実に伝わったか確かめたい: 本文で受領の連絡を依頼し、期限を切って督促する
こう並べると、開封確認が最適解になる場面は思ったより少ないことが分かります。相手が個人のアドレスを使っている場合や、社外との一度きりのやり取りでは、まず返ってきません。それでも送るなら、返ってこなかったときに何をするかを先に決めておく必要があります。この点は後の節で詳しく書きます。
送信側の手順は、どのメールソフトでも3つの段階
操作そのものは、製品が違ってもほぼ同じ流れです。
・メールの作成画面を開く ・送信オプションの中から開封確認の項目を選ぶ ・通常どおり送信する
2つ目の項目がどこにあるかは製品によって違い、その他のオプションの中に隠れていることもあれば、リボンやメニューの中に並んでいることもあります。項目名は「開封確認をリクエストする」「開封確認メッセージを要求する」といった形で、英語の画面では read receipt という語が使われます。配信確認のほうは delivery receipt と表記されるので、英語の画面で操作するときは取り違えないようにしてください。
注意したいのは、この項目名も置き場所も、製品の版が上がると変わるという点です。手順を人に案内する必要があるなら、そのときに公式のヘルプで名称を確かめてから書いてください。古い画面名で書かれた手順書は、案内された側が画面を探し回る原因になります。社内の手順書に画面の名前を書くときは、いつ時点の情報かを添えておくと、後で見直しやすくなります。
もうひとつ、送信時に付けている設定が1通ごとのものなのか、以後すべてのメールに適用されるものなのかを確認してください。全体の設定として開封確認を常に付ける形にしていると、日常的な連絡にまで要求が付きます。受け取る側からすると、毎回確認の画面が出るのは煩わしく、印象もよくありません。必要な1通にだけ付けるのが基本です。
技術的には、送信時に足されているのはDisposition-Notification-Toというヘッダーの1行だけです。規格では、この行は1通のメッセージに1回までしか置けないと決まっています。複数の宛先について別々に通知を集めるような使い方はできません。
自分の操作が実際に効いているかどうかは、自分宛てに1通送ってみれば分かります。受け取ったメールのヘッダーを表示させて、この1行が入っているかを見るだけです。項目にチェックを入れたつもりでも、送信前に別の画面へ移動した拍子に設定が外れていることがあります。大事な相手に送る前に、一度手元で確かめておくと安心です。
複数の宛先に同じメールを送る場合の扱いにも触れておきます。宛先が複数あるとき、通知は受け取った人ごとに返る可能性があり、誰から返ってきたのかは通知の中身で判別することになります。送る前に決めておきたいのは、宛先を並べて1通で出すのか、写しに入れるのか、相手ごとに1通ずつ分けるのかです。1通ずつ分けて送っておけば、返ってきた通知がどの宛先のものかで迷わずに済みます。写しに入れた人にも確認の表示が出る環境があるので、関係者を広く写しに入れる習慣のある職場では、1通あたりに止める手の数が思ったより増えます。何人に送って何人から返ってきたかを数えたいのであれば、開封確認ではなく別の方法を検討してください。返ってこない人が拒否したのか、環境の都合で返せないのかを区別できない以上、数字として意味を持たないためです。
送れるアカウントと、送れないアカウントがある
手順どおり操作しても、そもそも項目が見当たらない場合があります。使っているアカウントの種類によって、機能が提供されていないことがあるためです。
Googleのヘルプは、この点をはっきり書いています。開封確認は仕事用アカウントまたは学校用アカウントでのみ利用でき、個人用のアカウントでは機能しないとされています。個人のアドレスで送ろうとして項目が見つからないのは、設定を見落としているのではなく、機能が提供されていないということです。
組織のアカウントを使っていても、管理者の側で制限がかけられていることがあります。同じヘルプには、組織内のユーザーや組織外の特定のユーザーに対する開封確認の送信が管理者によって制限されている場合が、通知が返らない理由として挙げられています。設定を探しても該当の項目がない場合は、管理者に確認してください。
受け取る側の環境も同じです。相手が個人のアドレスを使っていれば、こちらがどれだけ正しく操作しても通知は返りません。取引先の担当者が個人のアドレスから連絡してくる窓口や、応募者からのメールを受ける採用の窓口では、返ってこないことのほうが多くなります。
つまり、開封確認は「使える条件がそろったときだけ働く機能」です。送る前に相手の環境が分かることはまずないので、返ってくればもうけもの、くらいの位置づけで使うのが現実的です。業務の判断をこの通知に載せると、条件がそろわなかったときに動けなくなります。
社内であれば、条件をそろえられる余地があります。全員が同じ環境を使っていて、管理者が制限をかけていなければ、開封確認は比較的よく働きます。ただ、社内で一律に開封確認を付ける運用には別の副作用があります。上長から部下へ、あるいは管理部門から現場へ一方的に付けると、監視されているという受け取られ方をしやすい形です。確実に読ませたい連絡があるなら、確認の方法をあらかじめ決めて周知しておくほうが摩擦が少なく済みます。読んだら所定の場所に印を付ける、といった形です。
社外向けについては、条件をそろえることはできません。相手が何を使っているかは選べないからです。この非対称を理解しておくと、社内で試してうまくいった方法を社外に持ち出したときに、なぜ機能しないのかで悩まずに済みます。
相手が承認しないと、通知は返らない
もうひとつ、送る側が見落としがちな条件があります。受け取った側が返すかどうかを選べるという点です。
重要: 受信トレイに開封確認を受け取るには、メールの受信者が開封確認を承認する必要があります。 出典: support.google.com
受け取った側の画面には、開封確認を送るかどうかを尋ねる表示が出ます。そこで送らないほうを選べば、こちらには何も返りません。断ったことが送信側に通知される仕組みもないので、返ってこなかった理由が拒否なのか環境なのかは区別できません。同じヘルプには、受け取った側にその表示が出ない場合は自動的に開封確認が送信されていると案内されており、返す返さないの扱いは相手の設定次第だということが分かります。
これは規格の設計どおりの動作です。2017年2月に公開された RFC 8098 は、通知を送る前に利用者の同意を得ることを強く推奨し、既定値は送らないほうにすべきだと書いています。受け取った側が黙って要求を無視することも認められています。
この設計の背景にはプライバシーの考え方があります。通知には、いつ読んだか、どのメールソフトで読んだか、どのOSを使っていたかといった情報が乗りうると規格自身が指摘しています。受け取る側が返したくないと考えるのは自然なことで、組織として一律に返さない方針にしている会社も珍しくありません。相手の会社がそういう方針であれば、こちらが何度送っても状況は変わりません。
送る側としては、この点を織り込んでおくのが実務的です。返ってこなかったことを相手の不誠実さと結びつけると、関係を損ねます。返ってこないのが普通で、返ってきたら条件がそろっていた、という順序で理解してください。
したがって、開封確認を付けて送るときは、返ってこないことを前提に組み立ててください。返ってきたら状況が1つ分かる、返ってこなくても何も分からないだけ、という扱いです。返ってこないことを理由に相手の姿勢を推測すると、判断を誤ります。
なお、規格では1人の受信者について発行できる通知は1回までと決まっています。同じメールを2回開いても、2回目の通知は出ません。相手が何度見たかを数える用途には使えません。
例外として、メールが転送された場合には通知が2つ生まれることがあります。窓口宛てのメールが担当者に転送される運用では、転送した人について1通、転送先の人について1通という形になりえます。返ってきた通知の件数から相手の人数を推し量ろうとしても、この事情でずれます。
また、返ってくる通知の中身には、それが手動で返されたものか自動で返されたものかを示す値が入っています。自動で返す設定にしている相手からの通知は、人が見たかどうかとは無関係に届いているということです。通知が来たからといって、担当者が内容を確認したとは限りません。共有のメールボックス宛てに送った場合は特に、通知を返した人と本来の宛先の人が別人である可能性があります。
返ってこない条件を、あらかじめ知っておく
返ってこない理由は複数あります。Googleのヘルプが挙げているものを整理すると、次のようになります。
・グループのメーリングリストやエイリアスに宛てて送った場合 ・管理者によって送信が制限されている場合 ・受信者がリアルタイムで同期しないメールプログラムを使っている場合 ・受信者が特定の接続方式のクライアントで返し、自動送信が行われない場合
これに加えて、規格の側にも制限があります。要求のヘッダーに書かれたアドレスと、メッセージのReturn-Pathに書かれたアドレスが異なる場合、自動で通知を送ってはいけないと定められています。配信システムや問い合わせフォームから送るメールは、表示上の差出人と経路上のアドレスが違うことがあり、この条件に当たります。転送を挟んでいる場合も同様です。
窓口の共有アドレスから送っている場合も注意が要ります。共有のメールボックスは複数人が見ているため、通知が返ったとしても、本来の宛先の人が見たとは限りません。実態と食い違う情報を受け取ることになります。
こうした条件を知っておくと、返ってこなかったときに無駄な作業をせずに済みます。設定を何度も見直したり、同じメールを送り直したりする前に、そもそも返らない条件に当たっていないかを確認してください。
切り分けの順番としては、次の3段階が早いです。
・まず、自分が送ったメッセージに要求のヘッダーが実際に付いていたかを確認します。付いていなければ、送信側の設定が効いていません ・次に、宛先がメーリングリストや共有アドレスになっていないかを見ます。個人のメールボックスに直接届いていない場合、通知の扱いは経路の設定次第です ・最後に、差出人の表示アドレスと経路上のアドレスが一致しているかを確認します。配信システムや転送を経由していると、ここが食い違います
この3つを潰しても返ってこないなら、相手の環境か相手の判断です。送る側の手として残るのは同じ内容をもう一度出すことだけですが、それをしても条件は何ひとつ変わりません。2通目にも同じ要求が付き、相手の画面には同じ確認の表示がもう一度出るだけです。次の1通は開封確認を外して、本文で受領の連絡を頼む形に切り替えてください。
もうひとつ、返ってこない理由として見落としがちなのが、メールそのものが届いていない場合です。迷惑メールの判定に入っていれば、相手は開いていないので通知も返りません。開封確認が返らないという症状は、配送の失敗と区別がつきません。宛先を確かめたいなら、開封確認ではなく配信確認を使うか、別の連絡手段で確認するほうが確実です。
一斉配信の開封率とは、別の仕組み
案内メールを大量に送る場面で「開封率」という言葉が出てきますが、これは開封確認とはまったく別の仕組みです。
一斉配信で計測される開封率は、本文に埋め込んだ小さな画像が読み込まれた回数を数えたものです。ヘッダーは関係ありません。画像を表示しない設定の相手ではゼロのままで、逆にセキュリティ機器が中身を検査するために画像を読み込むと、人が見ていなくても開封として計上されます。
数字の性質がまったく違うので、混ぜて話すと会話がかみ合いません。1通ずつのやり取りで相手が見たかどうかを知りたいのが開封確認、配信全体で何人が開いたかを知りたいのが開封率です。送る操作も別物で、開封確認は必要な1通に自分で項目を付けますが、開封率は配信の道具が全通に自動で仕込みます。自分がどちらを操作しているのかは、送信画面に項目があるかどうかで見分けられます。
一斉配信で開封確認の要求を全員に付けるのは避けてください。受け取った人全員の画面に確認の表示が出るため、印象が悪くなります。要求のヘッダーがそのままメーリングリストの購読者に配送されると、購読者が通知を返すことで、誰が登録しているかが送信者に知られる可能性があると規格も指摘しています。配信では使わない、と決めておくのが安全です。
数十人から数百人に案内を出す場面では、開封の数字を追うより、相手に行動してもらう入口を用意するほうが確実です。案内の中に申し込みや回答のリンクを置いておけば、押した人が誰かは記録として残ります。これは相手が実際に手を動かした結果なので、環境によるぶれがほとんどありません。開いたかどうかより、動いたかどうかのほうが、業務の判断には役立ちます。
なお、送った側に返ってきた通知を業務として保存する場合、それは特定の個人がいつメールを見たかという情報になります。返ってきたものを目的も決めずに溜めていく形は避けてください。集める目的と、残す期間と、その記録を業務のどの判断に使うのかまで決めてから始めるのが安全です。考え方は個人情報保護委員会が公開している資料が参考になりますが、自分たちの場合にどう当てはまるかは、所管の窓口や専門家に確かめてください。
送ったあとに何をするかを、先に決めておく
開封確認を付けて送る場合、送る前に決めておくべきことが1つあります。返ってこなかったときに、いつ、何をするかです。
これを決めずに送ると、受信箱を眺めて待つ時間が発生します。返ってきたかどうかを気にしながら仕事をするのは、集中を削るだけで何も生みません。しかも、返ってこない場合のほうが多い仕組みなので、待つ時間のほとんどは空振りになります。
送った件数が増えると、待っている案件が頭の中に溜まっていきます。人が同時に覚えていられる数には限りがあるので、どこかで必ず抜けが出ます。抜けたことに気づくのは、たいてい相手から催促が来たときです。そうなる前に、期限が来たら気づける形にしておいてください。予定表に入れる、案件の一覧に期限の列を作る、どちらでも構いません。人の記憶の外に出すことが目的です。
決め方は単純です。送信した日を起点に、いつまでに反応がなければ次の手を打つかを1つ決めます。書類の締切が絡む案件なら翌営業日、通常の連絡なら3営業日といった形です。その日が来たら、開封確認が返っているかどうかにかかわらず、短い督促を出します。
督促の文面は、相手を責めない形にしてください。
・先日お送りした件について、念のためご連絡いたします。行き違いでしたらご容赦ください。お手数ですが、資料が届いているかどうかだけお知らせいただけますでしょうか。
届いていない可能性をこちらから示しておくと、相手は返しやすくなります。返信が来ない理由の多くは、無視ではなく埋もれです。迷惑メールの判定に入っていれば、相手は探しても見つけられません。
最初から本文に受領の依頼を書いておくと、督促そのものが減ります。
・お手数ですが、本メールを受け取られましたら、その旨を一言ご返信いただけますと幸いです。2営業日以内にご返信がない場合は、改めてご連絡いたします。
こちらから次の行動を予告しておけば、相手も動きやすくなります。開封確認の機能を使うより、この一文のほうが確実に効きます。
依頼の書き方には、少しコツがあります。何を受け取ったのかを具体的に書くことです。「本メール」とだけ書くと、複数のやり取りが並行しているときにどの件か分かりません。「本日お送りした見積書」「3月分の請求書」のように対象を特定してください。
期限の書き方も同じです。「お手すきの際に」と書くと、相手は急ぎではないと判断します。日数か日付で書いてください。営業日で書くか暦日で書くかは、社内で統一しておくと行き違いが起きません。連休をまたぐ場合、「3営業日以内」は相手の感覚では1週間以上先になります。
そして、返信が要るのかどうかをはっきりさせてください。受領の連絡が要らない案件で毎回依頼を書いていると、相手は次第に読み飛ばすようになります。本当に必要な場面で効かせるために、依頼を書くのは必要な1通に絞るほうがよい結果になります。
そもそも送らずに済ませる受付の作り方
ここまで見てきたとおり、開封確認は条件がそろったときだけ働く不安定な仕組みです。それでも使いたくなるのは、送ったものがどうなったか分からないという不安があるからです。その不安の元は、状況が相手の側にしかないことです。
受付の業務であれば、この構図をひっくり返せます。申し込みや問い合わせをフォームで受けている場合、届いた時点の記録はこちらの側に残ります。いつ受け取ったか、誰が担当しているか、いまどの段階か、次に誰が動く番か。この4つは相手の環境に一切左右されません。
そのうえで、相手にも同じ情報が見える形にしておくと、確認のやり取りが減ります。受け付けた時点で受付番号を含む自動の返信を送り、状況が変わったら通知する。この流れができていれば、届いたかどうかを尋ねるメールも、開封確認の要求も発生しません。
この4つを受信箱の中だけで管理していると、必ず崩れます。受信箱は届いた順にしか並ばず、既読か未読かという状態しか持てないためです。誰が担当かも、いまどの段階かも、期限がいつかも、受信箱には書けません。開封確認に頼りたくなる窓口は、たいていこの状態にあります。仕組みで持てるはずの情報を、人の記憶で埋めようとしているわけです。
判断の目安として、いま自分の窓口について3つの数字がすぐ答えられるかを確かめてみてください。1日に何件届くか、そのうち何件が返信済みか、いちばん古い未返信は何日前のものか。答えられないなら、状態が記録として残っていないということです。答えられるなら、いまの方法で足りている可能性が高く、無理に変える必要はありません。
フォームで集めるところまでは多くの道具でできますが、送信されたあとの道具がそろっているかどうかは製品によって差が出ます。いま使っている道具で足りるかを確かめるときは、できることに並んでいる項目と、自分の窓口で毎日起きている作業を突き合わせてみてください。実際の画面の動きは動くところを見るで確認できます。
いまGoogleフォームで受け付けていて、集める部分は問題なく回っているなら、詰まっているのは回答が増えたあとの返信の段階です。その境目の整理はGoogleフォームとの比較にあります。WordPressのプラグインで問い合わせを受けているならContact Form 7との比較、Microsoft 365を使っている組織ならMicrosoft Formsとの比較が近い内容です。
窓口の性質によって、必要になるものは変わります。応募者と何度もやり取りする採用なら採用の応募受付、締切が厳格な公募なら助成金・公募の受付、参加者への案内が続くイベントならイベントの申し込み、写真や型番を先にもらう必要がある修理の受付なら修理・サポートの受付が、それぞれ近い形になります。費用の考え方は料金に、判断の途中で出てくる細かい疑問はよくある質問にまとまっています。
開封確認の送り方を調べる時間は、突き詰めれば「相手が受け取ったかどうかを知りたい」という一点に向かっています。その問いに対して、開封確認は不確実な答えしか返しません。確実な答えを返すのは、受け取った側が持っている記録です。送る技術を磨くより、受ける側の記録を整えるほうが、結果的に早く楽になります。
今日からできることを3つ挙げるなら、次のとおりです。まず、送る前に何を確かめたいのかを決めて、開封確認と配信確認と文面での依頼を使い分けること。次に、開封確認を付けて送るときは、返ってこなかったときに動く日を必ず決めておくこと。最後に、受け付けた側から出す自動の返信に、受付番号と次の連絡時期を入れること。3つ目まで進めば、開封確認の送り方を調べる場面そのものが減っていきます。
Q1. 開封確認の項目が画面に見当たらないのはなぜですか？
使っているアカウントの種類が原因である場合があります。開封確認は仕事用アカウントまたは学校用アカウントでのみ利用でき、個人用のアカウントでは機能しないと案内されています。組織のアカウントでも、管理者の側で制限がかけられていることがあるため、項目が見つからない場合は管理者に確認してください。
Q2. 開封確認と配信確認は何が違いますか？
配信確認は相手のメールサーバーがメッセージを受け取った時点で返る通知で、人が見ているかどうかは関係ありません。開封確認は相手のメールソフトでメッセージが表示されたときに返る通知です。宛先の誤りや配送の詰まりを疑うなら配信確認、相手が見たかどうかを軽く確かめたいなら開封確認を使い分けてください。
Q3. 開封確認を付けて送ったのに返ってこないのはなぜですか？
返らない条件がいくつもあります。メーリングリストやエイリアス宛てに送った場合、管理者が制限している場合、受信者が随時同期しないクライアントを使っている場合などです。加えて、受け取った側は要求を断る自由を持っており、規格では返さないことが既定とされています。返ってこないのは異常ではありません。
Q4. 一斉配信のメールに開封確認を付けてもよいですか？
避けたほうがよいです。受け取った人全員の画面に確認の表示が出るため、印象を損ねます。配布リストに要求のヘッダーが残ると、誰が登録しているかが送信者に知られる可能性があると規格も指摘しています。配信全体の反応を見たい場合は、開封率を計測する別の仕組みを使ってください。