Cloudflare 14：Email Routing ― 独自ドメインのアドレスを、今の受信箱で

一言でいうと：受け取って、今の受信箱へ転送する係

Email Routing は、独自ドメイン宛てのメールを Cloudflare が受け取り、決めた規則どおりに別のアドレスへ転送する機能です。 料金はかかりません。

図の中央の札が、転送の規則です。たとえば次のように決めます。

Email Routing がしないことも、はっきりさせておきます。

「受信箱は今のものを使い続け、入り口のアドレスだけ独自ドメインにする」。これが Email Routing の考え方です。アドレスはいくつでも作れるので、「サービスごとに別のアドレスで登録し、どこから漏れたか分かるようにする」といった使い方もできます。

仕組み①：MX を Cloudflare に向ける

メールはどうやって届け先を知るのでしょうか。答えは DNS の MX レコードです（メールのしくみシリーズで見たもの）。[email protected] にメールを送るとき、送信者のメールサーバーは DNS に「example.com のメールはどのサーバーに渡せばいい？」と聞きます。その答えが MX です。

Email Routing を有効にすると、Cloudflare が MX を Cloudflare のメールサーバーに向ける行を DNS に足してくれます。同時に、SPF の TXT レコードも足されます。

example.com  MX   xxx.mx.cloudflare.net   （優先度の違う行が複数）
example.com  TXT  "v=spf1 include:_spf.mx.cloudflare.net ~all"

MX のサーバー名は、アカウントによって違うことがあります。管理画面が示すものをそのまま使ってください。

ここで大事なのは、ほかの MX を残さないことです。前に別のメールサービスを使っていて、その MX が残っていると、送信者のサーバーはどちらか一方に届けます。すると、「届くメールと届かないメールがある」という、とても分かりにくい状態になります。Email Routing の設定画面は、邪魔になる古い行があると知らせてくれるので、確かめてから消しましょう。

なお、この仕組みは DNS が Cloudflare にあることが前提です（01号）。

仕組み②：届いたメールを、規則に当てて転送する

MX が Cloudflare を向いたので、example.com 宛てのメールはすべて Cloudflare に届くようになりました。図の小包が、いまエッジに届いたメールです。

Cloudflare は、メールの宛先を見て、規則の一覧から合うものを探します。

キャッチオールは、「規則に書いていないアドレス宛て」をまとめて扱う規則です。オンにして転送すると、どんなアドレスでも受け取れて便利ですが、そのぶん迷惑メールもすべて届きます。迷惑メールの業者は、admin@ sales@ などありそうなアドレスを片っ端から試すからです。最初は「捨てる」にしておき、必要なアドレスだけ規則を作るのが安全です。

規則の行き先は、転送先のアドレスか、Email Worker（コード）のどちらかです。1つの規則から複数のアドレスへ同時に転送したいときは、Worker を使います（あとのページ）。

仕組み③：今の受信箱に、そのまま届く

規則に当たったメールは、転送先の受信箱に届きます。図の小包が右の受信箱に着きました。

Gmail で見ると、このメールは「To: [email protected]」のメールとして表示されます。送信者（From）は元の送信者のままなので、返信ボタンを押すと、元の送信者に向けて返信が作られます。ただし、そのとき差出人は Gmail のアドレスになります。[email protected] として返信する方法は、あとのページで見ます。

Gmail 側でフィルタを作れば、「To が [email protected] のものにラベルを付ける」といった整理もできます。

受け取る側から見ると、Email Routing はほとんど目に見えない仕組みです。メールは Cloudflare を一瞬通るだけで、保存されずに転送されます。

ここで1つ問題が起きます。転送すると、メールの送り手が変わるのです。元の送信者のサーバーが送ったメールを、今度は Cloudflare のサーバーが Gmail に送ります。Gmail から見ると、「example.com から来たはずのメールを、Cloudflare のサーバーが送ってきた」ことになります。これが、次のページで見る SPF の問題です。

転送と SPF・DKIM・DMARC

メールの「なりすまし」を防ぐ仕組みは3つあります（メールのしくみシリーズ）。

SPF の問題に対して、Email Routing は封筒の差出人（エンベロープの From）を Cloudflare 側のアドレスに書き換えて転送します（SRS と呼ばれる方法）。こうすると、受け取った Gmail が確かめる SPF は「Cloudflare のサーバーが Cloudflare のアドレスとして送った」になり、合格します。見た目の From（画面に出る差出人）は変えません。

