独自ドメイン（例: [email protected]）のメールを、メールボックス料金を一切払わずにGmail上で使いたいという場面は多いはずです。実際にCloudflareとGmailの組み合わせで試したところ、「受信」と「送信」はまったく別の仕組みで動いており、両者の難易度も大きく違うことが分かりました。本記事ではその手順と、送信側だけがメール認証の原理上どうしても割り切りを要する理由を、公式ドキュメントとRFCの定義に基づいて整理します。

結論 — 受信は無料で完結、送信もできるが認証だけは割り切りが要る

  • 受信は簡単で、確実に無料で閉じる。 Cloudflare Email Routingがドメイン宛のメールを既存の受信箱（Gmail）へ転送します。無料で利用でき、必要なDNSレコードは自動で作られます。ただし件数は無制限ではなく、Email Routingの制限一覧によれば、ドメインごとのルーティングルール（カスタムアドレス）は200件、アカウントごとの検証済み転送先アドレスも200件が上限です。
  • 送信は無料でできるが、構造的な制約が一つ残る。 Gmailの「他のアドレスから送信」で独自ドメインを差出人にして送れます。しかし個人のGmailアカウントでは自ドメインのDKIM署名を打てないため、独自ドメインの視点ではDMARC認証が原理上そろいません。ここを理解せずに独自ドメインへ厳格なDMARCポリシー（p=reject など）を設定すると、自分が送ったメールが自分のドメインのポリシーで弾かれうります。

つまり「無料でGmail上に独自ドメインメールを載せる」という前提は正しく、200件という上限も個人利用の範囲では問題になりません。そのうえで、送信側の認証だけは割り切りが必要——というのが本記事の主題です。

全体像：受信と送信は別物

メールは「受け取る経路」と「送り出す経路」が独立しています。この構成では両者を別のサービスが担当します。

担当料金難易度
受信Cloudflare Email Routing（転送）無料低
送信Gmail「他のアドレスから送信」＋ Gmail SMTP無料中（認証の理解が要る）

Cloudflare Email Routingは明確に受信（転送）専用であり、この機能自体からメールを送信することはできません（Email routing rules and addresses）。だから送信は別途Gmail側に任せます。以下、受信 → 送信 → 認証の順に組み立てます。

1. 受信側を作る（Cloudflare Email Routing）

前提条件

Email RoutingはドメインのDNSがCloudflareで管理されていること（ネームサーバがCloudflareを向いていること）が必須です（Email Routing — Cloudflare）。ドメインをCloudflareに追加していない場合は、まずネームサーバの移管を済ませておきます。

設定手順

  1. Cloudflareダッシュボードで対象ドメインを選び、Email Routing を開く。
  2. 転送先アドレス（Destination Address） に、受信を集約したいGmailアドレスを登録する。Cloudflareが確認メールを送ってくるので、Gmailの受信箱でリンクを踏んで検証を完了する。検証が済むまでルーティングルールは有効化されない（スパム悪用防止のため）。
  3. ルーティングルール（Routing Rule） を作る。[email protected] のようなカスタムアドレスと、検証済みのGmailを紐づける（Email routing rules and addresses）。
  4. Email Routingを有効化すると、CloudflareがMX・SPF・DKIM のDNSレコードを自動で追加する（Domain configuration）。この自動追加のSPF/DKIMは、あくまで転送経路を正しく認証させるためのものである点に注意（送信用ではない）。

覚えておくと便利な機能

  • キャッチオール（Catch-all）：存在しないローカルパート宛を含め、そのドメイン宛のすべてを1つの受信箱へ流せる。タイプミス救済に便利だが、迷惑メールも全部拾うので運用は慎重に（Email routing rules and addresses）。
  • サブアドレッシング（プラスアドレス）：[email protected] のような + 付きアドレスをRFC 5233に準拠して扱える。+ 以降は無視して user@ のルールで受けつつ、ログやWorkerで用途識別に使える。
  • Worker連携／Drop：受信メールをWorkerでプログラム処理したり、特定アドレス宛を破棄（存在するように見せて捨てる）することもできる。

