Resend 是什麼？SMTP、API、電子報與 WordPress 寄信完整指南

如果你第一次看到 Resend，很容易把它理解成「另一個 SMTP 寄信服務」。這個理解不算錯，但已經不夠完整。

Resend 一開始最受注意的是開發者友善的 Email API，但到 2026 年，它已經不只處理密碼重設、訂單通知這類交易信，也提供 Contacts、Audiences、Broadcasts、行銷 Email、自動退訂、開信與點擊追蹤、Webhooks、Automation 與收信功能。

對一般網站經營者來說，真正值得理解的是：Resend 可以只當「寄信引擎」，也可以成為你整套 Email 系統的一部分。兩種用法需要的架構完全不同。

如果你目前只是 WordPress 表單、WooCommerce 訂單信、會員通知寄不出去，可以先看WordPress 寄信 SMTP 外掛 FluentSMTP，先理解網站寄信和真正 Email 行銷的差別。

Resend 是什麼？它不是只有 SMTP

Resend 的定位可以簡單理解成「Email 基礎設施＋Email 行銷能力」。網站或應用程式可以透過 API 或 SMTP 把信交給 Resend，再由 Resend 處理實際寄送、退信、投遞狀態與部分寄信信譽相關工作。

目前 Resend 官方把常見用途分成四大類：

用途	典型情境	Resend 主要工具
交易型 Email	密碼重設、訂單通知、收據、註冊確認	Email API、SMTP
行銷 Email	電子報、產品公告、促銷、內容更新	Broadcasts、Contacts、Audiences
收信	把收到的 Email 交給系統處理	Inbound、Webhooks
自動化	歡迎序列、購物車提醒、滴灌流程	Automations、Events、Contacts

所以 Resend 不是「只有工程師才能用」，但它的核心思維仍然很偏開發者：你可以用現成介面，也可以把 Email 能力嵌進自己的網站、會員系統、課程平台或應用程式。

Resend 最重要的第一個觀念：交易信和行銷信要分開看

這是很多網站經營者最容易混淆的地方。

交易型 Email通常是因為使用者先做了某個動作，系統才寄出一封必要通知。例如：

• 會員註冊驗證。
• 忘記密碼。
• WooCommerce 訂單通知。
• 付款完成信。
• 課程報名成功信。
• 系統安全通知。

行銷 Email則是一對多寄送，例如：

• 每週電子報。
• 新文章通知。
• 新品或新課程公告。
• 促銷活動。
• 內容更新與品牌培養。

Resend 官方目前也把這兩種產品分開計價與管理：交易信主要看寄送量；行銷信則更重視 Contacts 與 Broadcasts。這也是為什麼你不能只看到「有 SMTP」就直接把 Resend 等同於完整電子報平台。

Resend 可以怎麼用在 WordPress？最常見有 3 種架構

用法 1：只把 Resend 當 WordPress SMTP 寄信服務

這是最簡單的用法。WordPress 仍然由原本外掛與系統產生 Email，FluentSMTP 或其他 SMTP 外掛負責把信交給 Resend。

Resend 官方目前提供 SMTP Relay，常用設定如下：

SMTP Host	smtp.resend.com
建議 Port	465
Username	resend
Password	Resend API Key
加密	SSL／TLS

這種架構適合處理 WordPress 系統通知、表單通知、會員信與 WooCommerce 交易通知。對網站管理者來說，優點是不用自己維護郵件伺服器。

用法 2：Resend 管理 Contacts，直接用 Broadcasts 寄電子報

如果你要的是電子報，不一定要再加一套 WordPress 電子報外掛。Resend 本身已經有 Contacts、Audiences、Broadcasts、視覺化編輯、Markdown、排程、個人化變數、開信／點擊追蹤與退訂處理。

這時候流程會變成：

訂閱表單 → Resend Contacts／Audience → Broadcasts → 收件者。

