SMTP

この用語をシェア

SMTPとは

SMTP（Simple Mail Transfer Protocol）は、電子メールの送信・転送に使用される標準プロトコルです。1982年にJon PostelによってRFC 821として定義され、現在はSMTP拡張仕様であるESMTP（Extended SMTP）を取り込んだRFC 5321（2008年）が標準として運用されています。メールサーバー同士（MTA間）の通信や、メールクライアント（またはアプリケーション）からメールサーバーへの送信に使用される、インターネットメールの根幹を成すプロトコルです。

SMTPはあくまで「送信・転送」を担うプロトコルであり、受信者がメールを読み出す仕組み（POP3やIMAP）とは役割が明確に分離されています。この非対称性はインターネットメールの設計思想の根幹であり、自社メールサーバーを構築する際にも「SMTPは送信経路、POP3/IMAPは受信経路」という区分を理解しておくことが、トラブルシューティングの第一歩になります。

SMTPの仕組み

エンベロープとヘッダーの違い

SMTPを理解する上でつまずきやすいのが、エンベロープ（封筒）情報とメールヘッダーが別物である点です。MAIL FROMとRCPT TOで指定するアドレスは配送先を決めるための「封筒の宛名」にあたるエンベロープ情報で、実際に配送処理そのものを制御します。一方、メール本文中のFrom:やTo:ヘッダーは受信者のメールソフトに表示される「便箋に書かれた宛名」であり、配送経路には直接影響しません。SPF認証はエンベロープFromを、DMARCのアラインメントチェックはヘッダーFromを見るなど、認証の仕組みによって参照する情報が異なるため、この違いを理解していないとSPF/DKIM/DMARCの設定トラブルの原因を切り分けられません。

使用ポート

• ポート25: サーバー間通信（MTA間のリレー・転送）。多くのISPやクラウド事業者はスパム対策のため、一般利用者からのポート25発信をデフォルトでブロックしています。
• ポート587: メール投稿（Submission、RFC 6409）- メールクライアントやアプリケーションからサーバーへの送信専用ポート。STARTTLSによる暗号化とSMTP認証が事実上必須です。
• ポート465: 暗黙的TLS（Implicit TLS）によるメール送信。かつては非標準的とされ避けられがちでしたが、RFC 8314（2018年）で新規実装には暗黙的TLSを推奨する方針に転換され、現在はGmailやOutlook.com、多くのSMTPリレーサービスが587と並行して465を提供しています。

この3つのポートは役割がはっきり分かれているため、「25で送信できない」という相談を受けた際は、まずクライアント側が投稿用の587（または465）を使っているか、契約中のISP・クラウド事業者がポート25をブロックしていないかを切り分けるのが定石です。

MTA・MSA・MDAの役割分担

SMTPの通信経路には3種類の機能単位が登場します。MTA（Mail Transfer Agent）はサーバー間でメールを中継・転送するソフトウェア（Postfix、Exim、Sendmailなど）、MSA（Mail Submission Agent）はメールクライアントからの投稿を受け付ける機能（実体はPostfixのsubmissionサービスであることが多い）、MDA（Mail Delivery Agent）は最終的にメールボックスへ配送する処理（DovecotのdeliverコマンドやDovecotのLDA/LMTP機能）を指します。Postfix単体で完結しているように見えても、実際にはMTA・MSAの役割をPostfixが、MDAの役割をDovecotが分担しているケースが一般的です。

基本的な動作とセッションの流れ

SMTPは、テキストベースのコマンドでメールを送信します：

HELO mail.example.com
MAIL FROM: <sender@example.com>
RCPT TO: <recipient@example.com>
DATA
Subject: Test Mail

This is a test message.
.
QUIT

現代のSMTPサーバーはHELOの代わりに拡張版のEHLOを使うESMTPで応答するのが標準です。EHLOに対するサーバーの応答には、そのサーバーが対応している拡張機能の一覧が返されます。

EHLO client.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-AUTH PLAIN LOGIN SCRAM-SHA-256
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 SMTPUTF8

それぞれSTARTTLS（通信の暗号化開始）、AUTH（利用可能な認証方式）、SIZE（送信可能な最大メールサイズ）、PIPELINING（複数コマンドの一括送信による高速化）、8BITMIME（8ビットデータの本文送信）、SMTPUTF8（国際化メールアドレス対応）といった拡張を表しており、クライアントとサーバーの双方が対応している拡張だけが実際に使われます。

応答コードの読み方

SMTPサーバーは各コマンドに対して3桁の応答コードを返します。1桁目が成功・失敗の種別、2桁目が意味のカテゴリを示すため、ログ調査の際はこの構造を押さえておくと原因の切り分けが速くなります。

4xx系は「一時的な失敗」なので送信側MTAはメールキューに保持して再送を試み、5xx系は「恒久的な失敗」なので即座にバウンスメールとして送信者に差し戻される、という違いを押さえておくと障害対応の判断が早くなります。

具体的な例・ユースケース

Webアプリケーションからの通知メール送信

会員登録完了メールやパスワード再設定メールを送信する際、アプリケーションサーバーは自社のPostfix（またはリレー専用のSMTPサーバー）に対してポート587でSMTP接続し、SMTP AUTHで認証したうえでメールを投函します。アプリケーション側は自前でDNSルックップやMXレコードの解決を行う必要がなく、リレーサーバーに投げるだけで済むため、実装がシンプルになります。

DNSのMXレコードによる配送先の決定

送信側MTAはRCPT TOで指定されたドメインのMXレコードをDNSに問い合わせ、優先度（プリファレンス値）が最も低いホストから順に接続を試みます。

; example.com のMXレコード例
example.com.    3600  IN  MX  10 mx1.example.com.
example.com.    3600  IN  MX  20 mx2.example.com.

