メールのしくみ保存先へ届けてから、
相手が読みに行く。

相手のスマホが眠っていても、メールが届く理由

電子メールは、送る人の端末から受け取る人の端末へ、その場で直接渡す仕組みではありません。メールを扱うサーバーが受け渡し、受信側で保存します。相手は後からその保存先へアクセスして読めるので、二人が同時にオンラインである必要はありません。

電話なら通話中のつながりが必要ですが、メールは途中で引き受けたシステムが次へ渡す「蓄積して転送する」方式です。相手のスマホの電源が切れていても、受信側のサーバーが利用できれば配送は進みます。ただし、宛先の誤り、障害、容量や受信ルールなどにより届かないこともあります。

図1では、送信側、配送先を調べるDNS、受信側、保存先、読む端末を分けました。これは役割の図です。一台のサーバーが複数の役割を担当することも、複数の中継や迷惑メール検査を挟むこともあります。緑の矢印はメールの受け渡し、青い矢印は保存後の閲覧要求とデータ、橙の破線はDNSの問い合わせと答えです。

送信ボタンから、相手の保存先まで

メールアプリは、宛先、件名、本文、添付などを用意して送信サービスへ渡します。利用者が新しいメールを預ける段階を「投稿」といい、送信サービスは通常、利用者の認証を行います。専用アプリではSMTPに基づく投稿の仕組みを使い、Webメールではまずブラウザからサービスへ操作を送ります。

送信側の配送システムは、宛先アドレスのドメイン部分、つまり @ の後ろの名前を手がかりに配送先を決めます。一般的にはDNSのMXレコードを調べ、メールを受けるサーバー名と優先順位を得て、その名前のIPアドレスも調べます。DNSはメール本文を運ぶ係ではありません。図の上に分けた橙の破線は、この行き先を調べる通信です。

MXレコードがない場合に、そのドメインのアドレス情報を使う規則もあります。社内の配送、決められた中継先、同じサービス内の相手などでは経路が違うこともあるため、すべてのメールが図と同じ台数を通るわけではありません。

サーバー間の受け渡しにはSMTPを使います。相手サーバーがメール全体を受け取って成功応答を返すと、次の配送を引き受ける責任が移ります。この成功は、相手が画面を開いて読んだという報告ではありません。最終的に受信側で利用者の保存先へ渡され、受信ルールに応じて受信箱や別のフォルダーなどから見られるようになります。

配送指示と、画面に見える宛先は別にある

メールには、配送用の情報と、件名・本文などを含むメッセージがあります。配送用の情報を「エンベロープ」と呼びます。紙の封筒にたとえる名前ですが、実際にはSMTPのやり取りで、エラーの返送先や今回の配送先を指定する情報です。

図2の上段は配送指示、下段はメッセージを表します。メッセージの先頭にはヘッダーがあり、From（差出人）、To（宛先）、Cc、Subject（件名）などを記載します。図の横線は値のある場所を示すだけで、実際のアドレスやメールの書式を再現したものではありません。

↔ 表が収まらない場合は、横にスクロールして比較できます。

Bccの宛先にも配送用の宛先を指定しますが、他の受信者にそのアドレスを見せないよう、配送するコピーからBccの行を取り除くなどの処理をします。仕様には複数の処理方法があり、Bcc欄の表示がすべてのコピーで同じになるとは限りません。Bccは本文を暗号化する機能でも、配送システムから宛先を隠す機能でもありません。

添付ファイルも、普通はメールとは別に独立して飛んでいくのではなく、MIMEという形式で本文を複数の部分に分け、その一部として運ばれます。図2の下段は文字の部分と文書の部分を並べた概念図です。クラウド上のファイルへのリンクを送る方法は、この添付とは区別します。

ファイルのデータをBase64という文字表現へ変換する場合、その部分のデータ量はおよそ3分の1増えます。改行やヘッダーなども加わるため、送るメール全体のサイズは元ファイルと同じではありません。変換はデータを運ぶための符号化で、秘密にする暗号化ではありません。

拡大して見る ↗

1. エンベロープの返送先：配送失敗の通知など
2. エンベロープの宛先：今回の配送先
3. ヘッダー：From・To・Cc・件名など
4. 本文の文字部分：読者に見せる内容
5. 本文の添付部分：MIMEで区切る文書など

SMTPで届ける。IMAPやWebメールで見る

受信側に保存されたメールを読む段階は、配送と別の通信です。メールアプリは、保存先のサービスに本人としてログインし、一覧や本文を取り出します。相手のアプリが読む操作をして初めて、保存済みの情報がその端末へ届くこともあります。

↔ 表が収まらない場合は、横にスクロールして比較できます。

