Email Routing

解決する課題

自前でメールサーバー（MTA）を構築・運用せずに、独自ドメイン宛のメールを受け取れます。

• 独自ドメインでメールを受けたいが、メールサーバーの構築・保守は避けたい
• 問い合わせ用・部署別など複数のカスタムアドレスを用意し、既存の受信箱に集約したい
• 使い捨てアドレスやエイリアスを増減させ、送信元ごとの管理をしたい
• 受信メールをトリガーに**自動処理（転記・通知・解析）**を行いたい

主要概念と用語

• ルーティングルール（Routing Rule）: 宛先アドレスと転送先（宛先アドレスまたはWorker）を結びつける設定の1件
• 宛先アドレス（Destination Address）: 転送先となる実際のメールボックス。利用前に所有権確認（確認メールの承認）が必要
• カスタムアドレス（Custom Address）: ドメイン配下の特定のローカルパート（例: info@example.com）に対するルール
• キャッチオール（Catch-all Address）: 個別ルールに一致しないすべての宛先メールを受け取る既定ルール
• Email Workers: 受信メールをイベントとして受け取り、コードで解析・転送・破棄などを行うWorkersの拡張（emailハンドラ）
• MXレコード / ルーティングレコード: メールをCloudflareへ届けるためにゾーンへ設定されるDNSレコード群（MX・SPF・DKIM関連のTXTなど）
• DMARC: 送信ドメインのなりすまし対策ポリシーを宣言するDNSレコード。Email Routing自体の受信可否には直接関係しないが、送信側ドメインの信頼性判断に影響する

仕様・制限・クォータ

• 受信専用の振り分け機能であり、独自ドメインからのメール送信は別のサービス（Email Workersでの送信API利用や外部SMTPサービス）が必要
• 有効化にはゾーンのDNSにCloudflareが提示するMX・TXT（SPF等）レコードを設定する必要がある
• 転送先の宛先アドレスは、事前に確認メールでの承認が完了していないと使用できない
• ルーティングルールの登録数やカスタムアドレス数には上限があり、規模に応じてキャッチオールやワイルドカードの活用が推奨される
• Email Workersで処理する場合、メッセージサイズやWorkers自体の実行時間・リソースにはWorkersプラットフォームの制限が適用される
• プロキシ化（オレンジクラウド）とは独立した機能で、ゾーンがCloudflareに委任されていることが前提となる

内部の仕組み

ドメインでEmail Routingを有効化すると、CloudflareはそのゾーンにMXレコードと送信認証用のTXTレコード（SPFなど）を設定するよう案内します。これにより、そのドメイン宛のメールはインターネット上の送信側MTAからCloudflareのメール受信基盤へ配送されるようになります。

受信したメールは、まずルーティングルールに照合されます。宛先のローカルパートが個別のカスタムアドレスに一致すればそのルールの転送先（宛先アドレスまたはWorker）へ、一致しなければキャッチオールルールへ渡されます。転送先が宛先アドレスの場合はそのまま外部の受信箱へ再送され、Workerが指定されている場合はメッセージ本体（ヘッダー・添付を含む）がイベントとしてEmail Workersのemailハンドラに渡され、コード側で転送・返信・破棄などの処理を行えます。

設計パターン / ベストプラクティス

• 問い合わせ窓口の集約: info@やsupport@など複数のカスタムアドレスを1つの受信箱へまとめて転送し、管理を簡素化する
• キャッチオール＋個別ルールの併用: よく使うアドレスは個別ルールで明示的に振り分け、それ以外はキャッチオールで漏らさず受ける
• Email Workersでの自動振り分け: 件名や送信元に応じてSlack通知やチケット起票など、受信メールをトリガーにした自動処理を組み込む
• エイリアスの使い捨て運用: サービスごとに異なるカスタムアドレスを発行し、漏洩元の特定やスパム遮断をアドレス単位で行う
• 送信は別サービスと分担: Email Routingは受信専用と割り切り、送信が必要な通知メールなどは別途送信用の仕組みと組み合わせる

運用・監視

• ダッシュボードのルーティングルール一覧で有効なルールと転送先を定期的に確認し、不要なアドレスを整理する
• **DNSレコード（MX・SPF関連TXT）**が意図せず変更・削除されていないか、ゾーン設定の変更履歴とあわせて点検する
• 宛先アドレスの確認状態を確認し、未承認のまま放置されたルールがないかチェックする
• Email Workersを利用する場合は、Workersのログ・エラー率を監視し、処理失敗時にメールが失われていないか確認する
• 転送先の受信箱側で迷惑メール判定が発生していないか確認し、必要に応じて送信側ドメインのSPF/DKIM/DMARC設定を見直す

コスト

セキュリティ

• ルーティングルールの追加・変更はダッシュボードやAPIトークンの権限管理下で行い、意図しない転送先追加を防ぐ
• 宛先アドレスの事前承認フローにより、第三者のメールアドレスを無断で転送先に設定できない仕組みになっている
• 送信ドメイン側のなりすまし対策として、自ドメインにSPF・DKIM・DMARCを適切に設定し、受信メールの信頼性を高める
• Email Workersで受信メールを処理する場合、添付ファイルや本文中のリンクを鵜呑みにせず、フィッシングやマルウェア混入を想定した検証ロジックを入れる
• キャッチオールルールは便利な反面、想定外の宛先宛メールも受け取ってしまうため、転送先の受信容量やスパム流入に注意する

関連サービス・比較

Email RoutingはWorkersと組み合わせて使われることが多く、受信メールの高度な自動処理はEmail WorkersのEmail Workersハンドラで実装します。他クラウドではAmazon SESの受信ルール（Receiving）が近い位置づけです。

ハンズオン / CLI例

Email Routingのルール設定は主にダッシュボードから行いますが、Email Workersと組み合わせる場合はwranglerでWorkerを作成・デプロイします。

# Email Workers用のプロジェクトを新規作成
wrangler init email-router-worker

# wrangler.tomlにemailハンドラ用のWorkerとしてデプロイ設定を記述後、
# Cloudflareアカウントへデプロイする
wrangler deploy

# デプロイしたWorkerのログをリアルタイムで確認し、
# 受信メールイベントの処理状況を確認する
wrangler tail

# アカウント配下のWorkers一覧を確認する
wrangler deployments list