プロダクトチームはCloudflareのメールルーティングをどう安全に導入すべきですか？

受信処理の役割と責任範囲を定義する

まず、受信処理で何をするのかを正確に書き出します。どのドメインとローカルパートでメールを受け付けるのか、各転送先の担当者は誰か、メッセージを転送するのか、コードで処理するのか、破棄するのか、運用上の証跡をどのくらいの期間保持してよいのか、といった点です。Cloudflare Email Routingは受信メールのルーティングレイヤーです。それ自体がサポートチケットを作成したり、送信者のIDを確立したり、転送されたメールが人に届いたことを証明したり、転送先でのメールボックスへの到達を保証したりするものではありません。こうした後段のアプリケーションの状態は分けて扱ってください。DNS、ルーティングルール、Workerのコード、転送先の検証、セキュリティインシデント、ロールバックについて、運用上の担当者を決めておきます。最初の導入時は、キャッチオールではなくsupport@やinvoices@のような専用のエイリアスを使いましょう。ルートを狭く絞ることで、意図しない収集を減らし、テスト結果を解釈しやすくし、転送先やWorkerの分岐を誤った場合の影響も限定できます。

DNSを何も考えずに済ませるインストール手順として扱わずにドメインをオンボーディングする

Cloudflareの現行のEmail Serviceドキュメントでは、Email Routingを使うにはドメインでCloudflare DNSを使う必要があるとされています。オンボーディングの流れでは、受信ルーティング用のMXレコードに加え、製品側で説明されているSPFやDKIM関連のTXTレコードが追加されることがあります。適用する前に、提案されるレコードを正確に確認してください。その前に、既存のMX、SPF、DKIM、DMARC、メールボックス、転送サービス、検証用トークン、サブドメインの委任を洗い出しておきます。MXレコードを置き換えると、新しい受信SMTPセッションの行き先が変わります。メンテナンス時間を調整し、以前の値をロールバック用の記録として残しておきましょう。1つのオーナー名にSPFのTXTレコードを複数作成するのは避けてください。変更後は権威サーバーと公開リゾルバーに照会し、転送先とは無関係なアカウントから配信をテストします。DNSの反映にかかる時間の目安は、すべての送信者が同じ応答を得ていることの証明にはなりません。ダッシュボードが緑色でも、エンドツーエンドで転送できていることの証明にはなりません。

有効なルートを作成する前に転送先を検証する

Cloudflareのドキュメントでは、転送先アドレスはアカウントレベルのリソースであり、ルーティングルールで使う前に検証が必要だとされています。この検証は不正利用を防ぐ重要な境界です。その時点でメールボックスを管理していることは示せますが、継続的な業務上の許可や、正しいチームに所属していることまでは確認できません。依頼した担当者、目的、検証日、見直し日を自社のシステムに記録しておきましょう。従業員個人のアドレスよりも、チームで管理する転送先を優先してください。退職したユーザーの転送先は速やかに削除します。Cloudflareのドキュメントによると、転送先を削除するとそれを使っているルートが無効になるため、削除前にどのルールがそのアドレスに依存しているかを確認してください。検証メールはセキュリティ上機密性の高いものとして扱い、自動でクリックしたり、信頼できない自動処理に転送したりしないでください。本番環境の変更では、ダッシュボード上は1人の運用者でもルールを保存できるとしても、通常のインフラ変更プロセスで別の担当者によるレビューを必須にしましょう。

明示的なルールを作成し、優先順位を理解する

ルーティングルールは、メールのパターンと、検証済みの転送先またはWorkerを組み合わせたものです。Cloudflareのドキュメントには、メールへの送信、Workerへの送信、破棄（drop）という3つのアクションが記載されています。最も具体的なローカルパートのルートから作成し、変更記録に担当者を明記し、1つのパターンに対して意図したルールが1つだけであることを確認してください。ドキュメントでは、複数のルールが同じパターンを使う場合、最初に並んでいるルールだけが受信メールを処理すると注意喚起されています。表示順を非公式な業務ルールとして当てにするのではなく、曖昧さそのものを取り除きましょう。破棄は意図的に配信しないことを意味するため、dropルールは正当な理由がある範囲に限定してください。キャッチオールを有効にするのは、プライバシー、スパムの量、入力ミス、ストレージへの影響を洗い出してからにします。キャッチオールは誰も作るつもりのなかったアドレス宛てのメールまで集めてしまう可能性があります。個人のメールボックスを黙って引き継がせるのではなく、専用の転送先またはWorkerのポリシー、アラート、すばやく無効化できる手段を用意しておきましょう。

