點樣由你嘅應用程式發送電郵（並確保入到收件箱）

要可靠地由應用程式發送電郵，請使用電郵發送服務商，而唔係用你自己嘅郵箱；由你自己網域上嘅地址發送；並加入服務商提供嘅 DNS 紀錄，令 SPF、DKIM 同 DMARC 全部通過驗證。將交易電郵（重設密碼、收據、確認訊息）同推廣電郵分開，每種只發送俾預期收到嘅人，並處理退信同取消訂閱。先確保認證正確，因為呢個係應用程式電郵被送入垃圾郵件最常見嘅原因。

交易電郵 vs 推廣電郵

呢兩類電郵喺程式碼入面睇落好相似，但收件箱服務商同法律都會以截然不同嘅方式處理。

要將兩者分開。如果某個推廣活動收到垃圾郵件投訴，你唔會想同一個發送渠道嘅重設密碼郵件因此受影響。常見做法係用獨立子網域，例如帳戶電郵用 mail.example.com，電子報用 news.example.com；有啲服務商亦會喺內部將兩者分開。例如 Postmark 表示，截至 2026 年 9 月，其交易與廣播「訊息串流」運行喺獨立嘅發送基礎設施上。

揀選服務商

你嘅應用程式唔應該由自己嘅伺服器直接發送電郵。發送服務商負責基礎設施、IP 信譽、重試同退信處理。知名選項包括 Postmark、Resend、SendGrid、Amazon SES 同 Mailgun；每個都提供 HTTP API 同 SMTP 存取。價格同方案都會更改，所以請到各自網站比較。

比較時要留意：

• **專注範圍。**有啲服務商專注交易電郵，有啲則同時提供交易同推廣電郵。
• **開發者體驗。**清晰嘅 API、適用於你語言嘅官方函式庫，以及有用嘅紀錄，可以睇到每封郵件係已送達、已退信定係被標記為垃圾郵件。
• Webhooks，用於接收退信、投訴同送達通知，令你嘅應用程式可以作出反應。
• 範本：儲存喺服務商處，或者放喺你自己嘅程式碼入面。放喺程式碼入面，範本會有版本記錄，亦更易測試。
• 地區同資料處理，如果你對資料處理地點有要求。
• 按你嘅用量計算成本，包括超出免費額度時會點。

如果係發送電子報俾一個名單，專門嘅電子報或電郵行銷工具通常比喺你嘅應用程式入面加入推廣功能更合適。

設定你嘅發送網域

請用你自己嘅網域發送，例如 hello@example.com，而唔係 Gmail 或 Outlook 地址。透過第三方服務以免費郵箱地址發送嘅郵件，會未能通過認證檢查，好可能會被過濾。

可以考慮專用於發送嘅子網域。例如 Resend 建議用 updates.example.com 之類嘅子網域發送，以隔離發送信譽（截至 2026 年 9 月）。咁做亦可以令電郵 DNS 紀錄同你主網站嘅紀錄分開。

服務商然後會提供 DNS 紀錄，你要喺管理你網域 DNS 嘅地方加入。如果你對 DNS 未太熟悉，網域同 DNS 點樣運作會先講解紀錄嘅概念。

SPF

SPF（Sender Policy Framework）係一條 TXT 紀錄，列出邊啲伺服器可以代表你嘅網域發送電郵。收件方會檢查發送伺服器有冇喺名單上。

• 一個網域只應該有一條 SPF 紀錄。如果加入新服務商，要併入現有紀錄，而唔係再加入第二條。
• 評估時 SPF 最多允許 10 次 DNS 查詢；如果 include: 條目鏈太長，可能會超出上限而導致失敗。
• 好多服務商會要求你建立一個回傳路徑子網域，並喺該子網域設定 SPF，所以你可能根本唔需要改動主 SPF 紀錄。

DKIM

DKIM（DomainKeys Identified Mail）會為每封郵件加入一個加密簽名。服務商用私鑰簽名；你則將對應嘅公鑰發布為 DNS 紀錄（TXT 或 CNAME，視乎服務商而定）。收件方會核對簽名，確認郵件確實來自獲授權嘅發送者，而且途中冇被更改。

服務商嘅「驗證網域」步驟主要就係關於 DKIM。唔好跳過。

DMARC

DMARC 將其他兩者串連起來。佢係位於 _dmarc.yourdomain.com 嘅一條 TXT 紀錄，會告訴收件方：

• **對齊：**睇得見嘅寄件人地址中嘅網域，必須同通過 SPF 或 DKIM 驗證嘅網域一致。
• **政策：**對驗證失敗嘅郵件點處理——p=none（只報告）、p=quarantine（視為可疑，通常會入垃圾郵件）或 p=reject（拒收）。
• **報告：**彙總報告要寄去邊個地址（rua=），令你知道邊啲人以你嘅網域發送郵件。

一個穩陣嘅做法，係先用 p=none 同一個報告地址，確認你嘅正常郵件都能通過，然後再轉去 quarantine，最後才到 reject。嚴格嘅政策亦令其他人更難偽冒你嘅網域。

Gmail 嘅要求

截至 2026 年 9 月，Google 嘅發送者指引規定：

• 所有發送者向個人 Gmail 帳戶發送郵件，都需要 SPF 或 DKIM、發送伺服器有效嘅正向同反向 DNS、TLS，以及 Postmaster Tools 中嘅垃圾郵件率低於 0.3%。
• 大量發送者（每日向 Gmail 發送超過 5,000 封郵件）需要 SPF 同 DKIM、一條 DMARC 紀錄（允許使用 p=none 政策）、寄件人網域對齊，並在推廣或訂閱郵件中提供一鍵取消訂閱，以及清晰可見嘅取消訂閱連結。