落とし穴

  • Email Routingを有効化すると、そのドメインのMXがCloudflareを指す。後からGoogle WorkspaceやMicrosoft 365を同じドメインに入れると、それらが発行する新しいMXがCloudflareのMXを上書きし、転送が止まる。メールプロバイダを切り替えるときは、先にEmail Routingを無効化するか、MX優先度を意識すること（Domain configuration）。
  • 受信専用なので、あなたがGmailからそのまま返信すると差出人は @gmail.com になる。宛先には個人アドレスが見えてしまう。ここを独自ドメインに見せるには、次の送信設定が必要になる。

この時点で「受信」は完全に無料で閉じています。ここまでで十分な人も多いはずです。

2. 送信側を作る（Gmailの「他のアドレスから送信」）

Gmailには、自分が所有する別アドレスを差出人にして送る「他のアドレスから送信（Send mail as）」機能があります。これを使って [email protected] を差出人にします。

事前準備：2段階認証とアプリパスワード

個人のGmailアカウントを送信サーバとして使うには、Gmailの外部SMTP（smtp.gmail.com）に認証情報を渡す必要があります。そのために：

  1. Googleアカウントで2段階認証（2-Step Verification）を有効化する。
  2. アプリパスワードを発行する（myaccount.google.com/apppasswords）。2段階認証が有効でないとアプリパスワードの項目は現れない。

このアプリパスワードが、SMTP認証のパスワードになります。

Gmailでの設定

  1. Gmailの 設定 → アカウントとインポート → 他のアドレスからメールを送信 で「別のメールアドレスを追加」をクリック。
  2. 名前と、差出人にしたい独自ドメインアドレス（[email protected]）を入力。
  3. SMTPサーバ情報を入力する：
    • SMTPサーバ：smtp.gmail.com
    • ポート：587（TLS）または 465（SSL）
    • ユーザー名：あなたの ～@gmail.com（※独自ドメインではなくGmailアドレス）
    • パスワード：先ほど発行したアプリパスワード
  4. Gmailが所有確認のため、[email protected] 宛に確認コードを送る。

ここで受信設定が効いてきます。確認コードは [email protected] に届き、Cloudflare Email Routing経由であなたのGmailに転送されます。コードを入力すれば所有確認が通り、受信と送信のループが閉じます。以後、Gmailの作成画面でFromに独自ドメインを選べるようになります。

3. 核心：なぜ「送信」だけ認証が厄介なのか

ここが本記事で最も正確さを要する部分です。上記の構成は動きます。だが「独自ドメインの視点でのメール認証」は原理上そろいません。理由をSPF・DKIM・DMARCの定義に戻って説明します。

SPFは「Fromヘッダ」を見ていない

SPF（Sender Policy Framework、RFC 7208）が認証するのは、SMTPのエンベロープ送信者（MAIL FROM / Return-Path）と HELO の識別子であって、受信者が画面で見る From: ヘッダではありません。RFC 7208自身、この2つ以外の識別子をSPFで検証することは「NOT RECOMMENDED」としています。

smtp.gmail.com 経由で送ると、送信インフラはGoogleなので、エンベロープ送信者（Return-Path）はあなたの @gmail.com になります。したがってSPFは「Googleのサーバが gmail.com を名乗って送っている」ことを検証し、gmail.comとしては合格します。表向きの差出人が [email protected] でも、SPFが照合しているのはそこではありません。

DKIMは「gmail.comの署名」になる

DKIM（DomainKeys Identified Mail、RFC 6376）は、送信側が秘密鍵でメッセージに署名し、受信側が d= で示されたドメインのDNS上の公開鍵で検証する仕組みです。Gmailは送信メールに d=gmail.com で署名します。個人のGmailアカウントでは、独自ドメイン（example.com）用のDKIM秘密鍵をGmailのSMTPに設定できません。独自ドメインでのDKIM署名は、Google Workspace（有料）の機能だからです。

DMARCが要求する「アライメント」がそろわない