IMAPを使っていても、削除したメールが永久に残るわけではありません。アプリの操作がサーバーへ反映されれば、別の端末からも見えなくなる場合があります。逆にPOP3だから必ず取得直後にサーバーから消える、という説明も不正確です。

Webページの表示と同じブラウザで読めることと、メールの配送にHTTPを使うことは別です。図1の青い矢印は、保存先への要求と、表示する情報の戻りを分けています。ブラウザで読む場合はWebメールのサービスを経由し、ブラウザが相手の受信サーバーへ直接SMTPでつなぐわけではありません。

「送信済み」は、どこまで進んだ知らせ？

送信済みフォルダーにコピーがあること、送信サービスが引き受けたこと、相手の保存先へ渡されたこと、相手が読んだことは、別の段階です。送信済みの表示やフォルダーへ保存するタイミングはサービスによって違うため、その表示だけから最後までの成功を判断できません。

配送先が一時的に応答しないなどの場合、配送システムは待ち行列に保持して、時間をおいて再試行することがあります。存在しない宛先など、そのまま再試行しても解決しない失敗は、すぐ拒否されることもあります。待つ時間や再試行を終える条件はシステムの運用によって違います。

配送失敗の通知は、必ず画面の差出人へ戻るとは限りません。エンベロープの返送先へ戻すのが基本で、送信サービスが通知をまとめて利用者へ知らせる場合もあります。通知自体が届かない場合もあり、エラー通知がないことだけで配達完了とはいえません。

受信側のシステムに受け付けられても、迷惑メールフォルダーや隔離先へ振り分けられる場合があります。「受信箱に見当たらない」ときは、配送前の失敗と、受信後の分類を分けて考える必要があります。

開封確認は配送とは別の通知機能です。受信側の対応や設定に左右され、通知を返さないこともあります。また、表示されたという通知でも、本人が文章を読んで理解したことまでは保証しません。

拡大して見る ↗

1. 送信済み：送る側の表示・保存。サービスによってタイミングが異なる。
2. 配達・保存：受信側に渡され、保存される段階。
3. 閲覧：本人が読む段階。理解したことまで配送で保証できない。

暗号化は、どの区間を守るのか

TLSは、通信中のデータを保護する仕組みです。メールアプリから投稿先、送信サーバーから次のサーバー、保存先から読む端末など、接続ごとに考えます。図1の矢印は仕事の流れを示しており、すべての区間でTLSが必ず使われていることを表すものではありません。

投稿と閲覧の通信ではTLSを使うことが推奨されています。一方、サーバー間の配送では、その接続相手と設定に応じてTLSの利用や検証条件が決まります。暗号化を要求する方針を公開するMTA-STSなどの仕組みもありますが、どの相手との配送でも自動的に同じ保証になるわけではありません。

TLSで各区間を保護しても、接続の終点であるサーバーは、通常のメールを処理するために内容を扱います。送る人と受け取る人だけが本文を読めるようにする「エンドツーエンド暗号化」は、別の仕組みです。サーバーの保存データを暗号化することとも区別します。

Webメールの画面がHTTPSで開いていることは、ブラウザとそのサービスの通信を保護しているという意味です。別のサービスへのメール配送まで同じ接続で保護している、という意味ではありません。

差出人の表示だけで、本人とは決められない

画面の差出人名やFromは、メッセージに書かれた情報です。その文字が本物らしく見えることだけで、本人が書いた証拠にはなりません。受信側は、ドメインの使用を確かめる仕組みと、内容や送信状況などの判断を組み合わせます。

• SPF：SMTPの返送先などに使われるドメインについて、接続してきた送信サーバーが、DNSに公開された許可の範囲に入るかを調べます。画面のFromを直接確認する仕組みとは限りません。
• DKIM：署名したドメインの公開鍵を使い、署名対象のヘッダーや本文を検証します。署名が通ることは、署名したドメインとの関係を確かめる材料で、内容の正しさを証明するものではありません。
• DMARC：SPFまたはDKIMで認証されたドメインが、画面のFromのドメインと規則に沿って対応するかを確かめます。ドメイン側は、失敗したメールをどう扱ってほしいかの方針を公開でき、受信側が扱いを判断する材料になります。

これらは本文を秘密にする暗号化ではありません。正しく認証された攻撃者自身のドメイン、似た文字を使ったドメイン、乗っ取られたアカウントからのメールなどは、認証だけでは排除できません。認証成功と、安全な内容・確実な受信箱への配達を同じ意味にしないことが大切です。

電子メールの仕組みを説明するときは、「どこへ渡すか」「どこに保存するか」「どう読みに行くか」「何を保護・確認するか」の四つを追ってみてください。送信ボタンの後ろで起きる仕事が、ひと続きの通信だけではないことが分かります。