這種做法的優點是整體比較簡單，名單與寄送都在同一個平台；缺點則是你的聯絡人資料會更依賴 Resend 本身。

用法 3：名單留在自己手上，Resend 只負責寄送

這也是你提供的參考文章最值得延伸的地方：名單、表單、標籤與商業邏輯自己掌握，Email 投遞交給 Resend。

例如名單可以放在：

• WordPress＋FluentCRM。
• 自建資料庫。
• 會員／課程系統自己的顧客資料。
• 其他 CRM，再透過 API 同步。

這種「半自建」的好處，是未來想換寄信供應商時，核心聯絡人資料不一定要跟著搬家；但代價是你自己要處理更多同步、退訂狀態、標籤與資料一致性。

如果你想了解 WordPress 把名單留在自己站內的做法，可以看FluentCRM 是什麼？WordPress 名單管理與電子報外掛介紹。

Resend 的免費方案到什麼程度？

截至 2026 年 10 月，Resend 的交易型 Email 免費方案是每月 3,000 封、每天最多 100 封，可使用 3 個網域；Pro 方案目前是每月 20 美元、50,000 封，Scale 方案目前是每月 90 美元、100,000 封。

行銷 Email 則是另一套邏輯。Resend 官方目前提供免費行銷方案，可管理最多 1,000 位 Contacts，Broadcasts 的計價重點是聯絡人數，而不是和交易信共用同一個寄送額度。

最容易搞錯的是：Broadcasts 寄出的行銷信，不會直接吃掉交易型 Email 的月寄送額度；兩者是不同產品邏輯。

價格會調整，因此實際採用前還是應以 Resend 官方 Pricing 頁為準。對小型網站來說，更值得先算的是「我要寄多少交易信、名單有多少人、要不要經營電子報」，而不是只看免費額度最大的是誰。

Resend 網域驗證在做什麼？SPF、DKIM、DMARC 不要跳過

如果你要用自己的品牌網域寄信，例如 moc.niamodruoyobfsctd-889734@rettelswen，就不能只建立一個寄件人名稱。你還需要在 DNS 加上 Resend 指定的驗證紀錄。

核心目的有三個：

• 證明你有權使用這個網域寄信。
• 讓 Gmail、Outlook 等收件服務能驗證信件來源。
• 降低偽造寄件人與投遞失敗的機率。

Resend 目前會提供 SPF、DKIM 等 DNS 設定，並支援 DMARC 相關驗證與自訂 Return Path。這些不是「做了就保證每封進收件匣」，但沒有正確網域驗證，大量寄信的穩定性與信譽管理會更困難。

主網域還是子網域寄信？小站和大規模名單的選擇不同

如果只是小型網站通知，直接用已驗證主網域通常比較簡單；如果未來電子報量很大，很多團隊會另外使用寄信子網域，例如 mail.example.com 或 news.example.com，把行銷寄信的聲譽和主網域的其他用途分開管理。

這不是每個新網站都必須第一天做到的事。比較合理的做法，是依寄送量、品牌數、交易信重要性與未來規模決定，不需要因為看到「最佳實務」就把架構一開始做得非常複雜。

Resend Broadcasts 可以做到哪些電子報功能？

Resend 現在的 Broadcasts 已經不是只有「API 群發」。你可以直接在後台建立行銷 Email，並使用：

• 視覺化內容編輯。
• Markdown。
• 個人化變數。
• 排程發送。
• 開信與點擊追蹤。
• Contacts／Segments。
• 退訂連結。
• Topics 訂閱偏好。
• API 建立、排程與寄送 Broadcast。

Resend 也會管理 Broadcast 的退訂狀態：聯絡人取消訂閱後，後續 Broadcast 會跳過該聯絡人。對真正經營電子報來說，這比「可以一次寄很多封」重要得多。

Resend 名單要放哪裡？其實有 3 種策略

