Labee Dev Toolbox
技術ノートガイド用語解説
無料で試す
  1. ホーム
  2. / 用語解説
  3. / MTA（Mail Transfer Agent）
メール配信インフラ

MTA（Mail Transfer Agent）

2025年12月11日 更新

概要

MTA（Mail Transfer Agent） は、SMTP プロトコルを使ってメールを中継・配送するサーバーソフトウェアです。RFC 5321（2008年）が SMTP の仕様を定義し、RFC 5598（2009年）がメールアーキテクチャにおける MTA の役割を定義しています。送信者のメールクライアント（MUA）から受け取ったメールを、宛先ドメインの MX レコードに従って次の MTA へ転送し、最終的に受信側の MDA（Mail Delivery Agent）へ渡す――この一連の中継処理が MTA の仕事です。

代表的な MTA として、Postfix、Sendmail、Exim、Microsoft Exchange、qmail があります。クラウド環境では Amazon SES、SendGrid、Mailgun など、MTA 機能をサービスとして提供する SaaS も普及しています。MTA は SPF・DKIM・DMARC の認証チェックを実行する主体でもあり、メールセキュリティの最前線に位置します。

仕組み

MTA はメール配送フロー、MX レコードによるルーティング、SMTP セッション、認証チェックの各段階で中心的な役割を果たします。

メール配送の全体フロー

メールが送信者から受信者に届くまで、複数のエージェントが連携します。

  1. MUA（Mail User Agent）がメールを作成する。Gmail、Thunderbird などのメールクライアントがこれにあたる
  2. MSA（Mail Submission Agent）が MUA からメールを受け取り、ポート 587（Submission）で SMTP 認証を行う
  3. 送信側 MTA が宛先ドメインの MX レコードを DNS に問い合わせ、優先度の高い MX ホストへ SMTP 接続する
  4. 中継 MTA がある場合、次の MTA へ転送する
  5. 受信側 MTA がメールを受け取り、SPF・DKIM・DMARC の認証チェックを実行する
  6. MDA（Mail Delivery Agent）がメールをユーザーのメールボックスに格納する

MSA と MTA は同一のソフトウェア（Postfix 等）が兼ねることが多いですが、RFC 5598 では役割を明確に区別しています。MSA はユーザー認証と送信ポリシーの適用を担当し、MTA はドメイン間の転送を担当します。

MX レコードによるルーティング

MTA は宛先メールアドレスのドメイン部分（@ より後ろ）から DNS の MX レコードを引き、接続先を決定します。

dig MX example.com
example.com.  300  IN  MX  10  mail1.example.com.
example.com.  300  IN  MX  20  mail2.example.com.

MX レコードの数値は優先度を表し、値が小さいほど優先されます。上の例では mail1.example.com へ先に接続を試み、失敗した場合に mail2.example.com へフォールバックします。MX レコードが存在しない場合、RFC 5321 に従って A レコードへのフォールバックが行われます。

SMTP セッションの流れ

MTA 間の通信は SMTP コマンドのやり取りで進みます。

220 mail.example.com ESMTP Postfix
EHLO sender.example.net
250-mail.example.com
250-STARTTLS
250 SIZE 52428800
STARTTLS
220 2.0.0 Ready to start TLS
MAIL FROM:<user@sender.example.net>
250 2.1.0 Ok
RCPT TO:<recipient@example.com>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Test
From: user@sender.example.net

Hello
.
250 2.0.0 Ok: queued as ABC123
QUIT
221 2.0.0 Bye

MAIL FROM で指定されるアドレスがエンベロープ From です。SPF はこのドメインに対して検証を行います。DATA 以降に含まれる From: ヘッダーは別物で、DMARC のアライメント検証に関係します。

メール認証における MTA の役割

受信側 MTA は、メールを受け取る過程で以下の認証チェックを実行します。

認証方式MTA が行う処理
SPFエンベロープ From ドメインの TXT レコードを引き、送信元 IP が許可リストに含まれるか照合する
DKIMメールヘッダーの DKIM-Signature に記載されたセレクタとドメインから公開鍵を取得し、署名を検証する
DMARCSPF と DKIM の結果をヘッダー From ドメインとのアライメントで評価し、ポリシー（none / quarantine / reject）に従って処理する

認証結果は Authentication-Results ヘッダーに記録されます。このヘッダーを付与するのも MTA の役割です。

設定例

Postfix を中心に、MTA の基本設定と DKIM 署名の連携方法を示します。

Postfix の基本設定

Postfix は Linux 環境で最も広く使われている MTA です。主要な設定ファイルは /etc/postfix/main.cf です。

myhostname = mail.example.com
mydomain = example.com
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost
relayhost =
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_security_level = may
smtp_tls_security_level = may

