← RFC Reference

メールのライフサイクル

「送信」をクリックした瞬間から、メッセージが誰かの受信箱に表示される瞬間まで — あらゆるホップ、あらゆるプロトコル、その過程でのあらゆる決定。

アクター

Internet Mail Architecture (RFC 5598)は、メール配信に参加するロールを定義しています。これらのロールを理解することは重要です。同じソフトウェアが複数のロールを担当することが多く、メールフローがどのように流れるかを理解するには、それらの境界が重要だからです。

実際には、これらのロールは折りたたまれることが多い。Gmailのインフラストラクチャは同時にMSA、MTA、MX、MDA、MRAです。Postfixはメサとして機能することも、MTAとして機能することもできます。しかし、論理的なロールは異なったままであり、それらを理解することは配信の問題のデバッグに役立ちます。

ステージ1：作成（MUA）

ライフサイクルは、ユーザーがメールクライアントでメッセージを作成するか、アプリケーションがプログラム的にメッセージを生成する（APIまたはSMTPライブラリ経由）ときに開始します。

MUAはRFC 5322（Internet Message Format）に従ってメッセージを構築します：

このステージでの主な決定：

• From:ヘッダーは、著者を受信者に識別します（DMARCがアライメントをチェックするもの）。
• Message-ID:が生成されます。この特定のメッセージのグローバルに一意の識別子。
• MIMEエンコーディングが適用されます：添付ファイルはBase64エンコードされ、ボディが必要に応じてマルチパートとして構造化されます。
• MUAはReceived:ヘッダーを追加しません。それらはメッセージを処理する各サーバーによって追加されます。

ステージ2：送信（MUA → MSA）

MUAはMSA（RFC 6409）に接続してメッセージをハンドオフします。これは送信ステップです。

MSAがメッセージを受け取った際の処理：

• 送信者を認証します。MUAは有効な認証情報（AUTH経由のユーザー名/パスワード）を提供する必要があります。これにより、ランダムな人がメールサーバーをオープンリレーとして使用するのを防ぎます。
• エンベロープを検証します。MSAはMAIL FROMドメインが認証済みユーザーのドメインと一致することを確認できます。
• Received：ヘッダーを追加します。これは最初のホップを記録します：メッセージを送信したユーザー、タイミング、および送信元IP。
• ヘッダーを追加または修正する場合があります。MSAは不足している場合はDate:ヘッダーを追加し、MUAがそうしなかった場合はMessage-ID:を生成し、DKIM-Signatureヘッダーを追加できます。
• 配信のためにメッセージをキューイングします。メッセージはMTAのアウトバウンドキューに入ります。

API送信パス

Mailer To Goのようなトランザクションメールサービスを使用する場合、アプリケーションは通常、SMTPではなくHTTP APIを経由して送信します。APIサーバーはメッセージを受け入れ、SMTPエンベロープとヘッダーを構築し、DKIM署名を適用し、メッセージをMTAキューに注入します。API呼び出しはMUAとMUA-to-SMTP SMTPトランザクション両方を置き換えますが、下流のすべてはそのままです。

ステージ3：ルーティングと転送（MTA → MTA）

送信MTAはメッセージを受信者のドメインに配信する必要があります。これはリレーフェーズであり、RFC 5321（SMTP）によって管理されます。

DNS解決

MTAは受信者のドメインのMXレコードをルックアップします：

最初に優先度が最も低いMXを試します。そのサーバーに到達不可な場合は、次のサーバーにフォールバックします。DNSとメールルーティングを参照してください。A/AAAAレコードへのフォールバック、Null MX処理を含む完全なアルゴリズム。

転送

このステージでは：

• STARTTLSは接続を暗号化します。MTA-STSまたはDANEがない場合、TLS交渉が失敗すると、送信MTAはプレーンテキストにフォールバックします。これはセキュリティリスクです — アクティブな攻撃者はTLSを接続から削除できます。
• 認証（AUTH）は使用されません。ポート25でのサーバー間SMTP認証情報は必要ありません。受信サーバーはIPアドレス、SPF、DKIM、およびDMARCに依存して送信者を検証します。
• 別のReceived：ヘッダーが追加されます。各MTAはReceived：ヘッダーを前置き、メッセージのパスを文書化するチェーンを構築します。
• メッセージは複数のMTAを通過する場合があります。大規模な組織内のルーティング、フォワーディングルール、メーリングリストは追加のホップを追加できます。

