メールのライフサイクル

メールのライフサイクルは、Cloudflare Email Service を通るメールの一連の流れです。このプロセスを理解すると、メール実装の最適化と配信問題のトラブルシューティングに役立ちます。

Email Sending と Email Routing は、別々の処理パイプラインに従います。送信フローはサービス経由で送るメール、受信フローは Email Routing を設定したドメインで受け取るメールです。

送信フロー（Email Sending）

Cloudflare Email Service 経由で送るすべてのメールは、次の処理パイプラインに従います。

flowchart LR
    A[Request Received] --> B["Rate Limit, Authentication & Suppression Check"] --> E[Delivery Attempt]
    E --> G{Success?}
    G -->|Yes, successfully delivered| F[Final Status & Metrics]
    G -->|No - Soft Bounce| H[Retry with Exponential Backoff]
    G -->|No - Hard Bounce| F
    H -->|Retries remaining| E
    H -->|Max retries exceeded| F

ステージの詳細

リクエスト受信: システムはメール形式、送信者の認可、メッセージ構造を検証します。無効なリクエストはすぐに拒否され、次のステージへ進みません。
レート制限チェック: システムはアカウント、ドメイン、受信者ごとの送信上限を確認し、悪用を防ぎます。上限を超えたリクエストは一時的に拒否され、あとでリトライする必要があります。
認証とレピュテーション: システムはメール認証チェックを行い、送信者のレピュテーションを評価します。
- SPF（Sender Policy Framework）: DNS TXT レコードを確認し、送信 IP アドレスがそのドメインからのメール送信を許可されているかを検証します。ドメインのなりすましを防ぎ、到達性を改善します。
- DKIM（DomainKeys Identified Mail）: メールの暗号署名を検証し、メッセージの完全性を確保して送信者ドメインを認証します。受信サーバーとの信頼を築きます。
- DMARC（Domain-based Message Authentication）: SPF または DKIM チェックに失敗したメールの扱いについて、ドメイン所有者のポリシーを適用します。フィッシングとブランドなりすましを防ぎ、フィードバックレポートを提供します。
これらの認証メカニズムは連携し、送信者の正当性を確立してメール詐欺から守ります。レピュテーションスコアが低い送信者は、スロットリングや遅延処理を受けることがあります。
抑制リストチェック: システムは各受信者を、アカウントの Email Sending 抑制リストと照合します。抑制された受信者は配信ステージに到達せず、クォータにも数えられません。

送信ドメインごとの Drop suppressed recipients 設定はデフォルトでオフです。オフの場合、いずれかの受信者が抑制されていると、REST API は 400 を返し、Workers バインディングは E_RECIPIENT_SUPPRESSED を投げ、SMTP はメッセージを拒否します。

オンの場合、Email Service は抑制された受信者を除き、残りの受信者を処理します。Email Service は配信停止リンクを処理しないため、配信停止した受信者は手動で追加します。
配信試行: システムは受信者のメールサーバーに接続し、SMTP 経由でメッセージ配信を試みます。配信が失敗すると、失敗の種類に応じて異なるリトライロジックを適用します。
- ソフトバウンス（4xx 応答）: システムは指数バックオフで配信をリトライします
- ハードバウンス（5xx 応答）: システムはメールを永続的失敗としてマークし、リトライしません
サーバー応答の処理: システムは受信サーバーからの SMTP 応答コードを処理し、最終的なメールステータスを決めます。
- 2xx コード: メールは正常に配信されました
- 4xx コード: 一時的な失敗が発生し、メールはリトライされます
- 5xx コード: 永続的な失敗が発生し、メールは配信できません
最終ステータスとメトリクス: サーバー応答に基づき、システムはメールに次のいずれかの最終ステータスを割り当てます。
- Delivered: メールは受信サーバーに正常に受理されました
- Delivery failed: メールは永続的に配信失敗した（ハードバウンス）か、最大リトライ回数を超えた（ソフトバウンス）ものです。このステータスは GraphQL Analytics API の照会では deliveryFailed と表示されます。

受信フロー（Email Routing）

Email Routing を設定したドメインで受け取るすべてのメールは、次の処理パイプラインに従います。

flowchart LR
    A[SMTP Receipt] --> B[Authentication Check]
    B --> C{Authenticated?}
    C -->|Yes| D[Rule Match]
    C -->|No| R[Reject]
    D --> E{Action?}
    E -->|Send to email| F[ARC Sign & SRS Rewrite]
    E -->|Send to Worker| W[Worker]
    E -->|Drop| X[Drop]
    W --> Y{Worker action?}
    Y -->|forward| F
    Y -->|reply| F
    Y -->|setReject| R
    F --> G[Outbound Delivery]
    G --> H[Final Status & Metrics]

ステージの詳細

SMTP 受信: 送信サーバーが Cloudflare MX サーバーに接続し、SMTP でメッセージを送信します。受信メッセージサイズ上限を超えるメッセージはこの段階で拒否されます。
認証チェック: システムは着信メッセージに対して SPF、DKIM、DMARC、ARC チェックを行います。送信者の DMARC ポリシーに従って認証に失敗したメールは拒否されます。Realtime Block List 上の IP アドレスからのメールもこの段階で拒否されます。詳細は Postmaster information を参照してください。
ルール照合: システムは受信者アドレスを、設定済みのルーティングルールと照合します。サブアドレッシングが有効な場合、サブアドレス付き受信者はベースのルーティングルールにフォールバックします。どのルールにも一致せず catch-all ルールが有効な場合、catch-all ルールが適用されます。
アクション: システムは一致したルールのアクションを適用します。
- メールへ送る: メッセージは検証済みの宛先アドレスへ転送されます（ステージ 5）。
- Worker へ送る: メッセージは Worker に渡されます。Worker は forward()、reply()、または setReject() を呼べます。
- Drop: メッセージは静かに破棄されます。これ以上の処理は行われません。
ARC 署名と SRS 書き換え: 転送メッセージでは、システムは元の認証結果を保持する ARC シールを追加し、Sender Rewriting Scheme でエンベロープ送信者を書き換えます。これにより宛先サーバーで SPF が通ります。
送信配信: システムは宛先メールサーバーに接続し、メッセージを配信します。ソフトバウンスは指数バックオフでリトライされます。ハードバウンスはアップストリーム SMTP エラーとして、セッション内で元の送信者に返されます。Postmaster: SMTP errors を参照してください。
最終ステータスとメトリクス: 最終結果は記録され、Activity log と GraphQL Analytics API から確認できます。