服務商會處理伺服器端嘅部分，而 DNS 紀錄同取消訂閱處理則由你負責。即使你每日發送量遠低於 5,000 封，符合大量發送嘅規則都係最簡單、最穩妥嘅做法。

將發送功能加入你嘅應用程式

網域驗證完成之後：

1. 儲存 API 金鑰，作為伺服器端秘密——切勿放喺前端程式碼入面。請參閱環境變數同秘密資料係咩。
2. 由伺服器發送，並且喺觸發電郵嘅操作成功之後先發送。
3. **唔好令用戶等電郵。**對於比最簡單更複雜嘅應用程式，應該將發送放入佇列，並對暫時性失敗進行重試，咁服務商回應慢都唔會拖慢註冊。
4. 記錄結果，包括服務商嘅訊息 ID 同狀態，但唔好記錄金鑰，亦唔好記錄包含個人資料嘅完整郵件內容。
5. 處理 webhook，接收退信同投訴。對硬退信或標記你為垃圾郵件嘅地址，停止再發送。

一個涵蓋基本功能嘅提示例子：

使用伺服器秘密 [ENV_NAME] 透過 [PROVIDER] 發送交易電郵，寄件人為「Acme hello@mail.acme.com」。用戶註冊後發送歡迎電郵，預約儲存後發送預約確認。範本放喺程式碼入面，並同時提供純文字同 HTML 版本。將發送放入佇列，對暫時性失敗最多重試三次。用服務商嘅錯誤訊息記錄失敗，但唔好記錄 API 金鑰。加入一個 webhook 端點，遇到硬退信同投訴時將地址標記為無法送達，並喺之後跳過呢啲地址。

帳戶電郵，包括驗證連結、魔法連結同重設密碼，都係登入流程嘅一部分。點樣為你嘅應用程式加入登入功能會講解呢啲流程點樣串連；請確保呢類連結只可使用一次，並且有效時間短。

送達率習慣

認證令你嘅郵件被考慮，但行為先可以令郵件留喺收件箱。

• **只發送人哋預期嘅郵件。**經確認嘅註冊、推廣需要清晰嘅明確同意，切勿購買名單。
• **令取消訂閱變得容易。**凡係並非純粹交易性質嘅郵件，都要提供簡單嘅取消方式，並即時執行。
• **預熱新網域。**一個全新網域第一日就發送數千封郵件，睇落好可疑。先由交易郵件開始，再逐步增加發送量。
• **保持名單乾淨。**即時移除硬退信，並考慮移除長時間冇開過任何郵件嘅人。
• **寫得似人寫。**清晰嘅主旨、容易認出嘅寄件人名稱、純文字版本、較少圖片，以及指向你自己網域嘅連結。避免使用短網址服務。
• **監察。**喺 Google Postmaster Tools 註冊你嘅網域，並不時閱讀 DMARC 報告。
• **使用真實、有人會閱讀嘅回覆地址。**回覆係良好嘅訊號，亦係有用嘅意見回饋。

測試而唔滋擾任何人

• 如果你嘅服務商有測試模式或沙盒，就用佢；否則就發送俾你自己擁有嘅地址。
• 喺開發階段，將郵件發送到接收所有郵件嘅測試收件箱，而唔係真正用戶；一個載有睇落似真實地址嘅種子資料庫，好容易令你誤發電郵俾陌生人。
• 喺幾個電郵用戶端檢查每個範本，例如網頁版 Gmail、手機郵件應用程式、Outlook，並檢查深色模式。
• 查看測試郵件嘅標頭：佢會顯示 SPF、DKIM 同 DMARC 有冇通過。

法律基本要點

規則因國家而異。概括而言，推廣電郵喺好多地方都需要同意、必須表明寄件人身份，並且必須提供有效嘅取消訂閱方式；交易電郵嘅處理方式有別，但都唔應該用來偷偷加入推廣內容。如果你透過候補名單頁面收集地址，要講清楚會發送咩、何時發送，以及每個人係點樣、幾時註冊嘅，並說明你會點樣儲存。如有懷疑，請查清你嘅用戶所在地嘅規則。

電郵檢查清單

• 已揀選發送服務商；API 金鑰已儲存為伺服器秘密
• 使用你自己嘅網域或子網域發送，而唔係免費郵箱
• SPF、DKIM 同 DMARC 紀錄已加入，並且通過驗證
• 交易郵件同推廣郵件已分開
• 發送已放入佇列並會重試；結果已記錄
• 已處理退信同投訴嘅 webhook
• 非純交易郵件提供取消訂閱，並即時執行
• 範本已喺多個用戶端測試；測試郵件永遠唔會送到真實用戶

由 Mythex 應用程式發送電郵

Mythex 唔會為你建立嘅應用程式提供內建嘅電郵發送服務，所以你需要自己帶一個服務商，例如 Resend、SendGrid 或 Postmark。將佢嘅 API 金鑰儲存為項目秘密——代理可以透過聊天中嘅秘密資料卡向你索取——然後用白話文講明你需要嘅電郵。文件中有一個起始提示，見由應用程式發送電郵。如果你喺 Pro 方案下透過 Mythex 購買咗網域，你可以喺網域嘅 DNS 設定中加入服務商提供嘅 TXT 同 CNAME 紀錄；請參閱自訂網域。

常見問題