キューイングとリトライ

受信MXが4xx一時エラーを返す場合（サーバービジー、グレイリスティング、レート制限）、送信MTAはメッセージをキューイングし、後で再試行します。リトライスケジュールは通常、指数バックオフを使用します：15分、30分、1時間、2時間など。リトライ期間（通常は4～5日）後にメッセージを配信できない場合、MTAはバウンスメッセージ（DSN）を生成し、エンベロープ送信者に送り返します。

ステージ4：受信（MX）

受信MX（受信者のドメインの受信メールを受け入れるMTA）は、ほとんどのフィルタリングが行われる場所です。これはゲートキーパーです。

接続時、メッセージコンテンツが到着する前に：

• IP評判チェック。受信MXは、接続IPを内部評判データベースおよび外部ブロックリストに対してチェックします。
• 逆DNS チェック。IPは同じIPに戻る有効なPTRレコードを持つ必要があります。
• レート制限。同じIPからの過度な接続がスロットルされる場合があります。

エンベロープフェーズ中：

• 受信者の検証。メールボックスは存在しますか？そうでない場合は：550 5.1.1 User unknown。
• SPFチェック。MAIL FROMドメインは、そのSPFレコードに対してチェックされ、送信IPが承認されていることを確認します。

DATA後（完全なメッセージが受信されます）：

• DKIM検証。DKIM署名はDNSの公開鍵に対して検証されます。
• DMARC評価。SPFおよびDKIM結果は、From：ヘッダーとのDMARCアライメントについてチェックされます。
• コンテンツフィルタリング。メッセージはスパムフィルターを通過します：コンテンツ分析、URLチェック、ベイズ分類、機械学習モデル。
• Authentication-Resultsヘッダーが追加されます。MXはすべての認証チェックの結果をAuthentication-Resultsヘッダーに記録します。

ステージ5：配信（MDA）

メール配信エージェントは、フィルタリングを通過したメッセージを受け取り、受信者のメールボックスにデポジットします。多くのシステムでは、MDAは別のプロセスではなくMXサーバーに統合されています。

MDAの責任：

• メールボック選択。RCPT TOアドレス、エイリアス、ルーティングルールに基づいて、どのメールボックス（ユーザーアカウント）がメッセージを受信するかを決定します。
• フォルダーの配置。スパムフィルターの評決とユーザー定義のルールに基づいて、メッセージは受信箱、スパム/迷惑フォルダー、特定のラベル（Gmail）、またはカスタムフォルダー（Sieveルール）に移動します。
• Sieveフィルタリング。多くのメールシステムはSieve（RFC 5228）をサポートしています。ユーザー定義メールフィルタリングルールの言語。ルールはメッセージをフォルダーにファイリングしたり、転送したり、拒否したり、休暇の自動返信をトリガーしたりできます。
• クォータの適用。メールボックスがクォータを超える場合、MDAは452 4.2.2 Mailbox fullまたは552 5.2.2 Mailbox fullでメッセージを拒否する場合があります。
• 通知。MDAはユーザーのデバイスへのプッシュ通知をトリガーする場合があります（新着メールアラート）。

この時点で、メッセージは保存状態で受信者のメール保存にあります。SMTPトランザクションは完了しました。送信MTAの責任は、受信MXから250 OKを受信したときに終了しました。

ステージ6：取得（MRA → MUA）

受信者のメールクライアントは、3つのプロトコルのいずれかを使用してメール保存からメッセージを取得します：

IMAP（RFC 9051）

優勢なメールアクセスプロトコル。IMAPはサーバー上のメッセージを保持し、状態（既読/未読、フラグ、フォルダー）を複数のクライアント間で同期します。クライアントは最初にメッセージヘッダーをダウンロードし、必要に応じて全文を取得します。1つのクライアント（既読マーク、フォルダーへの移動）で加えられた変更は、すべてのクライアントに反映されます。

POP3（RFC 1939）

古い、よりシンプルなプロトコル。POP3はメッセージをクライアントにダウンロードし、（デフォルトでは）サーバーから削除します。クライアント間で状態を同期しません。大部分がIMAPに置き換わっていますが、いくつかのシナリオでは引き続き使用されています。

ウェブおよびAPIアクセス