myhostname は MTA が SMTP の EHLO コマンドで名乗るホスト名です。PTR レコード（逆引き DNS）と一致させる必要があります。不一致の場合、受信側 MTA がスパム判定する可能性があります。

DKIM 署名の付与（OpenDKIM + Postfix）

送信側 MTA で DKIM 署名を行う場合、OpenDKIM を Postfix と連携させます。

# /etc/postfix/main.cf に追記
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

この設定で、Postfix が送信メールを OpenDKIM の milter（mail filter）に渡し、DKIM 署名が付与されます。

確認方法

MTA が正しく動作しているかは、SMTP 接続テストで確認できます。

openssl s_client -starttls smtp -connect mail.example.com:25

TLS 接続が確立し、250 レスポンスが返れば MTA は稼働しています。ポート 587（Submission）の確認も同様に行います。

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

MX レコードの設定が正しいかは dig で確認します。

dig MX 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 }
}

data.spf.exists が true であれば SPF レコードが外部から確認できる状態です。data.dkim.exists で DKIM レコードの存在、data.dmarc.exists で DMARC レコードの存在もあわせて確認します。MTA の設定と DNS レコードの両方が揃ってはじめて、メール認証は機能します。

よくある問題

MTA の設定不備は、メールの配送失敗やスパム判定、セキュリティ侵害に直結します。

PTR レコード（逆引き DNS）が設定されていない

MTA の IP アドレスに PTR レコードが設定されていないと、受信側 MTA がメールを拒否またはスパム判定します。Gmail は送信元 IP の逆引きが設定されていることを要件としています。VPS やクラウドサーバーでメールを送信する場合、ホスティング事業者の管理画面から逆引き DNS を設定します。PTR レコードの値は myhostname と一致させます。

EHLO ホスト名と実際のホスト名が一致しない

MTA が EHLO コマンドで名乗るホスト名と、DNS の A レコードおよび PTR レコードが一致していない場合、受信側 MTA が接続を拒否することがあります。Postfix では myhostname の値が EHLO で使われます。この値を DNS に登録されているホスト名と一致させます。

リレー制限が不十分でオープンリレーになっている

MTA の設定ミスにより、認証なしで第三者のメールを中継できる状態（オープンリレー）になることがあります。オープンリレーはスパム送信に悪用され、IP アドレスがブロックリスト（DNSBL）に登録される原因になります。Postfix では mynetworks と smtpd_relay_restrictions を正しく設定して、許可されたネットワークと認証済みユーザーのみがリレーできるよう制限します。

smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

TLS が有効になっていない

MTA 間の通信が平文のままだと、経路上でメールの内容を傍受される可能性があります。Postfix では smtp_tls_security_level = may で日和見 TLS（相手が対応していれば TLS を使う）を有効にします。encrypt に設定すると TLS 必須になりますが、TLS に対応していない MTA へのメール配送が失敗するため、一般的には may を使います。Google は 2023 年 12 月以降、TLS で暗号化されていないメールの受信時に警告を表示しています。

メールアーキテクチャにおける位置づけ

MTA はメール配送チェーンの中核ですが、単独では動作しません。RFC 5598 が定義するメールアーキテクチャの主要エージェントは以下の通りです。

エージェント役割代表的なソフトウェア
MUAメールの作成と閲覧Gmail、Thunderbird、Outlook
MSA送信メールの受付と認証Postfix（ポート 587）
MTAドメイン間のメール転送Postfix、Sendmail、Exim
MDAメールボックスへの格納Dovecot、Procmail

クラウドメールサービス（Gmail、Microsoft 365 等）では、これらのエージェントがすべてサービス内部に統合されています。自前で MTA を運用する場合は、各エージェントの設定と連携を個別に管理する必要があります。

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

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

無料で試す

関連用語

メール認証

SPF（Sender Policy Framework）

メール送信元の IP アドレスがドメイン所有者に許可されているかを検証する仕組み。DMARC の前提条件の一つ。

メール認証

DKIM（DomainKeys Identified Mail）

メールに電子署名を付与し、送信後の改ざんを検知する仕組み。SPF と並んで DMARC の前提条件。

メール認証

DMARC（Domain-based Message Authentication, Reporting and Conformance）

SPF と DKIM の認証結果を統合し、なりすましメールの処理方針をドメイン所有者が宣言する仕組み。Google・Yahoo が大量送信者に義務化。

メール認証

エンベロープ From（Envelope From）

SMTP の MAIL FROM コマンドで渡される送信元アドレス。SPF の検証対象であり、受信者には通常表示されない。

コンテンツ 技術ノート ガイド 用語解説
ツール ツール一覧 API Reference
Labee 日本語トップ Labee LLC
© 2026 Labee LLC . All rights reserved.
ホーム ブログ ガイド 用語集