電子報要自建還是外包？我用 Claude 走過一輪決策，最後選了 Resend

TL;DR — paulkuo.tw 要做電子報時，我一開始只想知道：該自己架，還是直接用 Substack？跟 Claude 討論一輪後，最後採用的是「半自建」：訂閱名單和流程留在自己手上，寄信則交給 Resend。最近，我又在原來的架構上加了開信追蹤。這次經驗讓我發現，半自建的好處不只是在當下省事，也讓之後想加功能時，不必等平台替你決定。

「如果網站要有電子報，建議自建立，還是用市場上現成的服務，例如 Substack？」

這是我問 Claude 的原話。當時 paulkuo.tw 已經有一套固定運作的網站後台，因此再加一份訂閱名單，技術上並不困難，成本也很低。但「技術上不難」跟「該不該做、該怎麼做」是兩件事。我想先把架構想清楚，再決定要不要動手。

Substack 很方便，但不符合這次的條件

Substack 的優勢很明確：它有自己的推薦網路，對剛開始經營電子報的人來說，可能更容易找到第一批讀者。不過，若開始收費，它會抽取 10% 的訂閱營收，另外還有金流費用；版面和讀者互動，也會逐漸留在 Substack 的 app 與 Notes 系統裡。

對很多人來說，這些交換可能很划算。但對 paulkuo.tw 而言，我更在意的是讀者名單能不能留在自己手上，以及未來能不能自由調整網站和寄送流程。

如果網站、內容和網域都自己管理，唯獨把訂閱關係放在另一個平台上，整套架構就會留下明顯的依賴。除非我很需要 Substack 帶來的初期流量，否則這筆交換對我並不划算。

但跳過 Substack，不代表就該全部自己來。

半自建是什麼意思？

全自建真正麻煩的，不只是把寄信程式寫出來，而是如何讓信穩定送進收件匣。寄件網域要驗證（例如 SPF、DKIM、DMARC）、退信和垃圾信投訴要處理，寄送紀錄一旦不好，整批信都有可能被丟進垃圾桶。這些已經是專門的服務商長期處理的問題，自己從頭搭，未必比較省事。

想成物流會比較清楚。全用現成服務像進駐百貨專櫃，什麼都幫你打理好，但客人名單是百貨的。全自建像自己蓋一棟樓，連水電管線都自己拉，最自由也最累。半自建則是自己管客人名單和營運，但貨要怎麼送到客人手上，交給黑貓宅急便，不自己養車隊。

具體切法：自己握訂閱名單、訂閱表單、和「有新文章就寄」的判斷邏輯；外包出去的是把信真的送進對方信箱這件事。架構定調之後，問題縮小成一個：外包的寄送這一層，該找誰。

四個候選服務，我怎麼一路刪到剩 Resend

比較過程中列出四個候選者，各自的優缺點都攤開比較，不是拍腦袋選一個：

值得一提：Cloudflare Email Service 一度是最順手的選擇，全 CF 生態、Workers 原生，看起來天作之合。但寫實作計畫前先去查了官方文件，才發現它現階段只收交易通知信，電子報這種一次寄給整個名單的寄送方式不在支援範圍內。這也成了我這次跟 Claude 討論時很有意思的一個轉折。表面上最合適的選項，查過官方文件後反而第一個被排除。對我來說，Claude 在這裡不只是幫忙列選項，更重要的是陪我把每個假設逐一查清楚，再重新調整方向。

最後一題：省寄信費，還是省維護時間？

最後只剩 Resend 和 AWS SES。兩者的差別其實很直接：SES 的寄信費用更低，但許多電子報需要的功能都要自己補；Resend 費用稍高一些，不過群發、退訂、退信與投訴處理已經準備得比較完整。

以個人網站目前的訂閱量來看，兩邊的實際費用差異不大，真正有差的是我還要投入多少時間維護。最後我選擇把時間留給寫文章，因此用了 Resend。

定案之後還有兩個追加決策，是半自建精神真正落地的地方。

第一個是訂閱名單要放在哪裡。一開始，我原本想直接使用 Resend 的名單管理功能，後來還是決定把資料留在自己的 Cloudflare D1，讓 Resend 只負責寄信。這樣即使未來更換寄送服務，訂閱資料也不需要跟著搬家。

第二個決定和寄件地址有關。比較理想的做法，是另外使用一個子網域寄送電子報，把網站本身和電子報的寄送紀錄分開。不過，這需要升級付費方案。考量目前的規模，我最後先沿用已驗證的主網域，使用 [email protected] 寄信。這不是最標準的架構，但在目前的成本和使用量之間，對我來說已經足夠。

系統在 2026 年 6 月底上線。我從訂閱、收確認信、點擊確認到最後退訂，完整走過一次流程。確認信有正常進入收件匣，資料庫狀態也會跟著更新，自動化測試全部通過。上線後，我的程式碼平台帳號曾意外被停權，但網站和電子報仍正常運作。這也意外驗證了：部署流程沒有綁在單一平台上。這段經歷值得另外寫一篇，這裡暫時略過。

寄出去之後，我開始想知道有沒有人打開

系統穩定運作一段時間後，回頭問了一個問題：這些訂閱者到底有沒有在看？一般電子報平台通常已經提供開信率，但在這套半自建架構裡，我得自己決定要不要追蹤、怎麼保存，以及最後要把資料放在哪裡看。好處是，名單和寄送紀錄都在自己手上，未來想怎麼使用，不需要受限於平台現有的介面。

答案一開始是查不到。Resend 本身有開信、點擊追蹤的能力，但預設沒開，開了之後也不會主動把事件回報給你。

做法並不複雜。先開啟 Resend 的追蹤功能，再建立一個接收通知的網址。之後只要有人開信、點擊連結，或信件發生退信、投訴，Resend 就會把事件送回我的系統。這種由服務主動通知另一個系統的方式，通常稱為 webhook。

為了避免有人假冒 Resend 傳資料，系統還會驗證每次通知附帶的數位簽章。最後，我新增兩張資料表：一張記錄信寄給了誰，另一張記錄信件後續發生的事件。整個機制不需要額外裝套件，瀏覽器和伺服器都內建的加密函式庫就能驗證簽章。

目前這個追蹤管道已經上線，安全驗證也測試完成。沒有合法簽章的請求，系統會直接拒絕。因為是剛接上的追蹤，還沒有累積到一次完整的開信事件，開信率目前誠實顯示「尚無資料」，而不是造假的 0%。這個資料還沒進來、但管道已經接好的誠實狀態，本身就是半自建架構的具體證明：想加什麼功能，隨時可以加，不用等別人開放。

接下來，我還可以把這些資料放進自己的後台，也可以接到其他分析工具，甚至只在需要時透過 API 查詢。目前我還沒有急著決定，先讓資料累積一段時間再說。

這套電子報系統上線後，我才慢慢看見下一個問題。先是寄得出去，接著是能不能退訂，後來又想知道讀者有沒有打開。功能不是一開始就全部規劃好的，而是在實際使用之後，一點一點長出來。

對我來說，這大概就是半自建最實際的好處：現在不用把所有事情都做完，但以後想往前走時，手上還留有調整的空間。