【メール入門 第1回】メールが届くまで ― 全体像・登場人物・MX・直接配送とリレー

「メールが届かないんですけど、うちのサーバーの問題ですか？」
「vCenterの通知メール、急に送れなくなりました」

メールは古い技術と思われがちですが、今も取引先との連絡、パスワードの再設定、監視やvCenter・複合機からの通知など、業務の多くを支えています。そして「届かない」「迷惑メールに入る」「急に送れなくなった」という問い合わせは、原因がメールソフト、送信サーバー、DNS、経路、受信側のどこにあるのか分かりにくいのが特徴です。

この連載では、メールが届くまでの登場人物とSMTPのやり取り、メッセージの構造から始め、ポートと暗号化、SPF・DKIM・DMARCによる送信ドメイン認証、迷惑メール対策、Postfixの運用、Microsoft 365などクラウドでの送り方、トラブルの切り分けまでを順に扱います。仕様や数値は2026年9月時点の情報（送信者ガイドライン、Basic認証の廃止など）に合わせています。

第1回は、1通のメールが、誰の手を経て届くのかです。

送る機器が変わっても、運ぶ仕組みはSMTPです。

---

この連載の進め方

全12回で、次の順に進めます。

回	テーマ	主な内容
第1回	メールが届くまで	全体像、登場人物、MX、直接配送とリレー
第2回	SMTPのやり取り	コマンドと応答、リプライコード、バウンス
第3回	メッセージの構造	ヘッダーとボディ、エンベロープ、MIME、日本語
第4回	ポートと暗号化・認証	25・587・465、STARTTLS、MTA-STS、SMTP AUTH
第5回	送信ドメイン認証 前編	なりすまし、SPF、DKIM、DMARC の仕組み
第6回	送信ドメイン認証 後編	DMARC の運用、転送、BIMI、送信者ガイドライン
第7回	迷惑メール対策と配信	DNSBL、レピュテーション、逆引き、OP25B
第8回	MTA の運用	Postfix の構成、キュー、リレー制御、ログ
第9回	コマンドで調べる	dig、nc、openssl、swaks、ヘッダーの解析
第10回	クラウドと現代のメール	Microsoft 365、Google Workspace、Amazon SES
第11回	トラブルシュート	「届かない」の切り分け、よくあるエラー、まとめ
第12回	設計演習	5つのケースで考える

第1回〜第3回が土台です。特に今回の「登場人物」、第2回の「リプライコード」、第3回の「エンベロープとヘッダーの違い」は、後のすべての回で使います。コマンドはLinux・Macのdig・nc・opensslを中心に、Windows標準のPowerShellでの手順も併記します（WSLは前提にしません）。各回の最後にある「考えてみよう」は、自分の職場の環境を思い浮かべながら答えてみてください。

メールはDNSや証明書とも深く関わります。前の連載「DNS入門」と「証明書入門」もあわせて読むと、理解が深まります。メールを受け取る側（POP・IMAP）は、連載「POP・IMAP入門」で扱います。

---

メールが届くまでの流れ

自社の山田さん（taro@example.jp）が、取引先の花子さん（hanako@example.com）へメールを送る場合を追ってみます。

1. 山田さんのメールソフトは、自社の送信サーバーに587番で接続し、認証してからメールを渡す
2. 送信サーバーは、宛先のドメインexample.comのMXレコードをDNSで引き、受け取り役のサーバーを知る
3. 送信サーバーは、そのサーバーへ25番で接続し、SMTPでメールを渡す
4. 受信側のサーバーは、宛先が自分の担当だと確かめて、メールボックスに格納する
5. 花子さんのメールソフトは、IMAPやPOPでメールボックスから取り出して表示する

①と③がSMTP、⑤は別のプロトコルです。メールはサーバーからサーバーへ預けられて進み、各サーバーは受け取るたびに記録（Receivedヘッダー、第3回）を残します。

届かないときは、①〜⑤のどの区間で止まったかを探す。これがメールのトラブル対応の基本です。

ポイント
・送る（SMTP）と読む（IMAP・POP）は別のプロトコル
・送信サーバーは宛先ドメインのMXをDNSで引いて届け先を決める
・メールはサーバーに預けられながら進み、各段で記録が残る

---

登場人物（RFC 5598）

メールの世界には、役割の違う登場人物がいます。

