SMTP

概要

SMTP（Simple Mail Transfer Protocol）は、電子メールをサーバからサーバへ中継して届けるためのプロトコルです。あなたがメールを「送信」ボタンで送り出してから、相手の受信箱に届くまでの配送路を担っています。郵便にたとえるなら、ポストに投函された手紙を集配局から相手の地域の局まで運ぶ、幹線輸送の取り決めです。

1982 年に標準化され、40 年以上たった今も世界中のメールはこのプロトコルで流れています。インターネットの黎明期からほぼ姿を変えずに使われ続けている最古参級のプロトコルである一方、性善説で設計されたがゆえに迷惑メール・なりすましとの終わりなき戦いを抱え込んでおり、「古い設計を後付けの仕組みで補強しながら使い続ける」という、インターネットらしい進化の実例としても学びの多い語彙です。

なぜ生まれたか

電子メール自体は SMTP より古く、1970 年代には同じコンピュータの利用者同士でメッセージを残す仕組みがありました。しかしネットワークで結ばれた異なる組織のコンピュータ同士がメールを交換しようとすると、機種やシステムごとにやり方がバラバラで、相互接続のたびに個別の取り決めが必要でした。また、相手のコンピュータが落ちていたら送れない、という問題もあります。

SMTP はこれを「中継」というモデルで解決しました。送信者は自分の組織のメールサーバに預けるだけでよく、そのサーバが責任を持って相手の組織のサーバまで運ぶ。相手サーバが落ちていれば待って再送する。誰とでも同じ手順で話せる共通言語を定めたことで、組織の壁を越えたメール網が成立しました。宛先サーバの探し方も、後に DNS の MX レコードとして標準化され、「メールアドレスのドメイン名だけから配送先が引ける」現在の形が完成します。

詳細

送信から受信箱まで — メールの全経路

「メールを送る」の裏側では、複数のサーバがバケツリレーをしています。全体像を追ってみましょう。

（1）まず送信者のメールアプリは、自分の所属する送信側サーバへ SMTP でメールを預けます（このとき利用者認証が行われます）。（2）送信側サーバは宛先アドレスの @ より後ろ、たとえば example.com を取り出し、DNS に「このドメインのメールはどのサーバが受け取るのか」を照会します。この専用の問い合わせに答えるのが MX（Mail eXchanger）レコードで、Web サイトの場所とメールの受取先を別々のサーバに分けられるのはこのレコードのおかげです。（3）答えを得た送信側サーバは、受信側サーバへ TCP で接続し、SMTP の会話 — 名乗り、差出人、宛先、本文 — を交わしてメールを引き渡します。相手が応答しなければキューに積んで数時間〜数日にわたり再送を試みます。（4）受け取った受信側サーバは迷惑メール判定を経て受信箱に格納し、（5）受信者はそれを POP または IMAP という別のプロトコルで読みます。SMTP は「運ぶ」専用で、「読む」は別プロトコルの担当 — この分業は押さえておきたいポイントです（POP は端末へダウンロードして手元管理、IMAP はサーバに置いたまま複数端末で同期、という違いがあります）。

平文の時代から STARTTLS へ

SMTP は平文プロトコルとして生まれました。会話も本文もそのままネットワークを流れるため、経路上で盗聴・改ざんし放題です。しかし世界中のサーバが既にポート 25 で平文 SMTP を話している以上、「明日から暗号化ポートに全員移行」は不可能でした。そこで採られたのが STARTTLS という後付けの仕組みです。まず平文で会話を始め、双方が対応していればその場で TLS 暗号化に切り替える。非対応の相手とは平文のまま続けられるため、互換性を壊さずに暗号化を普及させられました。現在ではサーバ間通信の大半が暗号化されていますが、「切り替え要求を攻撃者が握りつぶすと平文にダウングレードされる」という構造的な弱点も持ち、それを塞ぐ仕組み（MTA-STS など）がさらに後付けされています。

なりすましとの戦い — SPF / DKIM / DMARC

SMTP 最大の問題は、差出人を検証する仕組みが元々ないことです。プロトコル上、差出人アドレスはただの自己申告で、誰でも you@example.com を名乗ってメールを送れてしまいます。この性善説の穴が迷惑メールとフィッシングの温床となり、それを塞ぐために「送信ドメイン認証」と総称される 3 つの仕組みが積み上げられました。いずれも DNS に検証情報を置く、という共通の発想です。

SPF（Sender Policy Framework）は「うちのドメインのメールを送ってよいサーバの IPアドレスはこれです」というリストを DNS で公開し、受信側が実際の送信元 IP と照合する仕組みです。DKIM（DomainKeys Identified Mail）は送信サーバがメールに電子署名を付け、受信側が DNS で公開された検証鍵で署名を確かめる仕組みで、公開鍵暗号の応用により「本文が途中で改ざんされていないこと」まで保証できます。そして DMARC は、SPF・DKIM の検証に失敗したメールを「受け取る/隔離する/拒否する」のどれで処遇してほしいかをドメイン所有者が宣言し、検証結果のレポートを受け取る仕組みです。2024 年には Gmail が大量送信者に DMARC 対応を事実上義務化し、いまや Web サービスからメールを送る開発者にとって、この 3 点セットの設定は避けて通れない実務知識になっています。「自社サービスの通知メールが迷惑メール判定される」というトラブルの原因は、たいていここにあります。