Cloudflare

独自ドメインの info@ メールを Cloudflare + Resend + Gmail で 0円〜運用する

独自ドメインの封筒が Cloudflare と Resend と Gmail を経由して机の上に届くイメージ
受信は Cloudflare、送信は Resend、UI は普段の Gmail。役割分担で 0円〜運用にする

個人開発でも独自ドメインの対外アドレスは欲しい

個人開発でプロダクトを公開すると、わりと早い段階で「問い合わせ用のメールアドレス、どうしよう」という問題にぶつかります。AdSense の認証、申請書類の差出人、特商法表記の連絡先、X の DM じゃさすがに不安そうな案件 ── 受け皿としてのメールアドレスが必要になる場面はけっこう多いんですよね。

普段の Gmail をそのまま晒すのも、できれば避けたいです。本名アカウントだったり、プライベートに使っているアドレスだったりすると、ブランドと混ざるのが気持ち悪い。プロダクト/ドメイン側で info@example.com のような対外アドレスを立てておいて、そこに集約したくなります。

ただ、独自ドメインのメール運用というと真っ先に思い浮かぶのが Google Workspace で、これが個人で持つにはやや重いんですよね。月課金が複数ドメイン分ぶら下がってくると、収益化前のプロダクトには釣り合いません。

ということで、てちこまログ周りの info@ メールはこんな構成で組みました。

  • 受信: Cloudflare Email Routing で info@techikoma.com を普段使いの Gmail に転送
  • 送信: Resend の SMTP を経由して、Gmail から info@techikoma.com の差出人で送信
  • UI: 受信も送信も全部いつもの Gmail に集約 (Send mail as)

無料枠の範囲に収まるので、運用コストは実質 0 円です。Workspace を入れる前の選択肢として、個人開発と相性が良いなと感じています。

全体像

役割を整理するとこんな感じです。

役割担当サービス動き
受信Cloudflare Email Routinginfo@techikoma.com 宛てのメールを、普段使いの Gmail に転送する
送信Resend SMTP (smtp.resend.com:587)Gmail から API キーをパスワードにして、info@ 差出人で送信する
UIGmail (普段使い)受信トレイで読み、Send mail as で info@ から書く

ポイントは、受信と送信を別々のサービスに分担させて、UI は Gmail 1 個にまとめるというところです。Cloudflare は受信転送だけ、Resend は送信だけ、Gmail はそれを束ねて操作する場所、と役割が綺麗に分かれます。

1. 受信側 — Cloudflare Email Routing

ドメインを Cloudflare で管理しているなら、受信は Email Routing を有効化するだけで終わります。

Cloudflare のダッシュボードでドメインを開いて、サイドバーから Email > Email Routing。Get started を押すと、必要な MX レコードと SPF が自動で DNS に投入されます。既存の MX が他に向いていたら警告が出るので、その場合は競合先を整理してから進めます。

設定するのは 2 か所だけです。

  • Custom address: info@techikoma.com
  • Action: Send to an email → 普段の Gmail アドレス (例: you@gmail.com)

転送先には Cloudflare から確認メールが飛ぶので、Gmail 側でリンクを踏んで承認します。これで info@techikoma.com 宛てのメールが、普段の Gmail に黙って流れ込んでくる状態になります。

Cloudflare Email Routing の Custom addresses 画面。info@techikoma.com を Send to an email アクションで個人 Gmail に転送する設定が Active になっている

ここまでで受信は完了です。早ければ数分、DNS の伝播が遅くても十数分くらいで動き始めます。

ちょっと寄り道 — Resend ってなに？

ここで初めて出てきた Resend について、軽く触れておきます。

Resend は開発者向けのメール送信サービスで、API でも SMTP でも送れます。最近の個人開発・スタートアップ界隈では、SendGrid や Mailgun のポジションをこれが置き換えつつある印象で、Vercel / Next.js まわりのスタックでよく見かけます。

今回の用途で押さえておきたいのは次の3つです。

  • 無料枠が月 3,000 通。個人プロダクトの問い合わせ用途ならまず収まる範囲
  • Auto configure で DNS が自動投入される。Cloudflare で DNS を持っていれば、SPF / DKIM / MX のレコードを Resend が直接書き込んでくれる
  • Tokyo リージョン (ap-northeast-1) がある。国内向けの送信レイテンシも軽い

今回は API ではなく SMTP リレーとして使うので、Resend 上で触るのはドメイン登録と API キー発行の2つだけです。

2. 送信側 — Resend にドメインを登録

次は送信側。info@techikoma.com の差出人で Gmail から送れるようにするために、Resend を SMTP リレーとして使います。

Resend のダッシュボードで Domains > Add Domain を開いて、techikoma.com を入力。リージョンはお好みで (国内なら Tokyo) 選んで、設定方式は Auto configure を選ぶのが快適です。

Auto configure は、ドメインが Cloudflare で管理されていれば、SPF / DKIM / MX のレコードを Resend が直接 Cloudflare DNS に投入してくれます。手で TXT レコードを貼って typo に泣くフェーズが丸ごと省略されるので、これだけのために Cloudflare を使う価値があるレベルで便利です。