DMARC（RFC 7489）の中心概念が識別子アライメント（Identifier Alignment）です。RFC 7489（3.1節）の定義そのものを引くと、「RFC5322.From アドレスのドメインが、SPFまたはDKIM（あるいは両方）で検証されたドメインと一致するとき、識別子アライメントを持つ」とされています。DMARCが合格するには、SPFかDKIMのどちらか一方が「合格し、かつFromドメインとアライメントしている」ことが必要です。

この構成を当てはめると：

項目実際の値Fromの example.com と一致？
From:（人が見る差出人）[email protected]—
SPFが検証するドメイン（Return-Path）gmail.com不一致
DKIM署名のドメイン（d=）gmail.com不一致

SPFはgmail.comで合格、DKIMもgmail.comで合格します。だがどちらも example.com とはアライメントしません。結果、example.com の視点ではDMARCがfailします。

実務上どうなるか

DMARCがfailしたときの扱いは、そのドメインが公開しているDMARCポリシー（p=）で決まります。

  • example.com にDMARCを設定していない／p=none の場合：多くの受信側はメールを通します。日常運用としては届きます（ただし受信側によっては迷惑メール判定が厳しくなることはあります）。
  • example.com に p=quarantine / p=reject を設定している場合：受信側はポリシーどおり隔離・拒否しえます。つまり自分のドメインに施したなりすまし対策で、自分のGmail送信メールが弾かれるという自己矛盾が起きます。

したがってこの無料構成を採るなら、独自ドメインのDMARCは厳格にしない（p=none に留める、あるいはDMARCレコードを置かない）のが現実解になります。「無料で送れる」ことと「独自ドメインを厳格に認証する」ことは、この構成では両立しません。

補足：受信者に見える痕跡

  • 受信者のメールソフトによっては、差出人の横に「via gmail.com」と表示されます。
  • メールのソースヘッダ（Return-Path等）に、送信に使ったGmailアドレスが残ります。技術的な受信者には辿られえます。

4. 「きちんと」やりたいときの選択肢

DMARCを厳格に運用したい、なりすまし対策を効かせたいという場合は、独自ドメインでDKIM署名できる送信経路を用意する必要があります。無料構成の割り切りが許容できないなら、次を検討します。

  • DKIM対応の外部SMTPリレーを使う（無料枠あり）：Brevoなどのメール配信サービスは、独自ドメインをDKIM/SPFで認証したうえでSMTPリレーを提供します。GmailのSMTPサーバ欄にそのリレー（例: smtp-relay.brevo.com）と発行された認証情報を入れれば、独自ドメインでアライメントの通る送信ができ、DMARCも成立します。無料枠に送信数の上限がある点は要確認です。
  • Google Workspace（有料）：ドメインでのDKIM署名を含め、送受信を正規に一本化できます。月額課金だが、認証・運用の面では最も素直です。
  • Cloudflare Email Sending（アプリ向け）：Cloudflareには受信のEmail Routingとは別に、Workers・REST API・SMTP経由でドメインから送信するEmail Sendingもあります。ただしこれはアプリケーションからのトランザクションメール送信が主眼で、Gmail画面での日常的な「返信」用途とは設計思想が異なります。

まとめ

  • 独自ドメイン宛メールをGmailで受け取るのは、Cloudflare Email Routingで完全に無料で閉じる（ただしルーティングルール・転送先アドレスとも200件が上限）
  • 独自ドメインを差出人にしてGmailから送るのも無料でできる（Gmailの「他のアドレスから送信」＋アプリパスワード）
  • 送信メールで独自ドメインのDMARCを合格させることは、個人のGmailでは不可能。理由はDKIMを自ドメインで打てないため
  • したがって独自ドメインに厳格なDMARC（p=reject）を敷くのはこの構成と相性が悪く、自分の送信が弾かれるリスクを負う

受信は迷わずCloudflare Email Routingでよい構成です。送信もGmailの「他のアドレスから送信」で無料で実現できます。ただし送信側は、SPFがエンベロープ送信者を、DKIMが d= ドメインを、DMARCが両者とFromのアライメントを見る——というメール認証の原理上、独自ドメインの認証はそろいません。この割り切りを理解したうえで使うか、DKIM対応の送信経路に一段上げるか、という判断になります。

参考