メールのしくみ 3：SMTP ― メールが届くまで

① アプリが、送信サーバーに頼む

最初の一歩で、アプリは自分では配達しません。送信サーバーに「このメールを、この宛先へ送って」と渡すだけです。郵便でいえば、手紙をポストに入れる段階です。

自分で配達しない理由は、配達に付いてくる仕事が多いからです。

これらは、アプリの本来の仕事（Animemo なら作品を作って見せること）とは関係がありません。だから専門の送信サーバーに任せます。

② 宛先ドメインの MX を引く

送信サーバーは、宛先 [email protected] の @ の右側、つまり gmail.com を見ます。そして2本目の DNS に問い合わせます。

「gmail.com の掲示板の MX の行を見せて」

返ってくるのは「gmail.com あてのメールは gmail-smtp-in.l.google.com が受け取る（優先順位 5）」という答えです。送信サーバーは、さらにこの名前の A レコードを引いて番号を知り、接続を始めます。

ここで分かるのは、メールの宛先探しも、結局は DNS で住所を引いているということです。@ の右側は、DNS で引けるドメイン名そのものです。

③ 受信サーバーへ、SMTP で渡す

受け取り先が分かったので、送信サーバーは Gmail の受信サーバーに接続して、メールを渡します。このとき使う会話の決まりが SMTP（Simple Mail Transfer Protocol）です。

プロトコルとは、コンピューター同士が話すときの作法のことです。「まず挨拶する」「次に差出人を言う」「次に宛先を言う」「最後に本文を送る」という順番と言い回しが決まっていて、その通りに話せば、どこの会社のサーバー同士でもメールを受け渡せます。

世界中のメールサーバーが同じ SMTP を話すからこそ、Gmail と Outlook と会社のメールのあいだで、メールが行き来できます。

SMTP の会話は、ほぼ平文のやりとり

SMTP の会話を、実際に近い形で覗いてみます。

送: EHLO a1-23.smtp-out.amazonses.com
受: 250 はい、どうぞ
送: MAIL FROM:<[email protected]>
受: 250 OK
送: RCPT TO:<[email protected]>
受: 250 OK
送: DATA
受: 354 本文をどうぞ。最後は「.」だけの行で
送: From: Animemo <[email protected]>
送: To: [email protected]
送: Subject: 招待が届いています
送:
送: 本文……
送: .
受: 250 受け取りました
送: QUIT

1行ずつの意味は次のとおりです。

送る側が1行言い、受ける側が番号付きの返事を返す、という繰り返しです。この番号には大事な意味があります（次のページ）。

※ MAIL FROM の実際の値は長い英数字ですが、ここでは分かりやすく bounce@… と書いています。

返事の番号で、次にどうするかが決まる

受信サーバーの返事には、必ず3桁の番号が付いています。最初の1桁で、送る側の次の行動が決まります。

たとえば 421（混んでいるので後で）なら、送信サーバーはしばらく待ってから再送します。550（そのアドレスは存在しない）なら、何度送っても無駄なので、すぐに諦めます。

この再送と諦めの判断を、送信サーバーが代わりにやってくれています。①で「アプリは自分で配達しない」と書いた理由の1つがこれです。自分でやるなら、数日にわたって再送を管理し続けるしくみが必要になります。

差出人は2つある：封筒と手紙

SMTP の会話には、差出人が2回出てきました。MAIL FROM の行と、DATA の後の From: の行です。この2つは別物です。

郵便で考えると分かりやすくなります。封筒の裏に書く返送先と、便箋の最後に書く署名は、別々に書けます。

Gmail の画面に「Animemo」と出るのは、手紙の差出人のほうです。封筒の差出人は、ふだん利用者の目には触れません（受け取った側で Return-Path: というヘッダーとして記録されるだけです）。

そして、ここがこのシリーズ全体でいちばん大事な点の1つです。どちらも、送る側が好きな値を書けます。 SMTP には、それが本当かどうかを確かめる手順がありません。