DNS が反映されると、Resend のドメイン一覧で Verified バッジが付きます。これが付いていないと送信時に DKIM が通らず、Gmail 側で「on behalf of」みたいな迂遠な表示が出るので、ここは確認しておきたいポイントです。

Resend の Domains 画面。techikoma.com が Verified になり、Tokyo (ap-northeast-1) リージョンで登録済みの状態

3. Resend の API キーを発行

Resend では SMTP のパスワードとして API キーを使います。API Keys > Create API Key で、

  • Permission: Sending access
  • Domain: techikoma.com のみにスコープを絞る

として発行します。全権限のキーは作らないのが大事です。Gmail の設定欄に貼るパスワードなので、Gmail のセキュリティイベントに巻き込まれた時の被害範囲を、送信権限 + 単一ドメインに限定しておきます。

発行されたキーは一度しか表示されないので、その場で Gmail の設定に進むのがおすすめです。

4. Gmail の Send mail as に登録

Gmail を開いて、Settings > Accounts and Import > Send mail as > Add another email address。

  • Name: 表示したい差出人名 (例: Techikoma)
  • Email address: info@techikoma.com
  • Treat as an alias: 用途で選ぶ。普段の Gmail と完全に別人格に見せたいなら外す、束ねて扱いたいなら入れる

Next を押すと SMTP の設定画面が出るので、

  • SMTP Server: smtp.resend.com
  • Port: 587
  • Username: resend (固定)
  • Password: 発行した Resend の API キー
  • Secured connection using TLS: 選択

で Add Account します。

ここで Gmail から info@techikoma.com 宛てに確認メールが飛びます。この確認メールが届いた瞬間が、受信(Cloudflare) と 送信(Resend) が両方繋がった瞬間で、けっこう気持ちいいです。確認メールに書かれている確認コード、または検証 URL を踏めば登録完了です。

Gmail のアカウントとインポート画面の Send mail as セクション。techikoma info@techikoma.com が追加され、メールの経由サーバーが smtp.resend.com、TLS を使用したポート 587 で接続される設定になっている

仕上げに、Settings > Accounts > When replying to a message を Reply from the same address the message was sent to にしておくと、info@ 宛てに来たメールにそのまま info@ で返信できます。デフォルトのままだと普段の Gmail に戻ってしまうので、ここを切り替え忘れると返信のたびに差出人が混在することになります。

ハマりどころ

実際にやって詰まった箇所をいくつか。

  • MX の競合で Email Routing が有効にならない 既存ドメインで MX が他に向いていたり、過去のレコードが残っていたりすると、Cloudflare 側のセットアップが完了しません。Cloudflare の警告に従って古い MX を整理するか、本当に上書きしていいか確認してから進めます。
  • Resend の DNS Verified が落ちる Auto configure を使ってもごくたまに反映までラグがあります。15〜30 分待って Verified が付かないなら、Cloudflare DNS 側でレコードが本当に追加されているか目視確認します。投入失敗ならレコードを手動で貼ります。
  • 送信元が「on behalf of」表示になる これは DKIM が通っていないサインです。Resend の Domains で Verified を確認、Gmail の Send mail as 側でも SMTP 設定が smtp.resend.com:587 / TLS になっているか見直します。
  • 「常にこのアドレスから返信」を入れ忘れる Reply when sent to / Always reply from default の切り替えを忘れると、info@ 宛てへの返信が普段の Gmail から飛ぶ事故が起きます。最初に切り替えておきます。
  • 作業 Gmail を間違える 普段の本名 Gmail と、ブランド用に分けた Gmail がある人ほど、Send mail as の作業をどっちでやるか取り違えやすいです。複数ブランドを持つなら、ブランド用 Gmail を 1 つ用意して、そこに集約するのが管理しやすかったです。

運用メモ

  • コスト: Cloudflare Email Routing は無料、Resend は無料枠が月 3,000 通あるので、個人プロダクトの問い合わせ用途ならまず収まります
  • ドメインを増やす: ドメインが増えても Resend に Add Domain → Gmail に Send mail as 追加、で同じ Gmail に集約できます
  • 送信ログ: Resend のダッシュボードで送信履歴・配信ステータス・バウンスが見られるので、届いたか怪しい時はそこを見れば一発です
  • API キーのローテーション: 万が一漏れた時に備えて、Resend 側でキーを再発行 → Gmail の SMTP パスワードを差し替えるだけで切り替えできます
  • 個人ブランドと普段使いの分離: ブランド用 Gmail を別アカウントで持っておくと、Workspace なしでも公私の境界が引きやすいです

まとめ

役割を分割すると、独自ドメインのメール運用は思っているより軽く組めます。

  • 受信: Cloudflare Email Routing (無料・転送のみ)
  • 送信: Resend SMTP (無料枠・DKIM 付きでまともに届く)
  • UI: 普段の Gmail に Send mail as で集約

Workspace を入れる前の選択肢として、個人開発との相性は良いです。プロダクトが複数ある人ほど、対外アドレスを 1 つの Gmail に束ねられる利点が大きいなと感じています。

#Cloudflare #Cloudflare Email Routing #Resend #Gmail #個人開発 #メール