「メールが届かないんですけど、うちのサーバーの問題ですか？」
「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）へメールを送る場合を追ってみます。
- 山田さんのメールソフトは、自社の送信サーバーに587番で接続し、認証してからメールを渡す
- 送信サーバーは、宛先のドメイン
example.comのMXレコードをDNSで引き、受け取り役のサーバーを知る - 送信サーバーは、そのサーバーへ25番で接続し、SMTPでメールを渡す
- 受信側のサーバーは、宛先が自分の担当だと確かめて、メールボックスに格納する
- 花子さんのメールソフトは、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クライアントです。
考えてみよう
- 自社のドメインのMXを引いてください。受信サーバーは何台あり、優先度はどうなっていますか。それは自社のサーバーですか、クラウドや受信ゲートウェイですか。
- 職場のvCenter・複合機・監視サーバーは、どのサーバーにメールを渡していますか。そこから先、インターネットに出るまでに何台を経由しますか。
- メールを受け取る予定のないドメイン（Web専用のドメインなど）を持っていませんか。Null MXを置くと何がよくなりますか。
ヒント：この記事の「MXを引いてみる」のdig・Resolve-DnsName、「直接配送とリレー」の考え方、「MXで配送先を決める」の「MXが無いときの動き」が手がかりです。
まとめ
- メールは送る（SMTP）と読む（IMAP・POP）で別のプロトコル
- 登場人物はMUA・MSA・MTA・MDA・MS。製品は複数の役割を担うので、役割ごとに切り分ける
- 送信側は宛先ドメインのMXを引き、優先度の小さい順に試す。受け取らないドメインはNull MX
- 企業では機器やアプリから直接送らず、リレー（スマートホスト）に集めるのが主流
- 「届かない」は、どの区間で止まったかから探す
次回は、サーバー同士が実際にどんな会話（コマンドと応答）でメールを渡しているかを見ます。
連載「メール入門」全12回
- メールが届くまで（この記事）
- SMTPのやり取り
- メッセージの構造
- ポートと暗号化・認証
- 送信ドメイン認証 前編
- 送信ドメイン認証 後編
- 迷惑メール対策と配信
- MTAの運用
- コマンドで調べる
- クラウドと現代のメール
- メールのトラブルシュート
- メールの設計演習
コメント