送信予約と開封確認が実際に保証すること

この二つは機能一覧でよく並べて紹介されますが、どこまで信頼できるかという点では大きく異なります。

送信予約は、サービスが正常に稼働している限り決められたとおりに動きます。サーバーがメッセージを保管し、指定時刻に送信します。ノートパソコンを閉じても、接続が切れても、眠ってしまっても、端末がオンラインである必要はありません。

開封確認はあくまで依頼です。受信者のメールソフトに、メッセージを表示したら通知するよう求めますが、ソフト側は拒否したり、先に利用者へ確認したり、何もせず無視したりできます。通知が届かなくても、そこから分かることはほとんどありません。

どちらも役立つ機能ですが、それぞれが何を示せるのかを理解して使う必要があります。

送信予約の仕組み

メッセージを作成し、送信の横にあるメニューを開いて時刻を選びます。明日の午前、明日の午後、次の月曜の午前は選択肢から指定でき、それ以外は日付選択を使えます。メッセージは送信予約フォルダーへ移り、予定時刻までそこで待機します。

重要なのは、メッセージがどこで待つかです。メッセージはサーバーに保存され、処理プロセスが毎分、時刻を迎えたものを確認します。端末は処理に関与しません。ブラウザーのタブを開いたままにする必要も、アプリを起動しておく必要もなく、パソコンの電源を切っても構いません。これがサーバー側の送信予約と、一部のデスクトップソフトが提供するクライアント側の予約機能との違いです。後者では、予約時刻にパソコンが起動している場合だけ送信されることがあります。

実行されるまでは、予約したメッセージを自由に編集できます。送信予約フォルダーを開けば、取り消し、時刻変更、本文編集が可能です。取り消したメッセージは削除されず、下書きに戻ります。

あらかじめ知っておきたい制限が一つあります。共有メールボックスとして操作している場合、送信予約は利用できません。チームの受信箱から数時間前に登録したメッセージは、送信時点で担当者が明確でない可能性があります。作成者がすでにチームを離れていることもあり、待機中はほかのメンバーから見えません。共有アドレスからすぐ送信する機能には影響しません。

送信取り消しは送信予約ではない

この二つはよく混同されますが、解決する問題が違います。送信取り消しはクリック後の五秒間に気付いたミスを救済するものです。送信予約は、数週間先になることもある送信時刻を選ぶためのものです。

送信取り消しを使うと、すべてのメッセージに五秒の待機時間が加わります。送信をクリックすると、すぐには転送されずキューに入り、カウントダウンが表示されます。取り消すをクリックすれば、編集可能な状態で作成画面に戻ります。時間切れになれば送信されます。

五秒という長さは意図的なものです。よくある二つのミス、添付ファイルの付け忘れと宛先の間違いは、画面を閉じた直後に気付くことが多く、通常はこの時間で対応できます。一方で、送信が遅く感じない程度の短さでもあります。

より長い猶予は便利そうに見えますが、欠点もあります。三十秒にすると、すべてのメッセージが半分宙に浮いた状態で待ちます。「もう送られたか」を確認しなければならず、送信済みフォルダーの表示も実際の状態より遅れます。

タイムゾーンで送信予約を誤る理由

二人が別の場所にいるだけで、「明日の午前9時」は曖昧になります。送信予約では、その曖昧さによってメッセージが午前3時に届くことがあります。

指定する時刻には、ブラウザーから取得した自分のタイムゾーンが使われます。ベルリンのノートパソコンからサンフランシスコの同僚に向けて予約した場合、午前9時はベルリンの午前9時であり、相手にとっては深夜です。

以前はカレンダーでも同種の問題が起き、影響はさらに深刻でした。そのため現在の予定は、タイムゾーンのない単なる時計上の時刻ではなく、予定ごとに明示的なタイムゾーンを保存します。ベルリンで作成した会議をサンフランシスコで開くと、同じ数字を誤った場所に表示するのではなく、双方の画面に正しい現地時刻が表示されます。

実際に予約するときは、自分ではなく受信者の朝を基準に考え、時計が切り替わる週には特に注意してください。三週間先の送信を予約し、その間に夏時間の切り替えをまたぐと、想定した現地の時計上の時刻から一時間ずれて届くことがあります。

開封確認：MDNとは

メールの開封確認は、Message Disposition Notification（MDN）という仕組みで、RFC 8098で標準化されています。流れは次のとおりです。

1. 自分のアドレスを指定したDisposition-Notification-Toヘッダー付きのメッセージを送信します。
2. 受信者のメールソフトがヘッダーを認識します。その後の処理は、ソフトと設定に全面的に委ねられます。
3. 応答する場合は、その利用者がその時刻にメッセージを表示したことを示す、小さな機械可読の構造化メッセージを返します。
4. 通知は通常のメールと同じように受信箱へ届き、Original-Message-IDによって元のメッセージと照合されます。

こちらでは、送信時に受信者ごとの保留項目を一件記録します。照合可能な有効なMDNが届くと、対応する項目に時刻が記録されます。送信済み一覧には印が付き、メッセージを開くと、確認済みか未確認かを受信者ごとに確認できます。

Bccの受信者は、意図的にレポートから除外しています。非表示の受信者から届いた通知を送信者のレポートに表示すると、画面をのぞいた人にBccの存在が知られる可能性があります。Bccの意味をひそかに損なう機能は不具合です。

