會員收不到系統信？我們在自己的平台上踩過的寄件信任工程

為什麼 200 OK 卻收不到信

第一個要打破的迷思，是把「寄件 API 回傳成功」誤當成「使用者收到信」。這兩件事之間，隔著至少四道完全不受你程式碼控制的關卡。

當你呼叫 Resend、SendGrid、SES 或任何寄信服務的 API，得到一個 200 或一個 message ID，這只代表一件事：你的請求被寄件服務接受了。信件接下來會排隊、交給寄件服務的 MTA（郵件傳輸代理）、由它連線到收件方的伺服器（Gmail、Outlook、企業自架 mail server）、收件方做反垃圾與信任判斷、最後才決定要放進收件匣、垃圾桶，或是直接靜默丟棄。

關鍵在於：收件方的判斷發生在你的日誌之後。你的系統永遠看不到「Gmail 把這封信歸類為垃圾郵件」這件事，除非你主動去讀寄件服務回報的 bounce 與 complaint 事件。所以當客服收到「我沒收到信」的回報、而你的日誌一片綠燈時，請先假設問題出在送達層，而不是去翻你的應用程式碼。

我們在自己的平台上第一次遇到這件事的時候，也走了冤枉路——先去檢查呼叫寄信的那段邏輯有沒有寫錯、參數有沒有帶對、模板有沒有渲染失敗。全都正常。真正的兇手，是寄件網域本身。

沙箱寄件網域：最隱形的陷阱

這是我最想優先警告所有正在用寄信服務的人的一個坑，因為它「看起來完全正常」，卻會讓你的會員系統性地收不到信。

幾乎每一家寄信服務，都會給你一個「沙箱」或「測試」用的寄件網域，方便你在還沒設定自己的網域時就能跑通流程。以我們用的服務來說，那個沙箱寄件位址長得像 onboarding@resend.dev 這種樣子。它寄得出去、API 回 200、你自己測試時也收得到信——於是你以為一切就緒，上線了。

問題是：這類沙箱網域通常只允許寄信給「你自己的帳號」，寄給其他任何人都會被靜默攔下。你在開發時用自己的信箱測，當然每次都收得到，於是這個限制完全藏在你的視線之外。等到真實會員註冊、要收驗證信時，信根本送不出去，而你的日誌依然顯示成功。

我們在自己的平台上實際遇到的，正是這個情境：會員靜默收不到系統信，後端卻毫無錯誤。修法也很明確——把寄件網域從沙箱的 .dev 測試域，換成我們自己擁有、且完成驗證的正式子網域（我們用的是 send. 開頭的子網域）。換完之後，信才真正開始送進一般收件人的信箱。

如果你現在的系統還在用寄信服務預設的 .dev 或 sandbox 寄件位址，請立刻停下來檢查——這很可能就是你的會員收不到信的唯一原因，而它不會在任何日誌裡留下痕跡。

另一個藏在沙箱背後的限制是「網域額度」。許多寄信服務的免費方案只允許驗證一個寄件網域。我們在做多語系站點時就撞到這件事：英文站想用獨立的寄件網域，但免費額度已經被主網域用掉了，於是只能先讓英文站的系統信暫時共用同一個已驗證的網域，等之後再決定要不要升級付費方案換取第二個網域名額。這不是技術問題，是方案額度問題——但如果你沒意識到，就會在「為什麼新站寄不出信」上卡很久。

SPF、DKIM、DMARC：信任的三根柱子

要讓收件伺服器相信「這封信真的是從這個網域寄出的、而且沒被竄改」，你需要在 DNS 設定三組記錄。它們是現代寄件信任的地基，缺一不可。

SPF：誰有資格用我的網域寄信

SPF（Sender Policy Framework）是一條 DNS TXT 記錄，列出「哪些伺服器有權代表我的網域寄信」。當 Gmail 收到一封聲稱來自 truelink-group.com 的信，它會去查這個網域的 SPF 記錄，看看實際寄出這封信的伺服器 IP 在不在許可名單裡。在名單裡，這封信就通過 SPF 檢查；不在，就是一個負面信號。

當你用第三方寄信服務時，你需要把該服務的寄件主機納入你的 SPF。常見的陷阱是 SPF 記錄的「DNS 查詢次數上限為 10 次」——如果你串了太多服務、各自用 include: 疊加，很容易超過上限導致整條 SPF 失效。