ここで混同しやすいのが、この話は受信の話だという点です。Email Routing が足す SPF の行は、Cloudflare があなたのドメインを受け持つためのものです。あなたが [email protected] として送るメールを信用してもらうには、送信に使うサービスに合わせて、SPF・DKIM・DMARC をそれぞれ設定する必要があります。

転送先は、先に「本人確認」が要る

転送先に [email protected] を登録すると、すぐには転送が始まりません。Cloudflare から [email protected] に確認メールが届き、中のリンクを押して初めて、転送先として使えるようになります。

なぜこの手間があるのでしょうか。もし確認なしで転送先を登録できると、他人のアドレスを勝手に転送先にして、大量のメールを送り込むことができてしまいます。自分のドメインを作り、キャッチオールで他人のアドレスに転送するだけで、迷惑メールの中継所ができてしまうのです。確認のリンクは、「このアドレスの持ち主が、転送を受け取ることに同意した」という印です。

転送が始まらないときは、まず転送先の状態が「確認済み」になっているかを見ましょう。

Email Workers：転送の代わりにコードを動かす

規則の行き先には、転送先のアドレスの代わりに Worker（18号）を指定できます。これを Email Workers と呼びます。届いたメールをコードで処理できるので、単純な転送ではできないことが書けます。

export default {
  async email(message, env, ctx) {
    const allow = ["[email protected]"];
    if (!allow.includes(message.from)) {
      message.setReject("Address not allowed");
      return;
    }
    await message.forward("[email protected]");
    await message.forward("[email protected]");
  },
};

この例では、許可した送信者以外は受け取りを拒否し、許可した送信者のメールは2つのアドレスに転送しています。転送先は、どちらも本人確認済みである必要があります。

メールを「人が読むもの」から「プログラムが受け取るもの」に変えられるのが、Email Workers の面白さです。

送信は別の機能：Email Routing では「送れない」

Email Routing で一番よくある誤解が、「[email protected] から送れるようになる」というものです。Email Routing は受信と転送だけで、送信はしません。 Gmail で返信すると、差出人は Gmail のアドレスになります。

[email protected] として送りたい場合は、送信の仕組みを別に用意します。

Cloudflare では、受信の Email Routing と送信の Email Sending をまとめて Cloudflare Email Service と呼ぶようになっています。組み合わせれば、「メールを受け取って Worker で処理し、返信する」までを Cloudflare の中で完結できます。ただし Email Sending はベータで、アプリからの通知メールのような用途が中心です。人が日常的に使う送信には、まだ外部のサービスを使うことが多いでしょう。

どの方法でも、送信に使うサービスに合わせて SPF と DKIM の設定を足すことを忘れないでください。足さないと、送ったメールが迷惑メール扱いされます。

導入：ドメインを選んで、規則と転送先を作る

Email Routing の設定は、管理画面だけで数分で終わります。前提は、ドメインの DNS が Cloudflare にあることです（01号）。

5の試験は、転送先と同じアドレスから送らないのがコツです。Gmail は、自分で送ったメールが自分に戻ってくると、受信箱に表示しないことがあります。別のアドレス（携帯のメールなど）から送ってみましょう。

規則やアドレスは、API や Terraform でも管理できます（34号）。

料金と制限：受信・転送は無料

具体的な上限の数字（規則の数・転送先の数・サイズ）は、公式の Limits のページで確かめてください。個人や小さなチームの使い方で困ることは、まずありません。

逆に、大量のメールを受け取る業務（毎日何万通も届く問い合わせ窓口など）や、メールの保管・監査が必要な会社の用途には、Email Routing は向きません。その場合は、専用のメールサービスを使いましょう。

2026年9月時点の情報です。料金・上限は変わるので、公式で確かめてください。

よくある落とし穴

とくに最後の2つは、「Email Routing を入れたらメールが全部うまくいく」と思い込んだときに起きます。Email Routing は受信の入り口だけを受け持つ、と覚えておけば避けられます。

ほかの号とのつながり

Email Routing は、Cloudflare の中でも「無料で、すぐ効く」機能の代表です。ドメインを持ったら、まず info@ を作ってみるとよいでしょう。