略称	正式名（RFC 5598）	何をするか	身近な例
MUA	Message User Agent	メールを書く・読む。送る側も読む側もこれ	Outlook、Thunderbird、Gmail の画面、vCenter・複合機の通知機能
MSA	Message Submission Agent	MUA からの送信を受け付け、認証とポリシーを確かめる	587・465 番で待つ送信サーバー
MTA	Message Transfer Agent	次のサーバーへ中継する。宛先の MX を引いて配送する	Postfix、Exchange のトランスポート、Microsoft 365
MDA	Message Delivery Agent	受け取ったメールを受信者のメールボックスへ格納する	Postfix の local・virtual、Dovecot の LDA・LMTP
MS	Message Store	メールを保管し、MUA に IMAP・POP で取り出させる	Dovecot、Exchange のメールボックス

MTAはMail Transfer Agentとも呼ばれます。役割名はRFC 5598（2009年）が整理しました。規格上はSMTPクライアント・サーバーと呼びます。よく見かけるMRA（Mail Retrieval Agent）という言葉はRFC 5598には無く、MSの入口（IMAP・POPで取り出させる部分）に当たります。実際の製品は複数の役割を1台で担うため、切り分けは役割ごとに考えます。たとえばPostfixは、MSA・MTA・MDAのすべてを担えます。

---

送信と受信のプロトコル

プロトコル	区間	ポート	規格
SMTP（中継）	MTA → MTA	25	RFC 5321
サブミッション（投稿）	MUA → MSA	587（STARTTLS）、465（最初から TLS）	RFC 6409、RFC 8314
LMTP	MTA → MDA・MS	UNIX ソケットや任意のポート	RFC 2033
POP3	MS → MUA（手元に取り込む）	110、995（TLS）	RFC 1939
IMAP4	MS ↔ MUA（サーバーに置いたまま見る）	143、993（TLS）	RFC 9051（IMAP4rev2）、RFC 3501
JMAP	MS ↔ MUA（HTTPS と JSON）	443	RFC 8620、RFC 8621
製品独自の API	Outlook ↔ Exchange・Microsoft 365、Gmail アプリ等	443	MAPI over HTTP、Microsoft Graph、Gmail API など

SMTPは「送る」、POP・IMAPは「読む」ためのプロトコルです（POP・IMAPは連載「POP・IMAP入門」第1回（メールを読む仕組み）で扱います）。JMAP（2019年）は、IMAPをHTTPSとJSONで置き換える新しい規格です。

OutlookとExchange・Microsoft 365の間はSMTPではありませんが、組織の外へ出るときは必ずSMTPです。ポートと暗号化は第4回で扱います。

---

MXで配送先を決める

送信側のMTAは、宛先アドレスの@より右のドメインについてMX（Mail eXchange）レコードをDNSで引き、届け先のサーバーを決めます。

• MXには優先度が付いており、値が小さいほど優先。送信側はまず最も優先度の高いサーバーへ接続し、つながらなければ次のサーバーを試す
• 同じ優先度が複数あれば、その中からばらけて選ぶ
• どこにもつながらなければ、あきらめずにキューに残して後で再送する（第2回）

MXが無い、または受け取らないときの動きも押さえておきましょう。

• MXが無い → ドメイン名そのもののA・AAAAレコードを配送先とみなす（RFC 5321の「暗黙のMX」）
• MX 0 .（Null MX） → 受け取らない。送信側ですぐエラーになる（RFC 7505）
• ドメインが無い（NXDOMAIN） → すぐエラーになる

そのため、メールを受け取らないドメインは、Null MXを置いて受け取らないことをはっきり示します。優先度は「試す順番」、と覚えておきましょう。

---

MXを引いてみる

実際にMXを引いてみます（値は例示用で、名前・TTLは架空です）。

$ dig example.jp MX +noall +answer
example.jp.		3600	IN	MX	10 mx1.example.jp.
example.jp.		3600	IN	MX	20 mx2.example.jp.

$ dig noreply.example.jp MX +noall +answer
noreply.example.jp.	3600	IN	MX	0 .

PS> Resolve-DnsName example.jp -Type MX

Name          Type   TTL   Section    NameExchange      Preference
----          ----   ---   -------    ------------      ----------
example.jp    MX     3600  Answer     mx1.example.jp    10
example.jp    MX     3600  Answer     mx2.example.jp    20

• 優先度10のmx1が主、20のmx2が予備。WindowsではResolve-DnsName -Type MXで同じことが分かる（Windows 11・Windows Server 2025 の表示。Windows Server 2016 では1件ずつ縦に並ぶ形で表示される）
• MX 0 .はNull MX。このドメイン宛てのメールは、送信側ですぐにエラーになる（拡張ステータスコード5.1.10、第2回）
• 予備のMXは、宛先の確認や迷惑メール対策を主のMXと同じにする。予備だけ甘いと、迷惑メールの抜け道になる