策略	優點	代價
全部放 Resend	簡單、退訂與 Broadcast 整合完整	名單與寄送都依賴同一平台
WordPress CRM 為主	顧客、標籤、課程與網站資料可整合	要處理和 Resend 的同步方式
自建資料庫為主	資料控制與可移轉性最高	開發、同步、退訂與維護成本最高

沒有一種一定最好。如果你只是剛開始寄電子報，全部放 Resend 最簡單；如果網站本來就有 FluentCRM、WooCommerce、會員或課程資料，讓 WordPress 成為主要顧客資料來源可能更自然；如果你是 SaaS 或有工程團隊，自建資料層才更有意義。

Resend 可以取代 Brevo 嗎？先看你要的是「寄信」還是「CRM＋行銷平台」

這兩個工具有重疊，但產品思維不同。

比較	Resend	Brevo
核心出發點	開發者 Email 基礎設施	行銷、CRM 與 Email 平台
API／SMTP	強	有
交易型 Email	核心用途	支援
電子報	Broadcasts	Campaigns
名單	Contacts／Audiences	Contacts／CRM
適合自建系統	高	中高
非技術行銷團隊	可用，但思維偏技術	通常較直覺

如果你最重視 API、網站應用、交易信、自己掌握資料流程，Resend 很有吸引力；如果你要的是完整 CRM、Email 行銷與比較成熟的行銷工作流，Brevo 仍然有它的優勢。

你也可以延伸看Brevo 教學：SMTP、WordPress 與免費方案，再依自己的架構比較。

FluentCRM＋Resend 可不可以？先分清楚誰管理名單、誰負責送信

如果你已經使用 FluentCRM，理論上可以讓 WordPress 保留聯絡人、標籤、Automation 與 Campaign 邏輯，再把寄送交給外部服務。

但這裡要特別注意：Resend 官方把「交易型 Email」和「行銷 Email」分成不同產品路徑。Resend 官方也明確建議，如果要寄整個名單的電子報，應使用 Broadcasts，而不是把大量行銷信只當成一般交易信處理。

所以如果你打算把 FluentCRM＋Resend 組成主要電子報系統，要先設計清楚：

• 聯絡人主資料放哪裡。
• 退訂狀態誰是主來源。
• 標籤與 Segment 怎麼同步。
• 行銷 Campaign 是 FluentCRM 發，還是 Resend Broadcasts 發。
• 交易信是否獨立走 SMTP／API。

如果沒有先決定，最容易發生的是「WordPress 顯示已訂閱，Resend 顯示已退訂」或兩邊名單狀態不一致。半自建的自由度很高，但自由度越高，資料責任越要先講清楚。

WordPress 串 Resend，可以照這 6 步做

1. 建立 Resend 帳號：先決定要使用哪一個品牌網域寄信。
2. 加入並驗證網域：依 Resend 顯示的 DNS 紀錄完成 SPF、DKIM 等設定。
3. 建立 API Key：不要把主帳號密碼交給 WordPress，應使用專用 API Key。
4. 設定 FluentSMTP：使用 smtp.resend.com、Port 465、Username resend，Password 填 API Key。
5. 先寄測試信：確認測試 Email 能正常送達，而且寄件網域正確。
6. 再測真實流程：實際跑一次表單、會員註冊、WooCommerce 訂單或課程報名，不能只測「SMTP Test」成功。

最後一步很重要。SMTP 測試信成功，只能證明 WordPress 可以把一封信交給 Resend；真正營運時，還要確認 WooCommerce、會員、表單與課程外掛產生的 Email 都能正常送出。

寄得出去，不代表一定進收件匣：還要看這 7 個條件

• 網域驗證：SPF、DKIM 與寄件網域設定是否正確。
• 寄件人一致：不要一直用不同網域、不同 From Address 亂寄。
• 名單品質：不要寄給大量不存在、很久沒互動或來源不明的 Email。
• 退訂機制：行銷信要讓不想收到的人可以順利退訂。
• Bounce 與 Complaint：退信、垃圾郵件檢舉要持續觀察。
• 內容品質：主旨、網址、寄送頻率與收件者期待都會影響信譽。
• 寄送量成長：不要從幾十封突然跳到大量群發，尤其是全新網域。