Webメールインターフェース（Gmail、Outlook.com）およびモバイルアプリは、IMAP/POP3をバイパスして、専用API或いはJMAP（RFC 8620）経由でメール保存にアクセスします。メッセージはプロバイダーのサーバーを離れません — クライアントはそれをWebリクエスト経由で表示します。

問題が発生する場所：各ステージでの障害モード

送信障害

認証に失敗します（パスワードが違う、トークンが期限切れ）、MSAがメッセージを拒否します（サイズ制限超過、ポリシー違反）、または接続がタイムアウトします。ユーザーはすぐにエラーを見ます。

ルーティング障害

DNS解決に失敗します（MXレコードなし、DNSタイムアウト）、すべてのMXホストに到達不可、またはすべてのMXが永続的エラーを返します。リトライが終了した後、送信者はバウンス（DSN）を受け取ります。

受信時拒否

受信MXはSMTP時にメッセージを拒否します：ブロックリストIPアドレス（550）、認証失敗（550 5.7.1）、不明な受信者（550 5.1.1）、またはコンテンツ拒否（554）。送信MTAはエンベロープ送信者への跳ね返り通知を生成します。

受理後のフィルタリング

MXがメッセージを受け入れました（250 OK）が、MDAはコンテンツ分析と評判スコアに基づいてそれをスパムフォルダーにルーティングします。送信者はバウンスを受け取りません — メッセージは技術的には「配信」されていました — しかし、受信者はそれを見たことがありません。これは、最も一般的で、診断が最も難しい配信性の問題です。

メールボックスが満杯

受信者のメールボックスがクォータを超えています。実装に応じて、これは、RCPT TO時の拒否か、DATA受理後に生成されたバウンスのいずれかです。

ヘッダーはストーリーを語ります

ライフサイクルの各ステージはメッセージにヘッダーを追加します。下から上へのヘッダーを読むと、旅を再構築できます：

Received:ヘッダーはパンくずリストです。それぞれが送信ホスト、受信ホスト、使用されたプロトコル（TLSの場合はESMTP、ESMTPS、認証+TLSの場合はESMTPSA）、キューID、およびタイムスタンプを記録します。完全なガイドについては、メールヘッダーの解剖を参照してください。

トランザクションメールパス

アプリケーションがMailer To Goのようなサービス経由でメールを送信する場合、ライフサイクルは若干異なります：

1. アプリケーションはAPIを呼び出します。アプリはメッセージコンテンツ、受信者、メタデータを含むPOSTリクエストを送信します。
2. サービスはメッセージを構築します。MIME構造を構築し、必要なヘッダー（Date、Message-ID、該当する場合はList-Unsubscribe）を追加し、ドメインキーでDKIM署名を適用します。
3. サービスのMTAがメッセージを送信します。メッセージはサービスのIPからポート25の受信者のMXに送信され、STARTTLSします。
4. 残りは同じです。MX受信、認証チェック、コンテンツフィルタリング、MDA配信、クライアント取得はすべて上記のとおり進行します。

主な違い：アプリケーションは直接SMTPを話しません。APIはプロセス送信全体を抽象化します。しかし、メッセージは依然として同じインフラストラクチャをトラバースし、同じ認証チェックを受け、同じスパムフィルターで評価されます。

重要なポイント

• メールには6つの異なるステージがあります：作成、送信、転送、受信、配信、取得。各ステージはさまざまなプロトコルとさまざまなアクターを含みます。
• エンベロープとメッセージは分離しています。MAIL FROM / RCPT TO（エンベロープ）は、From：/ To：ヘッダー（メッセージ）と異なる場合があります。この区別は認証、バウンス、Bccにとって重要です。
• ほとんどのフィルタリングは受信時に行われます。受信MXは、認証、評判、コンテンツが評価される場所です。これは、受信箱とスパムを決定するステージです。
• 250 OKは受け入れられることを意味し、受信箱への配信ではありません。受信MXは依然としてメッセージをスパムにルーティングする場合があり、またはMDAが後で拒否する場合があります（メールボックスが満杯、Sieveルール）。
• Received：ヘッダーはジャーニーを文書化します。下から上へ読んで、メッセージのパスをトレースします。これらは、配信の問題をデバッグするための単一の最も役立つツールです。
• すべてのホップはレイテンシーと危険を追加します。より多くのホップは、障害、遅延、またはコンテンツの変更の可能性がより多いことを意味します（DKIM署名を壊す可能性があります）。

さらに詳しく

Related RFCs