MTAとは

MTAを読むときの前提

MTA（Mail Transfer Agent）は、メールを受け取り、キューに入れ、次のMTAや最終配送先へ渡す役割です。Postfix、Exchange Transport、クラウドメールゲートウェイなど、製品名ではなく配送を担う機能として見ると整理しやすくなります。

実務では、SMTP、MX、キュー、リレー、STARTTLS、HELO/EHLO、送信元IP、SPF/DKIM/DMARC、迷惑メール判定、バウンスを合わせて確認します。MTA単体ではなく、DNSとログを同じ時刻で突合します。

証跡には、対象MTA、送信元/宛先、Message-ID、キューID、SMTP応答、配送ログ、Receivedヘッダー、TLS結果、認証結果、確認時刻を残します。

配送経路とキューを分ける

MTAの切り分けでは、メールが受け付けられたのか、キューに滞留しているのか、次の配送先へ拒否されたのかを分けます。キューにあるメールは、まだ最終失敗ではなく再試行中の場合があります。

配送遅延では、宛先MXの応答、DNS解決、送信元制限、レート制限、受信側一時失敗を確認します。ユーザーの受信箱だけを見ても、MTA上で何が起きたかは分かりません。

• Message-IDとキューIDを保存する。
• 受け付け、滞留、再試行、バウンスを分ける。
• SMTP応答コードと次の配送先を確認する。

送信評価とDNSを突合する

MTAが外部へ送る場合、送信元IP、HELO名、PTRレコード、SPF、DKIM、DMARCが受信側評価に影響します。配送できても迷惑メール判定される場合は、SMTPログだけでなく受信側ヘッダーを見ます。

クラウド移行やメールゲートウェイ変更では、送信元IP、Return-Path、DKIM selector、Received経路が変わります。旧MTAが残ると、意図しない経路から送信され続けることがあります。

• 送信元IPとPTR/HELOを確認する。
• Authentication-ResultsでSPF/DKIM/DMARCを見る。
• 旧MTAや予備経路の残存を棚卸しする。

リレーと受信を分ける

MTAは受信用、送信用、リレー用で責任範囲が変わります。受信MTAのMX設定、送信MTAの許可送信元、リレーMTAの認証やIP許可を混同すると、障害原因を追いにくくなります。

社内アプリや複合機からの通知では、MUAではなくMTAやSMTPリレーへ渡している場合があります。接続元、認証、TLS、配送先、ログの所在を分けます。

• 受信、送信、リレーの役割を図にする。
• 許可IPと認証方式を確認する。
• ログを見る担当と保管場所を明記する。

変更証跡と引き継ぎ

MTA変更では、旧MTA、新MTA、MX、送信元IP、HELO名、PTR、TLS証明書、リレー許可、キュー移行、戻し条件を残します。移行直後は旧MTAのキューや再送も確認します。

引き継ぎでは、メール基盤管理者、DNS管理者、ネットワーク管理者、アプリ所有者、関連語としてSMTP、MX、HELO、PTRレコード、SPF、DKIM、DMARCを残すと追いやすくなります。

• 新旧MTAと配送経路を記録する。
• キュー確認と再送停止条件を残す。
• 送信評価に関わるDNSを同時に確認する。

関連語

同じ主要カテゴリの用語

メールの学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能