サブアドレスは意図を持って使う

Cloudflareのドキュメントには、RFC 5233に準拠したオプションのプラスアドレス機能が記載されています。有効にすると、user+detail@example.comのようなアドレス宛てのメールが基本のuser@example.comのルールに一致し、detailの部分はWorkerやログに渡されるメッセージの受信者情報に保持されます。これはルーティング用のタグ、テスト用の識別子、ワークフローごとのエイリアスに活用できますが、detailは送信者が自由に指定できるテキストです。認証済みのテナントID、認可、秘密情報として扱ってはいけません。データベースのキー、メトリクスのディメンション、キュー名として使う前に、正規化して長さなどに上限を設けてください。また、Cloudflareのドキュメントによると、サブアドレス全体を指定した明示的なルールは基本のルールより優先されます。後から追加した具体的なルールが既存のワークフローを気づかないうちに変えてしまわないよう、明示的なルールとフォールバックの両方のケースをテストしましょう。プラスタグはヘッダー、ログ、転送されたメッセージ、サポート用のエクスポート、アナリティクスに現れる可能性があるため、個人情報や機密データを含めないでください。

Workerは本当に処理が必要な場合にだけ使う

1つのアドレスを1つの検証済みメールボックスに転送するだけなら、直接転送を使います。制御された分岐、メッセージの検査、保存、拒否、返信、複数の転送先への転送が必要な場合に、Workerへルーティングします。Cloudflareのメールハンドラーは、エンベロープの送信者と受信者、ヘッダー、生のMIMEストリームとそのサイズ、そして転送・返信・拒否のためのメソッドを提供します。ハンドラーは小さく保ちましょう。まず受信者のポリシーを検証し、メッセージとパースに上限を設け、外部呼び出しは可能な限り時間制限付きのキューを経由させ、すべてのエラーについて結果を定義します。ヘッダー、件名、表示名、添付ファイル、リンク、MIMEの境界は攻撃者が制御できるものです。デフォルトで生の本文や完全なアドレスをログに記録しないでください。コンテンツを保存する必要がある場合は、暗号化し、テナントとジョブ単位でアクセスを制限し、削除の方針を定め、添付ファイルのスキャンは同期的なルーティング経路の外で行います。パースの例外によって、意図しない転送や返信に処理が流れてしまうことがあってはなりません。

明示的な判断経路を1つだけ実装する

安全なハンドラーは、副作用のある処理を行う前に、承認されたアクションを決定します。たとえば、エンベロープの受信者を設定済みのワークフローに正確に対応付け、不明な受信者は拒否し、上限を設けたメタデータのレコードをキューに入れてから、設定から選んだ検証済みの転送先にだけ転送します。転送先をメッセージのヘッダー、件名、プラスタグ、本文から受け取ってはいけません。複数の転送先に転送する場合、Cloudflareの制限に関するドキュメントによると、Workerは検証済みの転送先ごとにforwardを1回ずつ呼び出す必要があります。一部だけ成功した状態を許容するかを決め、各試行を個別に記録してください。ログには受信者の内容ではなく、安定した内部用の相関IDを使います。ハンドラーが返信する可能性がある場合は、Cloudflareの現行の返信に関する制約に従い、ループ防止策を追加してください。自動返信は人間のチームによる受信確認ではありません。アプリケーションとして確実な受け付けが必要な場合は、自動応答を送る前にチケットやイベントを保存し、あいまいな失敗は、処理が作成されたと約束するのではなく突き合わせによって解消しましょう。

転送と返信は、証拠の範囲が限られた結果として扱う

