独自ドメインを取ったあと、多くの人が次に欲しくなるのが [email protected] のような自分のドメインのメールアドレスです。ところが、これを自前で用意しようとするとメールサーバーの構築と運用という重い作業が待っています。レンタルサーバーやGoogle Workspaceなどの有料サービスを契約する、というのが一般的な解決策でした。
Cloudflare Email Routingは、この課題を「受信して転送する」という一点に絞って解決します。メールサーバーを持たないまま独自ドメインのアドレスをいくつでも作り、届いたメールを普段使っているGmailなどのメールボックスへ転送できます。しかも無料です。
このページで分かること
- Email Routingが何をしてくれるサービスなのか（そして何をしないのか）
- メールが届くまでの流れとMXレコードの役割
- カスタムアドレスとCatch-all（全受信）の使い分け
- Email Workersでメールをプログラムから扱う方法
- 無料の範囲と主な制限、導入前に知っておくべき注意点
Email Routingとは
Email Routingは、独自ドメイン宛に届いたメールをCloudflareが受け取り、あらかじめ登録しておいた既存のメールアドレスへ転送するサービスです。
やっていることは「メールの転送」だけですが、これによって次のことが可能になります。
info@support@shop@といったアドレスを、用途ごとにいくつも作る- どのアドレス宛のメールも、普段使っているひとつの受信箱にまとめて受け取る
- 受け取ったメールをWorkers（前々ページ）のコードで処理する
重要なのは、Email Routingはメールボックスを提供しないという点です。Cloudflare側にメールが保管されることはなく、届いたものはそのまま転送されて通過していきます。IMAPやPOPで接続する先も存在しません。あくまで既存のメールボックスへの「通り道」を作るサービスです。
なお現在、Email Routingは「Cloudflare Email Service」という枠組みの中の受信側の機能という位置づけになっています。同じ枠組みには送信用のEmail Sending（2026年8月時点でベータ、Workers有料プラン向け）もありますが、本ページで扱うEmail Routingは無料プランを含む全プランで正式提供されています。
メールが届くまでの流れ
仕組みを理解するには、まずメールの宛先がどう決まるかを知る必要があります。第1章のDNSで扱ったレコードのうち、メールの配送先を指定するのがMXレコード（Mail eXchanger）です。
誰かが [email protected] へメールを送ると、送信側のサーバーはまず example.com のMXレコードをDNSに問い合わせ、「このドメインのメールはどのサーバーが受け取るのか」を調べます。Email Routingを有効にすると、このMXレコードがCloudflareのメール受信サーバーを指すように自動設定されます。あわせて、なりすまし対策のためのSPFとDKIMのTXTレコードも追加されます。
以降の流れは次のとおりです。
- 送信者が
[email protected]へメールを送る - MXレコードに従って、メールがCloudflareへ届く
- Cloudflareが設定されたルールと照合する
- ルールに合致すれば、指定された転送先（検証済みのアドレス）へ転送する。あるいはEmail Workerのコードへ渡す
利用者から見れば、いつものGmailの受信箱に [email protected] 宛のメールが届くだけです。
設定の手順
大まかな手順は次の3つです。
- ドメインをCloudflareで管理する：Email RoutingはCloudflareのDNSを使っていることが前提です。ネームサーバーをCloudflareに向けた状態（第1章で扱った構成）である必要があります
- 転送先アドレスを登録して検証する：転送先にしたいメールアドレス（例：自分のGmail）を登録すると、そのアドレス宛に確認メールが届きます。中のリンクを開いて初めて転送先として使えるようになります。この検証があるため、他人のアドレスへ勝手に転送させることはできません
- カスタムアドレスを作る：
infoのような名前の部分を決め、どの転送先へ送るかを指定します
DNSレコードの追加はCloudflareが自動で行うため、手作業でMXレコードを書く必要はありません。反映は通常5〜15分程度です。
Catch-all（全受信）
ひとつずつアドレスを作るほかに、Catch-allという設定があります。これを有効にすると、ルールに一致しないものを含め、そのドメイン宛のすべてのメールが指定の転送先へ届きます。
[email protected] のように相手が打ち間違えたアドレス宛のメールも取りこぼさずに受け取れる一方、宛先を問わず届くため迷惑メールも一緒に流れ込みます。個人の小規模な用途では便利ですが、公開しているドメインでは受信量に注意してください。
Email Workers：メールをコードで扱う
Email Routingの転送先には、メールアドレスの代わりにWorkerを指定できます。これがEmail Workersです。
コードの形はWorkersの fetch ハンドラと同じ考え方で、入口が email に変わります。
export default {
async email(message, env, ctx) {
// message から差出人・件名・本文などを読み取って処理する
},
};
message を通じて、差出人・宛先・件名・ヘッダー・本文（生のMIMEデータ）・サイズを読み取れます。そのうえで、次の操作ができます。
- 転送する：検証済みの宛先へ送る（複数宛先も可能）
- 返信する：元のメールに紐づく形で自動返信する
- 拒否する：条件に合わないメールをSMTPのエラーとして突き返す
- 読み取って別の処理へ渡す：内容をD1に保存する、Slackへ通知する、といった連携
たとえば「特定の文言を含む問い合わせだけ担当者へ転送し、残りは記録だけ残す」「注文確認メールを解析してデータベースに登録する」といった自動化が、メールサーバーを持たずに実現できます。第2章のTurnstileと同じく、サーバーを用意せずに実用的な機能を足せる例のひとつです。
無料の範囲と主な制限
Email Routingは全プランで無料で使えます（2026年8月時点）。主な制限は次のとおりです。
- 転送先アドレス：1アカウントあたり200件まで（検証が必要。複数ドメインで共用できます）
- ルーティングルール：1ドメインあたり200件まで
- 受信メールのサイズ：25MiBを超えるメールは拒否されます
- Email Workerの実行：Workersの制限（CPU時間など）がそのまま適用されます。無料プランで重い処理を書くと、CPU時間の超過で失敗することがあります
初心者が注意するポイント
- 送信はできません：これが最大の注意点です。Email Routingで作ったアドレスは受信専用で、そのアドレスを差出人としてメールを送る機能はありません。Gmailの「送信元アドレスの追加」で送ろうとしても、別途送信用のSMTPサーバーが必要になります。送信も必要な場合は、Google WorkspaceやMicrosoft 365などのメールサービス、あるいは送信専用サービスとの併用を検討してください
- 既存のメールサービスとは共存できません：MXレコードはドメインのメール受信先を決めるものです。すでにGoogle Workspaceなどでそのドメインのメールを受けている場合、Email Routingを有効にするとMXが置き換わり、既存のメール受信が止まります。切り替えは慎重に行ってください
- 転送先で迷惑メール扱いされることがあります：転送されたメールは、送信者と転送先の間にCloudflareが挟まる形になります。SPFやDMARCの判定の都合で迷惑メールフォルダに入る場合があるため、導入直後は転送先の迷惑メールフォルダも確認してください
- 転送先のアドレスは自分で管理し続ける必要があります：転送先のGmailアカウントを失うと、そのドメイン宛のメールも受け取れなくなります
- CloudflareのDNSを使っていることが前提です：ネームサーバーをCloudflareに向けていないドメインでは利用できません
関連サービス
- DNS：MXレコードの仕組みそのもの。Email Routingの土台（第1章）
- ドメイン：受信するアドレスのもとになる独自ドメイン（第1章）
- Workers：Email Workersの実行環境。メールをコードで扱う（前々ページ）
- Turnstile：同じく「サーバーを持たずに使える実用機能」の例（第2章）
- D1・R2：Email Workerで受け取った内容の保存先（第6章）
まとめ
- Email Routingは、独自ドメイン宛のメールを受け取り、既存のメールアドレスへ転送する無料のサービス
- メールボックスは提供せず、あくまで受信と転送の通り道として動く
- 有効にするとMXレコードがCloudflareを指すように自動設定され、SPF・DKIMも追加される
- 用途別のカスタムアドレスに加え、すべてを受け取るCatch-allも設定できる
- 転送先にWorkerを指定すれば、転送・自動返信・拒否・記録といった処理をコードで書ける
- 送信はできず、既存のメールサービスとはMXレコードを取り合う点に注意する
次のページからは、再び開発プラットフォームの中身に戻ります。Workersの「状態を持てない」という制約を正面から解決する仕組みが、Durable Objectsです。
次に読む
※本記事の情報は 2026年8月時点のものです。