Resend 可以幫你處理寄送基礎設施，但它不能替你保證每一封一定進主要收件匣。寄信信譽是「技術設定＋名單品質＋寄送行為」共同累積的結果。

API Key 要怎麼保護？不要直接貼在公開程式碼

Resend 的 API Key 本質上就是寄信權限。只要拿到有效 Key，就可能代表有人能使用你的帳號額度寄信，因此它不能出現在公開文章、GitHub 公開專案、前端 JavaScript 或任何使用者可以直接查看的地方。

• WordPress 後台只提供給必要管理者。
• API Key 不要透過公開訊息或文件分享。
• 不同網站最好使用不同 Key，出問題時比較容易停用。
• 如果懷疑外洩，直接撤銷舊 Key 並建立新的。
• 能限制權限或網域時，盡量使用較小權限。

這一點對幫客戶架站的人尤其重要：不要讓所有客戶共用同一組寄信 Key。網站、品牌與客戶之間的帳號界線越清楚，未來交接越安全。

Resend、Brevo、自己架 SMTP，怎麼快速選？

你的情況	比較適合	原因
WordPress 需要可靠交易信	Resend／Brevo 等外部寄信服務	不用自己維護郵件伺服器
開發者要 API、Webhooks、自建流程	Resend	開發工具與 API 架構完整
非技術團隊要 CRM＋電子報	Brevo 等完整行銷平台	介面與 CRM 工作流更集中
名單一定要留在 WordPress	FluentCRM＋外部寄信服務	資料與標籤留在自己的網站
想自己維護郵件伺服器	自架 SMTP	控制最大，但維護、信譽與安全成本最高

如果只是為了省每月幾美元就自己架 SMTP，通常低估了送達率、IP 信譽、退信與安全維護的成本。真正值得自架的情況，通常是你有明確技術需求與維運能力，而不是單純覺得「自己架免費」。

Resend 的優點：不是只有便宜，而是架構彈性高

• API 與 SMTP 都完整：網站、應用程式與 WordPress 都能找到整合方式。
• 交易信與行銷信同平台：不用一定拆成兩家公司。
• Contacts／Broadcasts 已成熟很多：不再只是 API 工具。
• 退信、投遞、Webhooks 比自架 SMTP 省事：不用自己造整套郵件基礎設施。
• 適合半自建架構：名單、網站與商業邏輯可以留在自己系統。
• 開發者體驗好：API、SDK、CLI、MCP 與文件都很完整。

Resend 的限制：不是每個人都需要這麼高的自由度

• 非技術使用者可能覺得太工程：很多價值建立在 API、Webhooks 與資料整合上。
• 不是傳統 CRM 優先產品：如果你最在意業務 Pipeline、完整 CRM 操作，其他平台可能更直覺。
• 半自建需要自己負責資料同步：自由不是免費的。
• 免費方案有每日寄送限制：小站夠用，但大量交易信要評估付費方案。
• 電子報功能正在快速進化：功能更新速度快，採用前要重新核對官方方案與限制。

Resend 適合哪些人？

• 有 WordPress／WooCommerce，需要可靠寄送系統通知的人。
• 有網站會員、課程、SaaS 或應用程式，要寄交易信的人。
• 希望名單留在自己 CRM／資料庫，寄送交給專業服務的人。
• 希望交易信與電子報未來可以整合在同一平台的人。
• 有工程能力，想用 API、Webhooks 或 Automations 建立更客製流程的人。

哪些人不一定要用 Resend？

• 只想登入後台、拖拉版面、按寄送，不想碰任何 DNS 或技術設定。
• 主要需求是成熟 CRM、銷售 Pipeline 與大量行銷自動化。
• 沒有自己的網站或系統，也不需要交易型 Email。
• 不想管理網域驗證、名單同步與技術整合。