Workerのメソッド呼び出しが成功したことは、プラットフォーム上の操作についての証拠であり、ユーザーにとっての最終的な結果ではありません。SMTPはシステム間の転送を定めるものであり、その後のフィルタリング、転送、隔離、メールボックスのルール、人が読むかどうかは、そのホップの範囲外です。「Cloudflareが受信」「Workerが起動」「アクションを試行」「転送先サーバーが受け付け」「遅延または失敗」「アプリケーションのレコードを作成」といった状態は分けてモデル化しましょう。これらをすべて「配信済み」とラベル付けしてはいけません。ルールのID、Workerのリビジョン、アクション、タイムスタンプ、相関ID、大まかな結果を含む、構造化されプライバシーに配慮して最小化したログを残します。完全なアドレスやコンテンツは、文書化された運用上の必要性がある場合にのみ保存してください。起動の失敗、サイズによる拒否、キャッチオールの異常な量、繰り返される送信者のパターン、転送先での失敗、トラフィックの急変にはアラートを設定します。管理されたテストメッセージを継続的にサンプリングしますが、実際の顧客のコンテンツを可観測性のテストデータとして使ってはいけません。

現行のプラットフォームの制限と障害モードを踏まえる

Cloudflareは現在、Email Routingの制限として、ドメインあたり200件のルーティングルール、アカウントあたり200件の転送先アドレス、25 MiBの受信メッセージサイズ上限、そしてWorker経由でルーティングされるメッセージにはWorkersの標準的なCPUとメモリの制限を記載しています。これらは恒久的な定数ではなく、現時点のプロバイダーのドキュメントとして扱ってください。計画時には最新の制限ページを確認し、上限に近づくかなり前にアラートを出しましょう。大きなMIMEメッセージは、不用意にデコードすると、プラットフォームの生サイズの上限以下でもメモリやCPUを使い果たすことがあります。不要なコンテンツはストリーミング処理するか拒否し、添付ファイル数に上限を設け、負荷の高いパースは上限付きの非同期処理に回してください。Cloudflareのルーティングドキュメントによると、Workerの名前を変更するとルーティングのバインディングが壊れることがあるため、デプロイ後の検証にルートの確認を含めましょう。失敗した起動はWorkersのログで確認できるはずですが、ログがあるだけでは再実行（リプレイ）はできません。送信者にSMTPで再試行させるのか、運用者がアプリケーションのジョブを安全に再実行できるのか、後段でのレコードの重複をどう防ぐのかを決めておいてください。

ロールアウトとロールバックを1つの変更としてテストする

まずステージング用またはリスクの低いルートを作成します。検証済みの転送先とは別のアカウントから管理されたメッセージを送り、プレーンテキスト、マルチパートのコンテンツ、想定される添付ファイル、プラスアドレス、未知のローカルパート、安全な範囲で意図的に不正な形式にした入力を網羅します。DNSの応答、ダッシュボードの設定、Workerのリビジョン、転送結果、後段のレコード、プライバシーに関する挙動を確認してください。次に、異常系をテストします。未検証の転送先、無効化されたルール、Workerの例外、サイズ超過のメッセージ、重複配信、本来ならキャッチオールに該当するルールなどです。各段階で期待される証拠を記録します。トラフィックを拡大する前に、ルールの無効化、必要に応じた以前のMXレコードへの復元、Workerの切り離し、遅延または拒否されたメールについての連絡をリハーサルしておきましょう。説明のつかないルーティングの消失、テナント間での露出、コンテンツの漏えい、予期しない返信、上限のないストレージ使用、Workerの継続的な失敗が起きた場合はロールバックします。設定のスナップショットとテスト結果は保存しますが、メッセージの内容は必要以上に長く保持しないでください。

SendHQの位置付け

SendHQはメール受信をサポートしています。このガイドはCloudflare Email Routingを対象としています。各サービスの設定と上限については、それぞれのドキュメントに従ってください。

よくある質問

出典

• メールのルーティング（Route emails） — Cloudflare
• メールルーティングのルールとアドレス — Cloudflare
• ルーティングされたメール向けのWorkers API — Cloudflare
• Cloudflare Email Serviceの制限 — Cloudflare
• RFC 5321：簡易メール転送プロトコル（SMTP） — RFC Editor
• RFC 5233：Sieveメールフィルタリング：サブアドレス拡張 — RFC Editor