MSA（Mail Submission Agent）とは何ですか？

メールクライアントから送信メールを受け付け、認証と送信ポリシーを適用するサーバー。ポート 587 で SMTP AUTH を処理する。

メール配信インフラ

MSA（Mail Submission Agent）

Q: MSA（Mail Submission Agent）の概要について教えてください

MSA（Mail Submission Agent） は、メールクライアント（MUA）からメールを受け付け、SMTP 認証と送信ポリシーの適用を行ったうえで MTA に引き渡すサーバーソフトウェアです。RFC 6409（2011年）が「Message Submission for Mail」として MSA の仕様を定義しています。

Q: MSA（Mail Submission Agent）の確認方法について教えてください

MSA がポート 587 で正しく動作しているかは、openssl で STARTTLS 接続を試みて確認します。

2026年5月19日更新

概要

MSA（Mail Submission Agent） は、メールクライアント（MUA）からメールを受け付け、SMTP 認証と送信ポリシーの適用を行ったうえで MTA に引き渡すサーバーソフトウェアです。RFC 6409（2011年）が「Message Submission for Mail」として MSA の仕様を定義しています。

MSA はポート 587（Submission）で MUA からの接続を待ち受けます。ポート 25 がサーバー間のメール中継（MTA 間通信）に使われるのに対し、ポート 587 はエンドユーザーからの送信専用です。この分離により、OP25B（Outbound Port 25 Blocking）の影響を受けずにメールを送信でき、認証なしの不正送信を防止できます。

実装上は、Postfix や Exim などの MTA ソフトウェアが MSA の機能を兼ねるのが一般的です。RFC 5598（2009年）のメールアーキテクチャでは MSA と MTA を別の役割として定義していますが、同一プロセスが両方の役割を担います。クラウドメールサービス（Gmail、Microsoft 365 等）では、MSA の機能がサービスの送信インフラに統合されています。

仕組み

MSA はポート 587 で SMTP AUTH によるユーザー認証を行い、ヘッダー補完や送信者検証を適用してから MTA にメールを引き渡します。

MSA と MTA の役割の違い

MSA と MTA はどちらも SMTP を使いますが、責任範囲が異なります。

項目	MSA	MTA
ポート	587（Submission）、465（Submissions）	25
認証	SMTP AUTH 必須	認証なし（サーバー間通信）
接続元	MUA（メールクライアント）	他の MTA
TLS	STARTTLS 必須または暗黙的 TLS	STARTTLS 任意（日和見 TLS）
役割	送信ポリシーの適用、ヘッダーの補完	ドメイン間のメール中継

MSA は送信者の身元を SMTP AUTH で確認してからメールを受け付けます。MTA はサーバー間でメールを転送するため、送信者の認証は行わず、代わりに SPF・DKIM・DMARC で送信元ドメインの正当性を検証します。

メール送信の流れ

MUA から MSA を経由してメールが送信される流れを示します。

MUA がポート 587 で MSA に TCP 接続する
MSA が 220 レスポンスで接続を受け付ける
MUA が EHLO コマンドで自身を名乗る
MSA が STARTTLS を含む拡張機能リストを返す
MUA が STARTTLS で TLS 暗号化を開始する
MUA が AUTH LOGIN または AUTH PLAIN でユーザー認証を行う
MSA が認証を検証し、235 Authentication successful を返す
MUA が MAIL FROM、RCPT TO、DATA でメールを送信する
MSA がヘッダーの補完（Date、Message-ID の追加等）を行う
MSA がメールを MTA の送信キューに渡す

SMTP AUTH の認証方式

MSA は SMTP AUTH（RFC 4954、2007年）でユーザーを認証します。代表的な認証メカニズムは以下の通りです。

メカニズム	特徴
PLAIN	ユーザー名とパスワードを Base64 エンコードして送信。TLS 必須
LOGIN	PLAIN と同様だが、ユーザー名とパスワードを別々に送信。TLS 必須
CRAM-MD5	チャレンジ・レスポンス方式。パスワードが平文で流れない
XOAUTH2	OAuth 2.0 トークンで認証。Gmail 等が採用

PLAIN と LOGIN は TLS で暗号化されていない接続では安全ではありません。MSA は TLS 接続が確立された後にのみ認証コマンドを受け付ける設定にします。

MSA によるヘッダー補完と送信ポリシー

MSA は、MUA が送信したメールに対して以下の処理を行います。

Date ヘッダーが欠落していれば追加します。Message-ID ヘッダーがなければ生成します。From ヘッダーのアドレスが認証済みユーザーと一致しない場合、設定によっては送信を拒否します。この「送信者の検証」が MSA 固有の役割です。MTA はヘッダー From の検証を行わず、受信側が DMARC で事後検証します。

