MUA（Mail User Agent）

概要

MUA（Mail User Agent） は、メールの作成・送信・受信・閲覧を行うクライアントソフトウェアです。RFC 5598（2009年）がメールアーキテクチャにおける MUA の役割を定義しています。一般的に「メールクライアント」や「メールソフト」と呼ばれるものが MUA に該当します。

代表的な MUA として、デスクトップ版では Mozilla Thunderbird、Microsoft Outlook、Apple Mail、Webメール版では Gmail、Yahoo! メール、Outlook.com、モバイル版では各 OS 標準のメールアプリがあります。MUA はユーザーとメールシステムの接点であり、メール送信時には MSA（Mail Submission Agent）に接続してメールを送り出し、メール受信時には IMAP や POP3 でメールサーバーからメールを取得します。

MUA はメールアーキテクチャの 4 つのエージェント（MUA → MSA → MTA → MDA）の起点です。MUA の設定が正しくなければ、後続のメール認証（SPF・DKIM・DMARC）にも影響が及びます。

仕組み

MUA はメール送信時に MSA へ SMTP で接続し、受信時には IMAP/POP3 でメールサーバーからメールを取得します。

メール送信時の動作

MUA がメールを送信する際の流れは以下の通りです。

1. ユーザーがメールを作成する（宛先、件名、本文、添付ファイル）
2. MUA がメッセージヘッダー（From、To、Subject、Date、Message-ID 等）を生成する
3. MUA がポート 587（STARTTLS）またはポート 465（暗黙的 TLS）で MSA に接続する
4. TLS 暗号化を確立した後、SMTP AUTH で認証を行う
5. MAIL FROM（エンベロープ From）と RCPT TO（エンベロープ To）を送信する
6. DATA コマンドでヘッダーと本文を送信する
7. MSA が受け付け、MTA の送信キューに渡す

MUA が設定する From: ヘッダーと、SMTP の MAIL FROM（エンベロープ From）は別のアドレスを指定できます。ヘッダー From は受信者のメールクライアントに表示されるアドレスで、エンベロープ From はバウンスメールの返送先です。DMARC はこの 2 つのアドレスのドメインが一致しているか（アライメント）を検証します。

メール受信時の動作

MUA がメールを受信する際は、IMAP または POP3 プロトコルを使ってメールサーバーの MDA にアクセスします。

プロトコル	RFC	ポート	特徴
IMAP4rev2	RFC 9051（2021年）	993（TLS）	サーバー上でメールを管理。複数デバイスで同期可能
POP3	RFC 1939（1996年）	995（TLS）	メールをダウンロードしてローカルに保存。同期機能なし

IMAP はメールをサーバー上に保持し、フォルダ構造やフラグ（既読・未読）を複数のデバイス間で同期します。POP3 はメールをクライアントにダウンロードし、サーバーから削除するのが基本動作です。現在のメール運用では IMAP が主流です。

MUA が生成するメールヘッダー

MUA が作成するメールには、RFC 5322（2008年）に準拠したヘッダーが含まれます。

From: user@example.com
To: recipient@example.net
Subject: Meeting tomorrow
Date: Fri, 11 Apr 2026 09:00:00 +0900
Message-ID: <abc123@mail.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
User-Agent: Mozilla Thunderbird 128.0

From ヘッダーは受信者に表示されるアドレスです。Message-ID はメールを一意に識別する ID で、MUA または MSA が生成します。User-Agent ヘッダーは任意で、送信に使った MUA の名前とバージョンを示します。

Webメールと MUA の関係

Webメール（Gmail のウェブ版、Outlook on the web 等）も MUA の一種です。ブラウザー上で動作しますが、メールの作成・閲覧・送信という MUA の機能を提供している点は同じです。

Webメールの場合、MUA（ブラウザー）と MSA/MTA（メールサーバー）の通信は HTTPS で行われ、SMTP は使いません。SMTP による通信はサーバー内部（MSA → MTA）で完結します。ユーザーが直接 SMTP を意識する場面はありませんが、SPF・DKIM の設定はサーバー側で行う必要があります。

