SMTPとは

SMTPを読むときの前提

SMTP（Simple Mail Transfer Protocol）は、メールを送信、配送、中継するためのプロトコルです。利用者のメールソフトから送信基盤へ出すsubmissionと、メールサーバー間で配送するrelayを分けて見る必要があります。

実務では、25番、587番、465番、SMTP AUTH、STARTTLS、送信元IP、送信ドメイン、キュー、リレー許可、不正中継、SPF/DKIM/DMARCの評価を合わせて確認します。From表示だけでは、実際の配送経路や認証対象は判断できません。

証跡には、送信元、宛先、送信時刻、SMTP応答コード、Message-ID、Receivedヘッダー、キューログ、バウンス、Authentication-Resultsを残します。

submissionとrelayを分ける

587番のsubmissionでは、利用者やアプリが認証してメールを出します。25番のrelayでは、メールサーバー同士が宛先ドメインのMXへ配送します。同じSMTPでも、認証、許可リスト、TLS、ログの見方が変わります。

アプリ通知や監視通知では、認証付きsubmissionなのか、社内ネットワークからのIP許可relayなのかを確認します。IP許可だけに依存すると、送信元変更やNAT変更で突然送れなくなることがあります。

• 利用ポート、認証方式、許可条件を確認する。
• 送信アプリ、メール基盤、ネットワーク経路を分ける。
• 不正中継にならない許可範囲を確認する。

応答コードとキューを見る

SMTPの切り分けでは、2xx、4xx、5xxの応答コードを分けます。4xxは一時失敗として再試行されることがあり、5xxは恒久失敗としてバウンスになることが多いです。

送れない、遅い、届かないという問い合わせでは、送信側キュー、受信側応答、DNSのMX、SPF/DKIM/DMARC判定を同じ時刻で見ます。利用者の受信箱にないだけでは、送信失敗とは限りません。

• SMTP応答コードと応答文を保存する。
• キュー滞留、再試行、バウンスを確認する。
• Message-IDで送信側と受信側ログを突合する。

STARTTLSとメール認証を分ける

SMTPでSTARTTLSを使うと配送経路を暗号化できますが、送信ドメインの正当性を示すものではありません。なりすまし対策はSPF、DKIM、DMARCで確認します。

暗号化失敗、証明書不一致、TLS必須設定、相手先のSTARTTLS非対応は配送可否に影響します。配送暗号化、送信者認証、迷惑メール判定を分けて記録します。

• STARTTLSの有無とTLSバージョンを確認する。
• Authentication-ResultsでSPF/DKIM/DMARCを確認する。
• TLS障害とメール認証失敗を混同しない。

変更証跡と引き継ぎ

SMTP変更では、送信元システム、接続先、ポート、認証方式、許可IP、TLS要件、レート制限、テストメールのヘッダー、戻し条件を残します。クラウドメール移行では旧SMTP relayの停止時期も重要です。

引き継ぎでは、メール基盤管理者、DNS管理者、送信アプリ所有者、関連語としてMX、SPF、DKIM、DMARC、STARTTLSを残すと確認しやすくなります。

• 送信経路と許可条件を台帳化する。
• テストメールのヘッダーとログを保存する。
• 旧relayの停止日と戻し条件を記録する。

関連語

同じ主要カテゴリの用語

メールの学習順

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

InfraEngKit内の関連機能