送信レート制限も MSA で適用されることがあります。1 ユーザーあたりの送信数を制限し、アカウントが乗っ取られた場合のスパム送信被害を抑えます。

設定例

Postfix の master.cf で Submission ポート（587）を有効にし、TLS 必須・SMTP AUTH・送信者検証を設定します。

Postfix の Submission ポート設定

Postfix で MSA 機能を有効にするには、/etc/postfix/master.cf で Submission サービスを設定します。

submission inet n       -       n       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o smtpd_sender_restrictions=reject_sender_login_mismatch
  -o smtpd_sender_login_maps=hash:/etc/postfix/sender_login_maps

smtpd_tls_security_level=encrypt で TLS を必須にし、smtpd_sasl_auth_enable=yes で SMTP AUTH を有効にしています。reject_sender_login_mismatch は、認証済みユーザーが自分以外の From アドレスでメールを送信することを禁止します。

ポート 465（暗黙的 TLS）の設定

RFC 8314（2018年）で再標準化されたポート 465 を使う場合の設定です。

smtps     inet  n       -       n       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject

smtpd_tls_wrappermode=yes で暗黙的 TLS を有効にします。接続開始時から TLS で暗号化されるため、STARTTLS のネゴシエーションが不要で、ダウングレード攻撃のリスクがありません。

確認方法

MSA がポート 587 で正しく動作しているかは、openssl で STARTTLS 接続を試みて確認します。

openssl s_client -starttls smtp -connect mail.example.com:587 -quiet

220 レスポンスが返り、EHLO に対して 250-AUTH 行が含まれていれば、MSA は認証を受け付ける状態です。

ポート 465（暗黙的 TLS）の場合は -starttls オプション不要で直接 TLS 接続します。

openssl s_client -connect mail.example.com:465 -quiet

MX レコードの設定が正しいかは dig で確認します。MSA 自体は外部からの受信には使いませんが、送信したメールが認証を通過するかどうかは SPF・DKIM・DMARC の設定に依存します。

dig TXT example.com

外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/mail-auth?domain=example.com"

{
  "success": true,
  "data": {
    "spf": {
      "record": "v=spf1 include:_spf.google.com ~all",
      "exists": true
    },
    "dkim": {
      "record": null,
      "exists": false,
      "selector": "default"
    },
    "dmarc": {
      "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com",
      "exists": true
    },
    "bimi": {
      "record": null,
      "exists": false
    }
  },
  "error": null,
  "meta": { "responseTime": 120 }
}

MSA 経由で送信したメールが受信側で認証を通過するには、data.spf.exists と data.dkim.exists が true である必要があります。MSA で DKIM 署名を付与している場合、受信側がその署名を検証できるよう DNS に DKIM 公開鍵レコードが公開されていなければなりません。

よくある問題

MSA のトラブルは、ポート 587 のブロック、SMTP AUTH の認証失敗、アカウント乗っ取りによるスパム送信が代表的です。

ポート 587 への接続がタイムアウトする

ファイアウォールやセキュリティグループでポート 587 がブロックされていると、MUA から MSA に接続できません。クラウド環境（AWS、GCP 等）ではセキュリティグループのアウトバウンドルールでポート 587 が許可されているか確認します。ISP によってはポート 587 もブロックしている場合があり、その場合はポート 465 を使用します。

SMTP AUTH の認証に失敗する

認証に失敗する原因として、パスワードの誤り、TLS が確立される前に認証を試みている、SASL 認証バックエンド（Dovecot SASL 等）との接続が切れている、などがあります。Postfix のログに warning: SASL authentication failure と記録されている場合は、SASL の設定を確認します。Gmail の場合、2022 年 5 月に「安全性の低いアプリのアクセス」が廃止され、アプリパスワードまたは XOAUTH2 の使用が必須になりました。

認証済みユーザーによるスパム送信

アカウントが乗っ取られると、MSA を経由して大量のスパムが送信されます。MSA で 1 ユーザーあたりの送信レート制限を設定し、異常な送信パターンを検知する仕組みを導入します。Postfix では smtpd_client_message_rate_limit で 1 接続あたりのメッセージ数を制限できます。

From ヘッダーの詐称

MSA で reject_sender_login_mismatch を設定していないと、認証済みユーザーが任意の From アドレスでメールを送信できてしまいます。正規のユーザーが他人になりすましてメールを送ることを防ぐため、認証済みユーザーとエンベロープ From の対応を sender_login_maps で定義し、不一致を拒否する設定にします。

実際のドメインで確認してみる

登録不要、無料です。ドメイン名を入れるだけで外部からの見え方を確認できます。

無料で試す