Cloudflare Email Routingで独自ドメインメールを既存メールへ転送する設定記録

お問い合わせ窓口を独自ドメインで受けるため、Cloudflare Email Routingで受信メールを既存のメールボックスへ転送する設定を行った。この設定で扱うのは受信経路であり、フォームからメールを送る仕組みとは別である。役割を混同すると、転送設定だけでフォームが送信できると考えたり、送信APIの認証情報を受信設定へ置いたりしやすい。

受信転送として設定する

Email Routingでは、転送先を確認してから、独自ドメイン宛のルールを設定する。今回の構成では問い合わせ用アドレスの受信転送を設定し、テストメールが転送先へ届くことを確認した。転送先のメールアドレス、確認用メールの内容、個人を特定できる情報は公開しない。

受信メールを転送するEmail Routingと、フォームからメールを送信するEmail Serviceは別の経路として扱う。

DNSをCloudflareで管理する場合でも、メールに必要なレコードを変更する前に既存のメール運用を確認する。設定画面が提示するレコードとゾーン内の既存レコードを比較し、同じ用途のレコードを推測で上書きしない。変更後は送信側の受信拒否や迷惑メール判定も含め、実際にテストメールで確認する。

公開窓口をフォームへ変えた理由

以前は公開HTMLにメールアドレスとmailto:を置いていたが、現在は/contact/のフォームを窓口にしている。これは受信転送を不要にする変更ではない。直接の連絡先を収集対象にしないことと、フォームの入力検証・迷惑送信対策を通すことを優先した判断である。

フォーム送信はPages FunctionからCloudflare Email Service REST APIを呼ぶ。Email Routingは届いたメールを転送する機能、Email Serviceはアプリケーションが送信する機能として扱う。どちらか一方の設定結果から、もう一方が動作すると判断しない。

失敗しやすい点と確認方法

DNSレコードを設定しただけで受信確認を終えない。外部の送信元からテストし、転送先で到着を確認する。フォームを導入した後も、直接受信・フォーム送信・返信の各経路は別々に確認する。サイト本文やリポジトリには転送先、認証情報、実メール本文を残さない。

受信のテストでは、到着したかだけでなく、意図した宛先として扱われたか、返信時に不要な経路を選ばないかを確認する。迷惑メールフォルダも確認対象に含めると、単に届かない場合と振り分けられた場合を分けられる。送信側のドメイン認証や配送品質は受信転送だけで保証できるものではないため、問題が起きたときはDNS、転送ルール、送信元を順番に切り分ける。

サイト上の連絡手段をフォームに集約したのは、窓口を隠すためではなく、必要な入力値を受け取り、プライバシーポリシーへの導線を示し、迷惑送信対策を適用するためである。フォームが一時的に利用できない場合に備えた受信経路の扱いも、公開する連絡先と同じではない。公開情報と運用情報を分けることが、個人情報を記事へ持ち込まない判断につながる。

受信転送の設定変更では、既存のDNSや他サービスに影響しないかを先に確認する。メールの経路は設定後に見えにくくなるため、変更前後の確認項目を短く残し、問題があれば直前に変更したレコードやルールから戻って調べる。ここでも、画面上の設定完了表示より実際の受信テストを優先する。

公式資料と関連記事

• Cloudflare公式: Email Routing — 受信転送の設定とDNS要件の確認先。
• お問い合わせ — 現在の問い合わせ窓口。