這些情況下，Brevo、Kit 或其他完整 Email 行銷平台可能更直接。工具不是越新越好，而是架構要和你的能力、資料與營運方式匹配。

如果是 WordPress／課程網站，我會怎麼選 Resend 架構？

需求	建議架構
只解決網站通知寄信	WordPress → FluentSMTP → Resend SMTP
想直接用 Resend 寄電子報	訂閱表單 → Resend Contacts → Broadcasts
WordPress 已有 FluentCRM	先決定 FluentCRM 或 Resend 誰是名單主資料，再設計同步
課程／會員系統要高度客製	網站／CRM 保留資料 → API／Webhooks → Resend
未來可能換寄信商	名單留在自己 CRM／資料庫，Resend 只負責寄送層

如果你已經在比較「WordPress 自架名單」和「雲端 Email 平台」兩種思路，也可以看FluentCRM＋Brevo vs Kit 怎麼選？，先把「名單放哪裡」這個核心決策想清楚。

Resend 常見問題

Resend 可以用在 WordPress 嗎？

可以。Resend 官方支援 SMTP，也列出 WordPress 為 SMTP 整合情境之一。WordPress 可以透過 SMTP 外掛，把系統 Email 交給 Resend 寄送。

Resend 可以寄電子報嗎？

可以。Resend 現在提供 Marketing Emails、Contacts、Audiences 與 Broadcasts，可發送電子報、產品公告與促銷內容，也支援退訂、排程、個人化與追蹤。

Resend 免費嗎？

有免費方案。截至 2026 年 10 月，交易型 Email 免費方案每月 3,000 封、每天 100 封；Marketing Email 目前也提供最多 1,000 Contacts 的免費層。正式使用前仍建議重新查看官方價格頁。

Resend 和 FluentSMTP 是同一種工具嗎？

不是。FluentSMTP 是 WordPress 裡負責把 wp_mail() 交給外部寄信服務的外掛；Resend 則是實際提供 SMTP／API 與 Email 投遞能力的雲端服務。

Resend 可以取代 Brevo 嗎？

視需求而定。如果主要需求是 API、交易信、SMTP、Broadcasts 與自建整合，Resend 很適合；如果你更需要完整 CRM 與非技術行銷流程，Brevo 可能比較直接。

名單一定要放在 Resend 嗎？

不一定。可以把 Contacts 放在 Resend，也可以讓 WordPress CRM 或自己的資料庫成為主資料來源，再把寄送交給 Resend。後者彈性較高，但同步與退訂管理也更複雜。

參考資料

Resend｜Pricing｜查閱日期：2026 年 10 月。
Resend｜Marketing Emails。
Resend｜Broadcasts。
Resend｜Audiences。
Resend｜SMTP Service。
Resend｜What are the most common use cases｜更新 2026 年 7 月。
Resend｜Compatibility、Webhooks 與 Domain 相關官方文件。

結論：Resend 真正值得看的，不只是「能寄信」，而是你可以把 Email 層獨立出來

如果只是要讓 WordPress 通知信正常送達，Resend 可以是一個 SMTP 選項；如果要經營電子報，它也已經有 Contacts、Broadcasts、退訂與追蹤；如果你有自己的 CRM、會員系統或資料庫，還可以把 Resend 只放在「寄送層」，讓名單和商業邏輯留在自己手上。

這也是 Resend 和傳統「全包式電子報平台」最有意思的差別：你可以只用一小部分，也可以把它組進自己的網站架構。

對 WordPress、課程網站與知識型創業者來說，真正要先決定的不是「Resend 好不好」，而是名單誰管理、交易信誰寄、電子報在哪裡發、退訂狀態以哪裡為準。這四件事想清楚，Resend 才會從一個寄信工具，變成真正可長期使用的 Email 基礎設施。