不租企業郵箱也能有自己的域名信箱：Cloudflare 轉發加 Resend 發信，這套零成本方案是怎麼跑起來的

有一個自己的域名信箱，聽起來像公司行號才需要的事。但對獨立開發者、接案者、或只是想讓個人網站看起來體面一點的人來說，能夠用 support@自己的域名 收信寄信，成本與效益之間一直存在一段尷尬的距離。企業郵箱要月繳費用，自建郵件伺服器則是一條出了名的深坑。近日一名開發者 SoyaLeaf 在 V2EX 分享了一條中間路線：用 Cloudflare Email Routing 負責收信，用 Resend 負責發信，再配上一個自己寫的 Chrome 擴充功能處理回信，全程不搭建郵件伺服器，免費額度內不花一毛錢。

這套方案的價值不在於技術新穎，兩個服務都已存在多年。它值得看懂的地方在於，作者把「收信」和「發信」拆成兩條獨立的路徑，各自交給最便宜甚至免費的服務處理，最後在使用者端把它們縫合起來。理解這個拆分，等於理解了現代電子郵件的分工結構。

電子郵件其實是兩件事，不是一件事

一般人開信箱軟體，收信寄信看起來是同一個動作。但在基礎協定層面，這是兩套完全不同的系統：收信靠 MX 記錄把別人寄來的信導到某臺伺服器，發信則需要一臺被信任的伺服器代為寄出。自建郵件伺服器之所以痛苦，就是因為你得同時搞定這兩件事，還要處理信譽問題。大型信箱服務對陌生伺服器寄來的信極度挑剔，一個沒養過信譽的 IP，寄出去的信大概率先進垃圾郵件夾。

打個比方，這就像開一家小店。收信是客人上門，你只要掛對招牌（MX 記錄），告訴郵差「寄到這個地址的包裹放這裡」就行。發信則是你主動出貨，物流公司願不願意幫你送、收件方願不願意簽收，取決於你這家店有沒有累積信用。Cloudflare 解決的是掛招牌的部分，Resend 解決的是出貨的部分。

先看收信。Cloudflare Email Routing 的機制是：你把域名的 DNS 託管在 Cloudflare，開啟 Email Routing 後，Cloudflare 會自動為你的域名加上它指定的 MX 與 TXT 記錄。之後任何人寄信到你的域名地址，信會先到 Cloudflare，再依照你設定的規則，轉發到你真正的個人信箱，QQ 郵箱、Gmail 或 Outlook 都行。你不需要管理任何儲存空間，因為 Cloudflare 只做轉手，信最終躺在你既有的信箱裡。

這裡有個實務上的細節值得記住：如果你這個域名原本就在用其他郵件服務，DNS 裡已經存在 MX 記錄，直接開啟 Email Routing 並讓 Cloudflare 覆寫記錄，舊信箱會立刻收不到信。作者在分享中也特別提醒這一點。MX 記錄一個域名同時只能有一組生效，這是郵件系統的老規矩，也是大多數「信收不到」事故的源頭。

發信這條路，交給 API

收信解決了，接下來是發信。如果你直接用 Gmail 回覆一封寄到 support@你的域名 的信，對方看到的發件人會是你的 Gmail 地址，域名信箱的偽裝立刻破功。

Resend 處理的就是這一公裏。它是一家提供發信 API 的服務，你在 Resend 後臺驗證你的域名（同樣透過 DNS 記錄證明域名屬於你），之後就能透過它的 API，以任何該域名下的地址寄信。因為信是從 Resend 管理的基礎設施出去的，它替你扛了伺服器信譽、SPF、DKIM 這些發信端的雜事。在免費額度內，這條發信通道對個人用途而言相當夠用。

於是整套流程變成：別人寄信給你的域名地址，Cloudflare 收下、轉進你的 Gmail；你想回信時，不是按 Gmail 的回覆鍵，而是透過 Resend 用域名地址把信寄回去。對方全程只看到你的域名地址，兩條路徑在使用者體驗上被縫合成一個正常的信箱。

縫合兩條路徑的那個瀏覽器擴充功能

縫合需要工具。每次回信都要開 API 文件、手動貼收件人與引文，這體驗顯然撐不了幾天。作者為此寫了 Chrome 擴充功能 Resend Mail Assistant，它能讀取目前網頁上的郵件內容，然後透過 Resend 以域名地址完成回覆。換句話說，你在 Gmail 網頁版看到轉發過來的信，按一下擴充功能，回信就從域名地址發出。

這個小工具填補的缺口很精確：Cloudflare 和 Resend 各自的免費方案，都沒有提供一個「以域名地址為主體的收件介面」。整個方案本質上是郵件轉發加 API 發信，沒有獨立的信箱後臺。擴充功能讓你在既有的 Gmail 介面裡完成最後一步，不需要學新介面，也不需要切換分頁。

這套方案適合誰，不適合誰

判斷的標準其實很清楚。適合的情境是：信量不大、以收為主、偶爾回覆的個人用途。個人網站的聯絡信箱、開源專案的支援地址、接案時想看起來專業一點的對外窗口，都屬於這類。Cloudflare Email Routing 免費，Resend 有免費額度，域名本身一年幾百塊，除此之外沒有固定開銷。

相對地，需要完整信箱功能的場景就不合適了。沒有獨立後臺意味著你依賴 Gmail 或 Outlook 的介面做事，儲存空間、搜尋、標籤全都在那裡；一旦哪天 Google 帳號出狀況，你的域名信箱也跟著失能。團隊協作、需要多個真人帳號各自登入收發的場景，正規的付費企業郵箱仍然有其不可取代性。這不是成本問題，是架構問題。

還有一點是資安與依賴面的考量。這套方案把信任分散在三家服務上：Cloudflare 管你的 DNS 和收信轉發，Resend 拿著你的發信授權，擴充功能則有權讀取你網頁上的郵件內容。任何一環的帳號被入侵，影響都會傳導到整條鏈。安裝第三方擴充功能前，確認它的原始碼是否公開、權限請求是否合理，是基本動作。作者把整套流程寫成部落格公開分享，這種透明度本身就是篩選訊號之一。

個人基礎建設的零成本邏輯

這篇分享之所以在社羣裡引起共鳴，反映的趨勢是：個人開發者能動用的免費基礎設施，已經覆蓋到過去需要付費或專業知識的領域。DNS、CDN、郵件轉發、API 發信，每一項單獨看都是小工具，組合起來卻能拼出一個功能完整的對外門面。域名是唯一真正屬於你的資產，其餘服務都可以替換，這也是為什麼把域名放在可攜的 DNS 服務上，值得優先投資心思。

對想動手試的讀者，順序建議照原分享走：先確認域名 DNS 已託管 Cloudflare，檢查現有 MX 記錄避免衝突，開啟 Email Routing 並驗證目標信箱，建立路由規則，測試收信通暢後，再進 Resend 驗證發信域名。每一步完成後都發一封測試信確認，問題會好找得多。零成本不等於零責任，DNS 上的每筆記錄都值得知道它為什麼存在，這套方案正好是一份入門教材。