; 対応するAレコード
mx1.example.com. 3600 IN A  203.0.113.10
mx2.example.com. 3600 IN A  203.0.113.20

プリファレンス値10のmx1が優先されますが、接続できない場合は自動的に値20のmx2へフェイルオーバーします。この仕組みにより、自社メールサーバーを二重化して可用性を高めることが可能です。あわせてMXレコードを指すサーバー側には、逆引き解決が正しく設定されたPTRレコードも必須で、これが欠けているだけで大手プロバイダに拒否されるケースが実務上非常に多く見られます。

メール認証を組み込んだ送信ドメインの構築

自社ドメインからのメールを大手プロバイダに確実に届けるには、SMTPの送信設定に加えてDNS側の認証レコードをセットで整備する必要があります。

; SPFレコード（Postfix送信元IPを許可する例）
example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip4:203.0.113.20 -all"

; DMARCレコード（ポリシー段階的強化の例）
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

実務ではまずDMARCポリシーをp=none（監視のみ）で導入し、rua宛に届く集計レポートでSPF/DKIMの整合状況を確認したうえで、p=quarantine、最終的にp=rejectへと段階的に強化していくのが定石です。いきなりp=rejectにすると、設定漏れがあった場合に正規のメールまで拒否されるリスクがあります。

SMTPリレー方式とAPI方式の使い分け

大量のトランザクションメール（注文確認、システムアラートなど）を送る場合、自社Postfixから外部のSMTPリレーサービスへrelayhost設定で中継し、IPレピュテーション管理やバウンス処理を外部サービスに任せる構成もよく採用されます。一方、送信量が多くリアルタイムの配信ステータス連携が必要な場合は、SMTPではなくHTTP APIベースの送信方式を使う選択肢もあり、両者は用途に応じて併用されることも珍しくありません。

メリット・デメリット（注意点）

混同されやすい用語・類似技術との違い

自社メールサーバー運用への応用

セキュリティ設定

自社メールサーバーでSMTPを運用する際は、以下のセキュリティ設定が必須です：

• TLS/STARTTLS: 通信の暗号化
• SASL認証: 送信者の認証
• リレー制限: 不正中継の防止
• レート制限: スパム送信の防止

Postfixでの設定例

# main.cf
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/ssl/certs/mail.crt
smtpd_tls_key_file = /etc/ssl/private/mail.key
smtpd_sasl_auth_enable = yes
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

上記のsmtpd_relay_restrictionsは上から順に評価され、社内ネットワーク（mynetworks）か、SASL認証済みのユーザーからのメールのみリレーを許可し、それ以外の未認証の宛先中継（reject_unauth_destination）は拒否するという、オープンリレー対策の基本形です。この設定を怠ると第三者にスパム送信の踏み台として悪用され、自社ドメインやIPアドレスが各種RBL（ブラックリスト）に登録されてしまうリスクがあります。

レート制限による送信量のコントロール

# main.cf
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 100
anvil_rate_time_unit = 60s
smtp_destination_concurrency_limit = 10
smtp_destination_rate_delay = 1s

Postfixのanvilサービスを使い、1クライアントあたりの接続数・メッセージ数を時間単位で制限することで、アカウント侵害時の大量送信被害を最小化できます。特にsmtp_destination_rate_delayは、Gmailなど宛先側のレート制限に配慮した送信間隔を設けるための設定で、大量配信時のブロック回避に有効です。

Dovecot（LMTP）との連携

# Postfix側 main.cf
virtual_transport = lmtp:unix:private/dovecot-lmtp

# Dovecot側 conf.d/20-lmtp.conf
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
}

PostfixはSMTPで外部からメールを受け取り、最終的なメールボックスへの配送はLMTP経由でDovecotに引き渡すという役割分担が広く使われています。LMTPはメールボックスごとの配送結果（容量オーバーなど）を個別に返せるため、Sieveフィルタとの連携やMaildir形式への保存処理を含め、SMTPだけで完結させるより堅牢な構成になります。

キュー監視とトラブルシューティング

# 滞留中のキューを確認
postqueue -p

# 特定メッセージの詳細を確認
postcat -q <queue_id>

# 滞留メールを強制的に再送
postqueue -f

メールが届かないという問い合わせを受けた際は、まずpostqueue -pでメールキューの滞留状況を確認し、mail.logで対象メッセージの応答コード（4xxか5xxか）を追うのが基本の切り分け手順です。4xxが続く場合は宛先側の一時的な受信制限（グレイリスティングやレート制限）が疑われ、5xxであれば宛先不在やDNSブラックリスト（RBL）掲載、SPF/DKIM不整合など恒久的な原因を疑います。

関連ブログ記事

• Docker Mailserver完全ガイド
• メール認証技術SPF/DKIM/DMARC

まとめ

SMTPは、40年以上にわたりインターネットメールの送信・転送を支えてきた標準プロトコルであり、その基本設計は今も変わっていません。一方で、設計当時は想定されていなかったスパムやなりすましへの対策は、STARTTLS・SMTP AUTH・SPF/DKIM/DMARCといった後付けの拡張仕様によって補われてきた歴史があります。自社メールサーバーを構築・運用する際は、ポート・認証方式の正しい理解（25/587/465の使い分け、SASL認証）、適切なセキュリティ設定（TLS暗号化、リレー制限、レート制限）、そして継続的なDNS認証レコードの整備（SPF/DKIM/DMARC、PTRレコード）の3点をセットで実装することが、迷惑メール判定を避けメールを確実に届けるための土台になります。

よくある質問（FAQ）

この用語についてもっと詳しく

SMTPに関するご質問や、メールサーバー構築のご相談など、お気軽にお問い合わせください。