設定例

デスクトップクライアントの SMTP 設定と、アプリケーションから SMTP ライブラリーを使った送信方法を示します。

Thunderbird の SMTP 設定

Thunderbird でメール送信を設定する際、MSA への接続情報を入力します。

設定項目	値
SMTP サーバー	smtp.example.com
ポート	587
接続の保護	STARTTLS
認証方式	通常のパスワード認証
ユーザー名	user@example.com

ポート 465 を使う場合は「接続の保護」を「SSL/TLS」に変更します。

アプリケーションからの SMTP 送信

アプリケーションが MUA として動作する場合、SMTP ライブラリーを使って MSA に接続します。Python の smtplib を使った例です。

import smtplib
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "app@example.com"
msg["To"] = "recipient@example.net"
msg["Subject"] = "Notification"
msg.set_content("Your order has been shipped.")

with smtplib.SMTP("smtp.example.com", 587) as server:
    server.starttls()
    server.login("app@example.com", "app-password")
    server.send_message(msg)

この場合、アプリケーションが MUA、smtp.example.com が MSA です。server.starttls() で TLS を確立し、server.login() で SMTP AUTH を行っています。

確認方法

MUA から MSA への接続が正しく行えるかは、openssl コマンドで手動テストできます。

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

TLS 接続が確立し、250-AUTH が含まれるレスポンスが返れば、MSA は認証を受け付ける状態です。MUA の設定でサーバー名、ポート番号、暗号化方式が正しいか照合します。

MUA から送信したメールが受信側で認証を通過するかは、受信メールのヘッダーで確認します。Gmail の場合、「メッセージのソースを表示」から Authentication-Results ヘッダーを確認できます。

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of user@example.com designates 198.51.100.25 as permitted sender)
       dkim=pass header.d=example.com
       dmarc=pass (p=REJECT)

SPF、DKIM、DMARC のいずれかが fail の場合、MUA の送信設定ではなく、DNS レコードや MSA/MTA の設定を見直す必要があります。

外部の視点からも確認したい場合は、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 }
}

data.spf.exists と data.dmarc.exists が true であれば、送信ドメインの認証レコードが外部から参照できる状態です。MUA の設定が正しくても、DNS レコードが不足していると受信側で認証に失敗します。

よくある問題

MUA の設定ミスや認証方式の変更がメール送信の失敗や迷惑メール判定につながります。

SMTP サーバーのアドレスやポートの設定ミス

MUA の送信設定で SMTP サーバーのアドレスやポート番号を間違えると、メールの送信に失敗します。ポート 587 と 465 では暗号化の方式が異なるため、ポート番号と暗号化設定の組み合わせを正しくする必要があります。587 には STARTTLS、465 には SSL/TLS（暗黙的 TLS）を対応させます。

アプリパスワードの未設定

Gmail は 2022 年 5 月に「安全性の低いアプリのアクセス」を廃止しました。2 段階認証を有効にしたアカウントでは、MUA に通常のパスワードを設定しても SMTP AUTH に失敗します。Google アカウントの設定からアプリパスワードを生成し、MUA にはそのパスワードを設定します。Microsoft 365 も同様に、先進認証（Modern Auth / OAuth 2.0）への移行を進めています。

送信メールが迷惑メールに振り分けられる

MUA の設定は正しいのに、送信先で迷惑メール扱いされるケースがあります。原因は MUA ではなく、DNS レコード（SPF・DKIM・DMARC）の設定不足にあることがほとんどです。MUA から送信したメールの認証結果は、受信メールの Authentication-Results ヘッダーで確認します。送信ドメインの DNS レコードを修正することで解決します。

添付ファイルのサイズ制限

多くの MSA はメールサイズに上限を設けています。Postfix のデフォルトは 10MB（message_size_limit = 10240000）、Gmail は 25MB です。上限を超えるファイルを添付すると、MSA が 552 Message size exceeds fixed limit で拒否します。大きなファイルはクラウドストレージのリンクを使って共有するのが実運用上の対応です。