手紙の中身：ヘッダーと本文

DATA の後に送る「手紙の中身」は、ヘッダーと本文に分かれています。間は空行1つで区切ります。

ヘッダーは、手紙の冒頭にある決まった欄の並びです。

注意したいのは、ヘッダーの `To` と、封筒の宛先（`RCPT TO`）も別物だということです。BCC が成り立つのはこのためです。BCC の宛先は封筒にだけ書かれ、手紙のヘッダーには書かれないので、他の受信者には見えません。

本文は、HTML で飾った版と、文字だけの版の両方を入れて送ることが多いです。文字だけの版があると、HTML を表示しないメールソフトでも読めますし、迷惑メールの判定でも不自然に見えにくくなります。

通信路は暗号化されるが、差出人の証明にはならない

SMTP は、もともと平文（暗号化なし）でやりとりする決まりでした。これでは途中の中継機で中身を覗かれてしまいます。

そこで今は、会話の最初に STARTTLS という命令を出して、通信路を暗号化してから本題に入るのが普通です。Gmail は、暗号化できない相手からのメールを警告付きで表示します。

ただし、ここで誤解しやすい点があります。

暗号化は「途中で覗かれない」ためのもので、「差出人が本物である」ことの証明にはなりません。

偽の差出人を書いたメールも、きちんと暗号化して送れます。暗号化された通信路を通ってきたからといって、From: に書かれた名前が本当だとは限りません。

差出人が本物かどうかを確かめる仕組みは、SMTP とは別に、後から作られました。それが5〜7本目の SPF・DKIM・DMARC です。

④ 受信サーバーが判定して、行き先を決める

メールを受け取った Gmail は、そのまま受信トレイに入れるわけではありません。まず、このメールを信じてよいかを判定します。

結果は3通りです。問題が無ければ受信トレイへ。怪しければ迷惑メールフォルダへ。明らかに偽物なら受け取りを拒否して、送信サーバーに 5xx の返事を返します。

判定するのは受け取る側で、送る側にはどうにもできません。送る側にできるのは、「このメールは本物です」と判定してもらうための材料を、あらかじめきちんと揃えておくことだけです。

その材料が、5〜7本目の SPF・DKIM・DMARC と、8本目の評判です。

自分のサーバーから直接は送れない

「送信サーバーを使わず、アプリのサーバーから直接 Gmail に渡せばいいのでは？」と思うかもしれません。実際には、ほぼできません。

1本目で見たとおり、メールには窓口（ポート）が複数あります。

AWS や Google Cloud など多くのクラウドは、25番ポートからの外向きの通信を最初から塞いでいます。 乗っ取られたサーバーから迷惑メールが大量に流れるのを防ぐためです。

そのため、アプリは 587 番か 465 番で送信サーバーにログインして送信を頼み、25番で相手に渡す仕事は送信サーバーに任せます。Supabase に SMTP の設定を入れるとき、ホストに smtp.resend.com、ポートに 465 を指定するのは、この「頼むための入口」を使っているからです（9本目）。

届かなかったら、封筒の差出人へ知らせが戻る

宛先のアドレスが存在しないなどで受け取りを拒否されると、送信サーバーは「届きませんでした」という知らせを作ります。これをバウンス（バウンスメール）と呼びます。

この知らせが届くのは、手紙の `From:` ではなく、封筒の差出人です。封筒の差出人が「届かなかったときの返送先」だったのは、このためです。

受信サーバーが会話の途中で拒否した場合は、送信サーバーがその場で知ります。一方、いったん受け取ってから後で配れないと分かった場合は、受信サーバーが封筒の差出人のドメインの MX を引いて、知らせをメールとして送り返します。

ここから、10本目で出てくる設定の理由が見えてきます。封筒の差出人は、戻ってきた知らせを受け取れる住所でなければなりません。Resend の設定で「送るだけなのに MX を登録する」のは、この戻り道を作るためです。