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

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

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

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

この連載の進め方

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

第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）

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

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

送信と受信のプロトコル

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サーバー」設定＝リレー先。中継の許可が要る

代表的な製品とサービス

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. メールの設計演習