DKIM：信沒有被竄改的數位簽章

DKIM（DomainKeys Identified Mail）是用一對公私鑰，對每一封寄出的信做數位簽章。私鑰由寄信服務保管、用來簽信；公鑰你發佈在 DNS 裡。收件方用公鑰驗證簽章，確認這封信在傳輸途中沒有被竄改、而且確實由授權方簽出。設定方式通常是寄信服務給你一段 CNAME 或 TXT 記錄，貼進你的 DNS 即可。

DMARC：當 SPF/DKIM 失敗時該怎麼辦

DMARC（Domain-based Message Authentication, Reporting & Conformance）是上層政策。它告訴收件方：「如果一封冒用我網域的信沒通過 SPF 和 DKIM，你該怎麼處理？」——是放行（p=none，只觀察）、丟進垃圾桶（p=quarantine），還是直接拒收（p=reject）。DMARC 還能要求收件方把驗證報告回傳給你，讓你看見有誰在冒用你的網域寄信。

三者的關係是：SPF 和 DKIM 負責「證明這封信是真的」，DMARC 負責「定義假信該怎麼處置、並回報狀況」。對 SME 來說，建議從 p=none 開始觀察一段時間，確認自己所有合法的寄信來源都通過驗證後，再逐步收緊到 quarantine 與 reject。一上來就 reject 而漏設了某個合法寄件來源，會把自己的正常信也擋掉。

用獨立子網域寄系統信

一個我認為被嚴重低估的最佳實務：不要用你的主網域直接寄系統信，而是用一個專屬的子網域。我們在自己平台上的做法，就是用 send.truelink-group.com 這樣的子網域來寄交易型系統信。

為什麼要分離？因為「網域聲譽」是會被牽連的。如果你用主網域（也就是員工日常收發、業務往來、行銷電子報全都混在一起的那個網域）去寄大量系統信，一旦其中某類信件觸發了大量的垃圾郵件檢舉或退信，整個主網域的聲譽都會受損——連你的業務同事寄給客戶的一對一信件都可能跟著進垃圾桶。

把系統信隔離到專屬子網域，好處有三個：

• 聲譽隔離：交易信的聲譽問題不會波及主網域的日常通訊。
• 可獨立監控：你可以單獨追蹤這個子網域的送達率、退信率、檢舉率，問題定位更精準。
• 分類更清楚：可以再進一步用不同子網域區分「交易信」（驗證碼、密碼重設、訂單通知這類使用者期待收到的信）與「行銷信」（電子報、促銷），因為這兩類信的聲譽模型完全不同，混在一起寄是大忌。

子網域同樣需要各自完成 SPF、DKIM、DMARC 的設定與驗證。在多語系或多品牌的情境下，這件事會變得更複雜——這也是前面提到的「免費方案網域額度」會卡住你的地方。

網域聲譽與暖機

收件伺服器對寄件網域與寄件 IP 都維持一份「聲譽分數」，這份分數會隨著你的寄信行為持續變動。一個全新的網域或 IP，聲譽是中性偏謹慎的——收件方不認識你，所以會用比較保守的態度對待你的信。

這就帶出「暖機（warm-up）」的概念。如果你的網域過去沒怎麼寄過信，然後某天突然爆量寄出幾千封系統信，這個流量模式本身就很像垃圾郵件發送者的行為，很容易觸發過濾。比較安全的做法是讓寄信量逐步爬升，給收件方時間建立「這是一個正常、穩定的寄件者」的印象。

對大多數 SME 來說，系統信的量通常是隨著真實業務自然成長的，所以這件事不一定需要刻意操作。但有兩個情境要特別注意：一是剛切換到新的寄件網域時（就像我們從沙箱換到正式子網域的那次），二是做大型會員名單匯入或一次性大量通知時。這兩種情況都會製造突發的流量尖峰，值得分批、分時段送出。

聲譽的另一面是「退信管理」。如果你持續寄信給不存在的信箱、或是早就失效的地址，高退信率會直接拖垮你的聲譽。寄信服務通常會回報 hard bounce（永久失效）與 soft bounce（暫時性失敗）事件——你必須真的去處理這些事件，把 hard bounce 的地址從名單裡移除，而不是放著不管繼續寄。

內容與互動也會決定送達率