作成画面でメッセージごとに開封確認を有効にできます。本当にすべてで必要なら、設定でメールボックスごとの既定値にもできますが、多くの人には常時有効化を勧めません。

トラッキングピクセルとの違い

開封を推測する別の方法として、送信者が管理するサーバー上の1×1の透明画像を埋め込み、受信者のソフトが画像を読み込んだときのリクエストを記録する手法があります。多くの「メール追跡」用ブラウザー拡張や営業ツールが採用しています。

ここでその方法を使わない理由は三つあります。

ひそかに行われるからです。受信者には、情報が記録されるという明確な表示がありません。MDNの依頼は見える形で行われ、ソフトが利用者に通知したり許可を求めたりできます。同意が仕組みに組み込まれています。

開封時刻より多くの情報が漏れるからです。画像のリクエストにはIPアドレスとユーザーエージェントが含まれ、おおよその位置や閲覧に使った端末が分かる可能性があります。「メッセージが表示された」という情報とは性質が異なり、明示的に尋ねず収集されることがあります。

現在では信号の信頼性が低いからです。Appleのメールプライバシー保護は、プロキシ経由で画像を事前取得することがあります。その場合、実際の受信者とは異なる場所から即座に開かれたように見えます。Gmailも独自のキャッシュ経由で画像を配信します。このため、データには多くのノイズが含まれます。

MDNで得られるデータは少ないものの、ソフトが通知すると判断した動作を表します。これは意図的な選択です。

通知がないときに分かること（ほぼ何もない）

ここは明確にしておく必要があります。開封確認の依頼の多くには応答がありません。その理由は、メッセージが読まれたかどうかとは関係ありません。

したがって空のレポートは、まだ読まれていない、スマートフォンやGmailで読まれた、Outlookで開いて拒否された、または読んだものの確認しなかった、というすべての状況に当てはまります。区別はできません。

正しい読み方は非対称です。通知が届いた場合、メールソフトがメッセージを表示したという有力な信号になります。届かなかった場合は、読んだかどうかの証拠にはなりません。前者は信号、後者は沈黙として扱ってください。

必要なのが開封ではなく配信の証拠なら、別の、通常はより確認しやすい問題です。送信ログには、受信サーバーがメッセージを受け入れたときのSMTP応答が記録されます。また、上昇するバウンス率は注視すべき信号です。インフラが観測できるのはサーバーによる受け入れであり、開封は受信者が自発的に伝える情報です。

レポートの読み方

送信済み一覧では、開封確認を依頼したメッセージに印が付きます。開くと、ToとCcの各受信者について、確認時刻または空欄が表示されます。

判定ではなく、連絡のきっかけとして使ってください。「五人中三人が確認し、残る二人から回答が必要だ」なら、フォローする合理的な材料になります。「14:32にメールを読んだのに返信しなかった」と言っても、よい会話の土台にはならず、相手を不快にさせるのにはもっともな理由があります。

それぞれを使う場面

送信予約が向いているのは、勤務時間外に書いたものの午前1時まで働いている印象を与えたくないとき、受信者が別のタイムゾーンにいて相手の朝に届けたいとき、更新通知や契約期限など特定日に送る必要があるとき、または送信前にもう一度考えたいときです。

開封確認を依頼するのは、メッセージが本当に重要で、確認の有無が次の行動を変え、かつ通知がないことは回答ではないと事前に納得できる場合です。既定で毎回依頼すると、常に確認を求められる受信者を煩わせ、本当に必要なメッセージでの信号価値も下がります。

よくある質問

パソコンの電源が切れていても送信予約は動きますか？

はい。サービスが正常に稼働していれば、メッセージはサーバーに保管され、処理プロセスが毎分、時刻を迎えたものを確認します。手元の端末を起動したりオンラインにしたりする必要はありません。

送信前に予約したメッセージを編集できますか？

はい。送信予約フォルダーを開けば、本文や時刻の変更、予約の取り消しができます。取り消すと下書きに戻ります。

共有メールボックスで送信予約を使えないのはなぜですか？

チームの受信箱から数時間前に登録したメッセージは、送信時の担当者が明確でない可能性があり、待機中はほかのメンバーからも見えません。共有アドレスからの即時送信は通常どおり使えます。

Gmailで開封確認は使えますか？

個人用GmailアカウントからのMDNは、通常は期待できません。Google Workspaceでは管理対象の設定に依存し、無効になっている場合があります。実際の動作は現在のドメイン設定とメールソフトによって決まります。

開封確認を依頼したことは受信者に分かりますか？

はい。これは意図した動作です。ソフトは受信者に通知したり、許可を求めたりできます。監視ではなく依頼です。

開封確認はメッセージが配信された証拠になりますか？

有効な通知は、メッセージが配信され、かつソフトに表示されたことを示します。通知がなくても何も証明できません。配信状況は送信ログと受信サーバーのSMTP応答で確認してください。

トラッキングピクセルを使っていますか？

いいえ。開封確認には、受信者のソフトが拒否できる標準MDNを使います。埋め込み画像や開封ビーコンはなく、この仕組みで受信者側のIPやユーザーエージェントを記録することもありません。

メッセージが転送されたか通知で分かりますか？

いいえ。MDNが報告するのは、元の受信者による処理だけです。転送は確認できません。