在開發網站、會員系統或 ERP 時，Email 通常是不可或缺的功能。

例如：

• 使用者註冊時寄送驗證信
• 忘記密碼時寄送重設連結
• 訂單成立時寄送通知
• 系統發生異常時寄送警告信
• 定期排程寄送報表

這些功能看起來很簡單，只要呼叫 SMTP 寄信就可以了。

但實際上，程式執行成功，不代表 Email 一定已經送達收件人的信箱。

SMTP 回傳成功，就代表信件送達了嗎？

假設程式透過 SMTP 傳送郵件，伺服器回傳：

250 OK

這通常代表目前這一段 SMTP 傳送流程已經成功，對方郵件伺服器接受了這封信。

但這不代表收件人一定看得到郵件。

後續仍可能發生其他狀況，例如：

• 郵件被放進垃圾郵件資料夾
• 郵件遭到收件端的安全機制攔截
• 後續投遞失敗，產生退信
• 收件人的信箱容量已滿
• 郵件已送達，但使用者沒有注意到

因此，如果系統只記錄「寄信成功」，當使用者反映沒有收到信時，開發人員可能還是無法判斷問題出在哪裡。

為什麼只記錄程式執行結果不夠？

不少系統會採用類似以下的處理方式：

try {
    mailSender.send(message);
    log.info("Email sent successfully");
} catch (Exception e) {
    log.error("Email sending failed", e);
}

這樣可以知道寄信過程是否發生例外，但對於後續的郵件投遞狀態，仍然可能缺乏足夠的資訊。

例如，當使用者回報沒有收到密碼重設信時，我們可能需要確認：

1. 系統是否真的執行寄信？
2. SMTP 伺服器是否接受郵件？
3. SMTP 回應內容是什麼？
4. 後續是否收到退信？
5. 這封郵件是否能透過唯一編號找到紀錄？

如果沒有保存這些資訊，往往只能重新測試，或請使用者檢查垃圾郵件資料夾。

每封郵件都應該有自己的追蹤紀錄

對於有一定寄件量的企業系統，我認為可以替每封郵件建立唯一的通知編號。

例如：

NTF-Email-0000009519

並記錄以下資訊：

當客戶反映沒有收到通知時，就可以透過通知編號或收件人查詢紀錄，而不是只能從應用程式日誌中慢慢尋找。

需要注意的是，SMTP 接受郵件、最終送達與使用者實際閱讀，是不同的狀態，不能全部混為一談。

當企業有多套系統時，問題會更複雜

假設一家公司有 ERP、CRM、官網及會員系統，而且每套系統都有寄信功能。

ERP ─────┐
CRM ─────┤
官網 ─────┼──> SMTP Relay ──> 收件人
會員系統 ─┘

如果每套系統都自行處理 SMTP 設定、錯誤紀錄與退信，日後維護就可能變得複雜。

例如，當某個系統突然大量寄信，或某一類郵件持續發生退信時，就需要分辨不同系統的寄件情況。

將郵件集中交由 SMTP Relay 處理，可以進一步統一帳戶管理、寄件紀錄與相關設定。

如果還能依照不同 SMTP 帳戶設定不同的寄件 IP，也有助於區分不同系統的郵件流量。

當然，集中管理並不代表可以保證郵件送達，寄件網域設定、郵件內容、收件人品質及收件端政策仍然會影響投遞結果。

自行維護 SMTP，還是使用第三方服務？

這沒有絕對答案。

如果系統寄件量很少，而且開發團隊已經有成熟的郵件維運能力，自行管理 SMTP 可能就足夠。

但如果企業有多套系統，還需要管理不同寄件帳戶、寄件 IP、退信紀錄與使用量，就可以評估使用第三方 Email 服務，減少自行維護相關基礎設施的工作。

評估時除了價格，也可以注意：

• 是否支援多個 SMTP 帳戶
• 是否能依帳戶進行寄件 IP 分流
• 是否能查詢單封郵件的寄件紀錄
• 是否提供 SMTP 回應及退信資訊
• 是否能依需求管理寄件額度
• 是否符合企業對資料安全與服務穩定性的要求

我們在科云通知中台的實作方向

在開發科云通知中台時，我們也將企業 SMTP 寄件管理納入設計。

目前以 SMTP Relay 為核心，提供多個 SMTP 帳戶、依帳戶進行寄件 IP 分流、寄件狀態追蹤、SMTP 回應紀錄、退信資訊管理及寄件額度管理等功能。

希望讓企業不必在每一套應用程式中各自處理所有郵件管理工作，而是能夠透過同一個服務集中管理。

如果你的系統也有大量 Email 通知，或正在處理 SMTP 寄件與退信追蹤問題，可以參考：

科云通知中台

https://hub.cointech.com.tw/

結語

Email 寄送看起來只是一個簡單的功能，但當它成為企業系統的重要通知管道後，真正需要處理的就不只是「如何寄出一封信」。

如何追蹤寄件紀錄、判斷 SMTP 回應、查詢退信原因，以及區分不同系統的寄件流量，同樣值得在系統設計初期就納入考量。

與其等到使用者反映收不到信時才開始追查，不如先建立完整的寄件紀錄，讓後續維護更有效率。