就算你的 SPF、DKIM、DMARC 全部設定正確、網域聲譽也良好，信件內容本身仍然會影響它落在收件匣還是垃圾桶。現代的反垃圾系統不只看技術驗證，也看內容信號與使用者互動。

幾個我看過實際造成差別的因素：

• 純圖片、零文字的信：一封信如果幾乎全是圖片、沒有實質的文字內容，會被過濾系統視為可疑。系統信裡的文字要有真實意義。
• 連結與顯示文字不一致：顯示的是一個網址、實際連到另一個網址，這是典型的釣魚信特徵，會被重罰。
• 夾帶縮網址或可疑網域：交易信裡盡量用你自己網域下的連結，少用第三方縮網址。
• 缺少退訂機制：行銷類信件若沒有清楚的退訂方式，會被視為不合規。交易信雖然性質不同，但整體合規姿態仍然影響網域評價。

更深一層的是「使用者互動信號」。當收件人打開你的信、回信、把你從垃圾桶移到收件匣、或把你加入聯絡人，這些都是強烈的正面信號，會讓收件方更願意把你之後的信放進收件匣。反過來，如果大量收件人直接刪除、或按「檢舉垃圾郵件」，你的聲譽會快速下滑。

這就是為什麼「只寄使用者真正期待收到的信」這麼重要。系統信之所以送達率通常比行銷信高，正是因為使用者剛剛做了一個動作（註冊、下單、要求重設密碼）、正在等這封信——這種高互動、被期待的信，本質上就是收件方眼中的好信。

收不到信的診斷清單

把前面所有的教訓濃縮成一份可以照著走的排查順序。當你接到「會員收不到信」的回報時，依序檢查：

1. 確認寄件網域不是沙箱／測試域。如果寄件位址還是 @something.dev 或服務預設的測試域，幾乎可以直接確定問題在這。換成你自己擁有並驗證過的網域。
2. 去寄信服務後台讀真實的事件，不要只看你自己的應用程式日誌。看每一封信的狀態：是 delivered、bounced、deferred，還是 spam complaint？真相在這裡，不在你的程式碼裡。
3. 用線上工具檢查 SPF、DKIM、DMARC 三條記錄是否都存在且正確、SPF 的 DNS 查詢次數有沒有超過 10 次上限。
4. 檢查退信與檢舉率。是不是在寄給一堆失效信箱？是不是某類信被大量檢舉？
5. 請回報問題的會員去翻垃圾桶。如果信在垃圾桶，那就是送達率問題（聲譽或內容），不是「沒寄出」的問題，排查方向完全不同。
6. 確認沒有近期的流量尖峰。是不是剛換網域、剛做大量匯入，觸發了保守過濾？

這份清單的精神是：從最外層（網域與信任）往內查，而不是一開始就鑽進程式碼。我們自己繞的冤枉路，就是因為一開始的方向反了。

送達率是信任工程的一環

我把這篇文章放在「信任工程」這個主題下，是因為系統信送達率和我們在做的其他事情——KYC 身分驗證、結構化資料（Schema）、內容真實性憑證——其實是同一件事的不同面向：讓機器（無論是收件伺服器、搜尋引擎還是 AI 爬蟲）有辦法驗證「你是你說的那個你」。

SPF、DKIM、DMARC 本質上就是「網域身分的密碼學驗證」。它和你在網站上佈署 Schema 結構化資料讓搜尋引擎理解你是誰、和你用 KYC 驗證一個會員的真實身分，是完全同構的問題。每一個都是在一個預設互不信任的環境裡，建立「可被機器驗證的信任」。

對 SME 創辦人和 CMO 來說，這帶來一個很實際的心態轉變：送達率不是 IT 部門事後補救的雜務，而是你品牌可信度的一部分。一個會員連你的驗證信都收不到的品牌，無論前端做得多漂亮，在那個關鍵時刻就已經失去了信任。把寄件信任工程做對，是你對「我們是一家認真、可被驗證的公司」這件事最低成本、卻最容易被忽略的證明。

這些不是理論。這是我們在自己的正式環境裡，一個坑一個坑踩出來、修起來的真實經驗——從沙箱網域的靜默失敗，到切換正式子網域，到多語系站點的網域額度限制。如果你正在被「會員收不到信」困擾，希望這篇文章能讓你少走我們走過的彎路。