SMTP
SMTP ・ えすえむてぃーぴー
電子メールをサーバからサーバへ中継して届けるプロトコル。送信ドメイン認証でなりすましと戦う。
✦ 30秒で試す — 航海40年前の設計のまま、世界中の手紙が今日も運ばれているこのメールは、SPF と DKIM の検証でどうなる？予想してみる概要
SMTP（Simple Mail Transfer Protocol）は、電子メールをサーバからサーバへ中継して届けるためのプロトコルです。あなたがメールの「送信」ボタンを押してから、相手の受信箱に届くまでの配送路を担っています。郵便にたとえるなら、ポストに投函された手紙を集配局から相手の地域の局まで運ぶ、幹線輸送の取り決めです。
1982年に標準化され（RFC 821、現行は RFC 5321）、40年以上たったいまも世界中のメールはこのプロトコルで流れています。インターネットの黎明期からほぼ姿を変えずに使われ続けている最古参のプロトコルの1つである一方、性善説で設計されたために迷惑メール・なりすましとの終わりのない戦いを抱えています。「古い設計を後付けの仕組みで補強しながら使い続ける」という、インターネットらしい進化の実例としても学びの多い語彙です。
なぜ生まれたか
電子メール自体は SMTP より古く、1970年代には同じコンピュータの利用者どうしでメッセージを残す仕組みや、ARPANET 上でファイル転送の仕組みを流用してメールを送るやり方がありました。しかし異なる組織のコンピュータどうしがメールを交換しようとすると、機種やシステムごとにやり方がばらばらで、相互接続のたびに個別の取り決めが必要でした。相手のコンピュータが止まっていたら送れない、という問題もありました。
SMTP はこれを「中継」というモデルで解きました。送信者は自分の組織のメールサーバに預けるだけでよく、そのサーバが責任を持って相手の組織のサーバまで運びます。相手が止まっていれば待って再送します。誰とでも同じ手順で話せる共通の言葉を定めたことで、組織の壁を越えたメール網が成り立ちました。宛先サーバの探し方も、のちに DNS の MX レコードとして標準化され、「メールアドレスのドメイン名だけから配送先が引ける」いまの形が完成します。
詳細
送信から受信箱まで: メールの全経路
「メールを送る」の裏側では、複数のサーバがバケツリレーをしています。メールアプリ（ブラウザで使う Web メールなら、その Web メールのサーバ）を1人の参加者として置くと、全体の流れが見えます。
（1）まず送信者のメールアプリは、自分が使っている送信側サーバへメールを預けます。これは「投稿（submission）」と呼ばれ、ポート 587 番で、利用者の認証と TLS の暗号化を伴って行うのが標準です（最初から TLS で包む 465 番も使われます）。（2）送信側サーバは宛先アドレスの @ より後ろ、たとえば example.com を取り出し、DNS に「このドメインのメールはどのサーバが受け取るのか」を照会します。これに答えるのが MX（Mail eXchanger）レコードで、Web サイトの置き場所とメールの受け取り先を別々のサーバに分けられるのはこのおかげです。
（3）答えを得た送信側サーバは、受信側サーバのポート番号 25 番へ TCP/IP の TCP で接続し、SMTP の会話を交わしてメールを引き渡します。会話は HELO（名乗り）、MAIL FROM（差出人）、RCPT TO（宛先）、DATA（本文）という短いコマンドの往復です。相手が応答しなければキューに積み、数時間から数日にわたって再送を試みます。（4）受け取った受信側サーバは、後で見る送信元の検証と迷惑メールの判定を経て受信箱に格納し、（5）受信者はそれを IMAP や POP という別のプロトコルで読みます。SMTP は「運ぶ」専用で、「読む」は別プロトコルの担当です（IMAP はサーバに置いたまま複数の端末で同期し、POP は端末へダウンロードして手元で管理します）。
投稿の 587 番と中継の 25 番を分けているのには理由があります。多くのプロバイダは、利用者の回線から外部の 25 番への接続を遮断しています（日本では OP25B と呼ばれます）。乗っ取られた家庭の PC が直接迷惑メールをばらまくのを防ぐためで、正規の利用者は認証付きの 587 番で自分のサーバに預け、サーバどうしの中継だけが 25 番を使う、という役割分担になっています。
封筒と便箋: 2つの「差出人」
SMTP のメールには差出人が2つあります。1つは SMTP の会話の MAIL FROM で伝える「封筒の差出人」で、配送できなかったときのエラー通知の返送先に使われます。もう1つは本文の先頭のヘッダに書かれた From: で、メールアプリが「差出人」として画面に表示するのはこちらです。この2つは一致しなくてもかまいません。配信サービスを使うと、封筒は bounce@esp.net（配信事業者のドメイン）、便箋は shop@example.com ということが普通に起こります。そしてプロトコルの上では、どちらも単なる自己申告です。
平文の時代から STARTTLS へ
SMTP は平文のプロトコルとして生まれました。会話も本文もそのままネットワークを流れるので、経路の上で盗聴も改ざんもできてしまいます。しかし世界中のサーバがすでに 25 番で平文の SMTP を話している以上、「明日から暗号化ポートに全員移行」は不可能でした。そこで採られたのが STARTTLS という後付けの仕組みです。まず平文で会話を始め、双方が対応していればその場で TLS による暗号化に切り替えます。非対応の相手とは平文のまま続けられるので、互換性を壊さずに暗号化を広められました。いまではサーバ間の通信の大半が暗号化されていますが、「切り替えの申し出を攻撃者が握りつぶすと平文に落とされる」という構造的な弱点があり、それを塞ぐ MTA-STS（受信側が「必ず TLS で来て」と宣言する仕組み）などがさらに後付けされています。
なりすましとの戦い: SPF・DKIM・DMARC
SMTP 最大の問題は、差出人を検証する仕組みがもともとないことです。誰でも you@example.com を名乗ってメールを送れてしまいます。この穴が迷惑メールとフィッシングの温床となり、それを塞ぐために「送信ドメイン認証」と総称される3つの仕組みが積み上げられました。いずれも、差出人のドメインの持ち主が DNS に検証の材料を公開する、という共通の発想です。
SPF（Sender Policy Framework）は、「このドメインのメールを送ってよいサーバの IPアドレスはこれです」というリストを DNS の TXT レコードで公開し、受信側が実際に接続してきた送信元の IP と照合する仕組みです。照合に使うのは封筒の差出人（MAIL FROM）のドメインです。DKIM（DomainKeys Identified Mail）は、送信サーバがメールのヘッダと本文に電子署名を付け、受信側が署名に書かれたドメイン（d=）の DNS から公開鍵を取って確かめる仕組みです。公開鍵暗号の応用で、途中で本文が改ざんされていないことまで保証できます。
ところが、SPF と DKIM だけではなりすましは防げません。攻撃者が自分で取った evil.example のドメインで SPF も DKIM も正しく設定し、ヘッダの From にだけ shop@example.com と書けば、どちらの検証にも合格してしまうからです。利用者が目にするのはヘッダの From なのに、検証されていたのは別のドメインだった、という隙間です。
この隙間を塞ぐのが DMARC（Domain-based Message Authentication, Reporting and Conformance）の核心、アラインメント（ドメインの一致）です。DMARC は「SPF か DKIM のどちらかが合格し、かつその合格したドメインがヘッダの From のドメインと一致すること」を求めます。そのうえで、ドメインの持ち主は _dmarc.example.com の TXT レコードに、合格しなかったメールを受信側にどう扱ってほしいか（p=none は何もせず報告だけ、p=quarantine は迷惑メールフォルダへ隔離、p=reject は受け取り拒否）と、検証結果の集計レポートの送り先を宣言します。
図の例では、配信事業者経由で送ったため SPF は esp.net で合格しても From とは一致しませんが、DKIM の署名を自社ドメイン example.com で付けているので DMARC に合格します。配信サービスを使うときに「DKIM を独自ドメインで署名する設定」が求められるのはこのためです。
2024年には Gmail と Yahoo が、1日に大量のメールを送る送信者に SPF・DKIM・DMARC の設定を事実上義務付けました。Web サービスから通知メールを送る開発者にとって、この3点セットは避けて通れない実務知識です。「自社サービスのメールが迷惑メールに入る」というトラブルの原因は、たいていここにあります。導入は p=none で始めてレポートを読み、自社の正規の送信元（配信サービス・問い合わせフォーム・社内システム）がすべて一致して合格することを確かめてから、quarantine・reject へと段階的に強めるのが定石です。いきなり reject にすると、設定漏れの正規メールまで届かなくなります。
試問
example.com の持ち主として、自社を名乗って届くメールを守る立場です。届いた6通は、どれも画面に表示される差出人（ヘッダの From）が shop@example.com です。受信側では、SPF（送信元サーバが、あるドメインの許可リストに載っているか）と DKIM（メールの電子署名が、あるドメインの鍵で正しく検証できるか）がそれぞれ「どのドメインで合格したか」を返し、DMARC がその結果を見て受け取るかを決めます。
差出人が shop@example.com の6通を、DMARC に合格するものと不合格になるものに仕分けよ
項目を選んでから、入れる箱を選びます