# 電子報要自建還是外包？我用 Claude 走過一輪決策，最後選了 Resend > paulkuo.tw 電子報從決策到上線的完整記錄：為什麼跳過 Substack 和全自建，怎麼在 Cloudflare Email Service、AWS SES、Buttondown、Resend 四個候選者之間選出 Resend，以及後來怎麼用同一套架構加開信率追蹤，不用等平台開放新功能。 - Author: Paul Kuo（郭曜郎） - Date: 2026-07-11 - Pillar: 創造與建構 / Creation & Enterprise - Tags: 電子報, Resend, Cloudflare Workers, 半自建架構, AI協作, 技術決策框架, D1 - Canonical: https://paulkuo.tw/articles/newsletter-half-self-built-resend/ - Site index for LLMs: https://paulkuo.tw/llms.txt --- > **TL;DR** — paulkuo.tw 要做電子報時，我一開始只想知道：該自己架，還是直接用 Substack？跟 Claude 討論一輪後，最後採用的是「半自建」：訂閱名單和流程留在自己手上，寄信則交給 Resend。最近，我又在原來的架構上加了開信追蹤。這次經驗讓我發現，半自建的好處不只是在當下省事，也讓之後想加功能時，不必等平台替你決定。
▶ 聽摘要
AI 合成語音・作者本人聲線克隆
「如果網站要有電子報，建議自建立，還是用市場上現成的服務，例如 Substack？」 這是我問 Claude 的原話。當時 paulkuo.tw 已經有一套固定運作的網站後台，因此再加一份訂閱名單，技術上並不困難，成本也很低。但「技術上不難」跟「該不該做、該怎麼做」是兩件事。我想先把架構想清楚，再決定要不要動手。 ## Substack 很方便，但不符合這次的條件 Substack 的優勢很明確：它有自己的推薦網路，對剛開始經營電子報的人來說，可能更容易找到第一批讀者。不過，若開始收費，它會抽取 10% 的訂閱營收，另外還有金流費用；版面和讀者互動，也會逐漸留在 Substack 的 app 與 Notes 系統裡。 對很多人來說，這些交換可能很划算。但對 paulkuo.tw 而言，我更在意的是讀者名單能不能留在自己手上，以及未來能不能自由調整網站和寄送流程。 如果網站、內容和網域都自己管理，唯獨把訂閱關係放在另一個平台上，整套架構就會留下明顯的依賴。除非我很需要 Substack 帶來的初期流量，否則這筆交換對我並不划算。 但跳過 Substack，不代表就該全部自己來。 ## 半自建是什麼意思？ 全自建真正麻煩的，不只是把寄信程式寫出來，而是如何讓信穩定送進收件匣。寄件網域要驗證（例如 SPF、DKIM、DMARC）、退信和垃圾信投訴要處理，寄送紀錄一旦不好，整批信都有可能被丟進垃圾桶。這些已經是專門的服務商長期處理的問題，自己從頭搭，未必比較省事。 想成物流會比較清楚。全用現成服務像進駐百貨專櫃，什麼都幫你打理好，但客人名單是百貨的。全自建像自己蓋一棟樓，連水電管線都自己拉，最自由也最累。半自建則是自己管客人名單和營運，但貨要怎麼送到客人手上，交給黑貓宅急便，不自己養車隊。 ![半自建架構切分圖：左側自己握有訂閱名單、表單與寄送判斷邏輯，右側外包 SPF/DKIM/DMARC 網域驗證與退信投訴監控給 Resend。](/images/articles/newsletter-half-self-built-resend-architecture-split.svg) 具體切法：自己握訂閱名單、訂閱表單、和「有新文章就寄」的判斷邏輯；外包出去的是把信真的送進對方信箱這件事。架構定調之後，問題縮小成一個：外包的寄送這一層，該找誰。 ## 四個候選服務，我怎麼一路刪到剩 Resend ![電子報寄送服務決策流程圖：Substack 因抽成與名單去留問題淘汰，全自建因送達維護負擔淘汰，半自建架構定調後比較四個候選服務，Cloudflare Email Service、Buttondown、AWS SES 依序淘汰，最終選定 Resend。](/images/articles/newsletter-half-self-built-resend-decision-flow.svg) 比較過程中列出四個候選者，各自的優缺點都攤開比較，不是拍腦袋選一個： | 候選者 | 優點 | 缺點 / 顧慮 | 結果 | |--------|------|------------|------| | [Cloudflare Email Service](https://developers.cloudflare.com/email-service/) | 全 CF 生態原生、Workers 直接整合、每月含 3,000 封起 | 2026 年才公測，目前只支援交易通知信，例如註冊確認、訂單通知，還不支援一次寄給大量訂閱者的電子報 | 一度是首選，查證後排除 | | AWS SES | 業界最便宜，這種量幾乎免費 | 寄送名單、退信和垃圾信投訴都要自己處理，後續維護工作最多 | 保留到最後一輪比較 | | [Buttondown](https://buttondown.com/pricing) | 最輕、markdown 友善，連名單管理都幫你做，免費層 100 訂閱 | 超過免費層約 9 美元一個月起，它連名單管理都包辦了，雖然方便，但和我想把名單留在自己手上的方向不同 | 半自建定調後淘汰 | | [Resend](https://resend.com/pricing) | 現成 broadcast、退訂 API，幫你扛退信和投訴管理，現成功能較完整，需要自己補的部分最少，免費層每月 3,000 封、每天 100 封 | 早期印象是「訂閱數一大就變貴」 | 最終勝出 | 值得一提：Cloudflare Email Service 一度是最順手的選擇，全 CF 生態、Workers 原生，看起來天作之合。但寫實作計畫前先去查了官方文件，才發現它現階段只收交易通知信，電子報這種一次寄給整個名單的寄送方式不在支援範圍內。這也成了我這次跟 Claude 討論時很有意思的一個轉折。表面上最合適的選項，查過官方文件後反而第一個被排除。對我來說，Claude 在這裡不只是幫忙列選項，更重要的是陪我把每個假設逐一查清楚，再重新調整方向。 ## 最後一題：省寄信費，還是省維護時間？ 最後只剩 Resend 和 AWS SES。兩者的差別其實很直接：SES 的寄信費用更低，但許多電子報需要的功能都要自己補；Resend 費用稍高一些，不過群發、退訂、退信與投訴處理已經準備得比較完整。 以個人網站目前的訂閱量來看，兩邊的實際費用差異不大，真正有差的是我還要投入多少時間維護。最後我選擇把時間留給寫文章，因此用了 Resend。 定案之後還有兩個追加決策，是半自建精神真正落地的地方。 第一個是訂閱名單要放在哪裡。一開始，我原本想直接使用 Resend 的名單管理功能，後來還是決定把資料留在自己的 Cloudflare D1，讓 Resend 只負責寄信。這樣即使未來更換寄送服務，訂閱資料也不需要跟著搬家。 第二個決定和寄件地址有關。比較理想的做法，是另外使用一個子網域寄送電子報，把網站本身和電子報的寄送紀錄分開。不過，這需要升級付費方案。考量目前的規模，我最後先沿用已驗證的主網域，使用 `news@paulkuo.tw` 寄信。這不是最標準的架構，但在目前的成本和使用量之間，對我來說已經足夠。 系統在 2026 年 6 月底上線。我從訂閱、收確認信、點擊確認到最後退訂，完整走過一次流程。確認信有正常進入收件匣，資料庫狀態也會跟著更新，自動化測試全部通過。上線後，我的程式碼平台帳號曾意外被停權，但網站和電子報仍正常運作。這也意外驗證了：部署流程沒有綁在單一平台上。這段經歷值得另外寫一篇，這裡暫時略過。 ## 寄出去之後，我開始想知道有沒有人打開 系統穩定運作一段時間後，回頭問了一個問題：這些訂閱者到底有沒有在看？一般電子報平台通常已經提供開信率，但在這套半自建架構裡，我得自己決定要不要追蹤、怎麼保存，以及最後要把資料放在哪裡看。好處是，名單和寄送紀錄都在自己手上，未來想怎麼使用，不需要受限於平台現有的介面。 答案一開始是查不到。Resend 本身有開信、點擊追蹤的能力，但預設沒開，開了之後也不會主動把事件回報給你。 做法並不複雜。先開啟 Resend 的追蹤功能，再建立一個接收通知的網址。之後只要有人開信、點擊連結，或信件發生退信、投訴，Resend 就會把事件送回我的系統。這種由服務主動通知另一個系統的方式，通常稱為 webhook。 為了避免有人假冒 Resend 傳資料，系統還會驗證每次通知附帶的數位簽章。最後，我新增兩張資料表：一張記錄信寄給了誰，另一張記錄信件後續發生的事件。整個機制不需要額外裝套件，瀏覽器和伺服器都內建的加密函式庫就能驗證簽章。 ![開信率查詢機制流程圖：Resend 觸發開信事件，經 webhook POST 送出，Svix 簽章驗證通過後寫回 Cloudflare D1 的兩張新表，累積後即可查得開信率。](/images/articles/newsletter-half-self-built-resend-webhook-flow.svg) 目前這個追蹤管道已經上線，安全驗證也測試完成。沒有合法簽章的請求，系統會直接拒絕。因為是剛接上的追蹤，還沒有累積到一次完整的開信事件，開信率目前誠實顯示「尚無資料」，而不是造假的 0%。這個資料還沒進來、但管道已經接好的誠實狀態，本身就是半自建架構的具體證明：想加什麼功能，隨時可以加，不用等別人開放。 接下來，我還可以把這些資料放進自己的後台，也可以接到其他分析工具，甚至只在需要時透過 API 查詢。目前我還沒有急著決定，先讓資料累積一段時間再說。 這套電子報系統上線後，我才慢慢看見下一個問題。先是寄得出去，接著是能不能退訂，後來又想知道讀者有沒有打開。功能不是一開始就全部規劃好的，而是在實際使用之後，一點一點長出來。 對我來說，這大概就是半自建最實際的好處：現在不用把所有事情都做完，但以後想往前走時，手上還留有調整的空間。