文書用ドメインのexample.comは、実際にNull MXを公開しています（2026年9月確認）。例示用のアドレスに試しに送っても届きません。MXの書き方と注意点（値にIPアドレスやCNAMEの名前を書かない等）は、連載「DNS入門」の第6回を参照してください。

---

直接配送とリレー（スマートホスト）

メールの送り方には、直接配送とリレーがあります。

• 直接配送：送信サーバーが自分で宛先のMXを引き、相手の受信サーバーへ25番で届ける方式。インターネット上の配送は、最後は必ずこの形
• リレー：決めた中継サーバー（スマートホスト、Postfixではrelayhost）へ渡す方式

企業では、機器やアプリから直接送らせず、社内のリレーサーバーやMicrosoft 365・Amazon SESなどに集めるのが普通です。理由は次のとおりです。

• ウイルス対策やアーカイブを1か所で行える
• 機器にTLSや認証の機能が足りない
• 機器がインターネットに出られない
• 送信元のIPアドレスを絞って、SPFや逆引き（PTR）を整えやすい
• クラウドや回線事業者が、外向きの25番を制限している（第7回・第10回）

冒頭の「vCenterの通知が急に送れない」の話につながりますが、vCenterや複合機の「SMTPサーバー」欄に書くのは、このリレー先です。リレーするには、リレーサーバー側で中継の許可が必要です（第8回）。

ポイント
・直接配送は自分でMXを引いて届け、リレーは決めた中継先へ渡す
・企業では対策の集約・機器の機能不足・出口の一元化のためリレーが主流
・機器の「SMTPサーバー」設定＝リレー先。中継の許可が要る

---

代表的な製品とサービス

種類	製品・サービス	2026年9月の状況
OSS の MTA	Postfix	3.11 系が安定版（3.11.7、2026年9月7日）。RHEL 系の標準で、この連載の第8回で扱う
OSS の MTA	Exim	4.100 が最新版。Debian 系で使われることが多い
OSS の MTA	Sendmail	8.18.2（2025年12月）。RHEL 10 で同梱が終了。新規の採用は勧めない
オンプレミス	Exchange Server	Subscription Edition（SE、2025年7月に一般提供）のみサポート。2016・2019 は2025年10月14日に終了
クラウド	Microsoft 365（Exchange Online）	旧 Office 365（2020年に改称）。第10回
クラウド	Google Workspace（Gmail）	第10回
クラウド（送信）	Amazon SES	アプリ・機器からの通知や大量送信向け。第10回
ゲートウェイ	Cisco Secure Email Gateway（旧 ESA）など	受信・送信の間に置く迷惑メール・ウイルス対策の関所。第7回

MUAは、Outlook（従来のOutlookと新しいOutlook）、Thunderbird、Gmail、スマホのメールアプリのほか、vCenter・複合機・監視装置の通知機能も含みます。サーバー側から見れば、人が操作するメールソフトも機器も、同じSMTPクライアントです。

---

考えてみよう

1. 自社のドメインのMXを引いてください。受信サーバーは何台あり、優先度はどうなっていますか。それは自社のサーバーですか、クラウドや受信ゲートウェイですか。
2. 職場のvCenter・複合機・監視サーバーは、どのサーバーにメールを渡していますか。そこから先、インターネットに出るまでに何台を経由しますか。
3. メールを受け取る予定のないドメイン（Web専用のドメインなど）を持っていませんか。Null MXを置くと何がよくなりますか。

ヒント：この記事の「MXを引いてみる」のdig・Resolve-DnsName、「直接配送とリレー」の考え方、「MXで配送先を決める」の「MXが無いときの動き」が手がかりです。

---

まとめ

• メールは送る（SMTP）と読む（IMAP・POP）で別のプロトコル
• 登場人物はMUA・MSA・MTA・MDA・MS。製品は複数の役割を担うので、役割ごとに切り分ける
• 送信側は宛先ドメインのMXを引き、優先度の小さい順に試す。受け取らないドメインはNull MX
• 企業では機器やアプリから直接送らず、リレー（スマートホスト）に集めるのが主流
• 「届かない」は、どの区間で止まったかから探す

次回は、サーバー同士が実際にどんな会話（コマンドと応答）でメールを渡しているかを見ます。

---

連載「メール入門」全12回

1. メールが届くまで（この記事）
2. SMTPのやり取り
3. メッセージの構造
4. ポートと暗号化・認証
5. 送信ドメイン認証 前編
6. 送信ドメイン認証 後編
7. 迷惑メール対策と配信
8. MTAの運用
9. コマンドで調べる
10. クラウドと現代のメール
11. メールのトラブルシュート
12. メールの設計演習