很多企業都有自己的 ERP、CRM、網站或會員系統，而這些系統通常都會需要寄送 Email。
一開始可能只要設定 SMTP 帳號就可以使用，但當系統越來越多，管理上就會開始遇到一些問題：
這些問題，也是企業開始考慮 SMTP Relay 的原因。
簡單來說，SMTP Relay 可以想成企業的「統一寄信出口」。
ERP、CRM、網站等系統，不需要各自處理郵件伺服器，而是把郵件交給 SMTP Relay，再由 Relay 負責送到收件人的郵件伺服器。
hungchinwai
ERP ─┐
CRM ─┤
網站 ─┼──> SMTP Relay ──> 收件人
App ─┘
這樣可以把原本分散在不同系統中的寄信功能集中管理。
當企業有多套系統時，可以進一步將 SMTP 帳戶分開。
例如：
ERP → ERP 帳戶
CRM → CRM 帳戶
網站 → Website 帳戶
這樣當收到一封退信或發現寄件異常時，比較容易判斷是哪一個系統所產生的郵件。
同時也可以依照不同帳戶進行權限與使用量管理。
這是 SMTP Relay 比較進階的應用。
例如：
ERP 帳戶 → IP-A
CRM 帳戶 → IP-B
網站帳戶 → IP-C
也就是說，不同 SMTP 帳戶的郵件，可以依照設定使用不同的寄件 IP。
這樣做的好處，是可以讓不同系統或不同用途的郵件流量分開管理。
例如企業可以將：
交易通知 → IP-A
系統通知 → IP-B
其他大量郵件 → IP-C
分別管理。
當某一類郵件出現寄件異常時，也比較容易進行問題定位與後續調整。
如果所有系統都使用相同的 SMTP 帳戶與寄件 IP：
ERP ─┐
CRM ─┤
網站 ─┼──> IP-A
App ─┘
當其中一個系統的寄件量突然增加，或出現大量退信時，就比較難區分不同來源的寄件狀況。
透過帳戶與 IP 分流，可以讓不同來源的郵件有更清楚的管理邊界。
當然，IP 分流並不是代表只要更換 IP 就一定可以解決郵件投遞問題。
寄件網域、SPF、DKIM、DMARC、郵件內容、收件人品質以及寄件行為等因素，同樣都會影響郵件投遞。
因此，IP 分流比較適合作為整體寄件管理的一部分。
其實不一定。
例如 SMTP Server 回傳：
250 OK
通常代表對方郵件伺服器接受了這次傳送。
但如果出現：
450
550
511
則可能代表暫時性或永久性的寄送問題。
因此，如果企業只是記錄：
系統已送出
其實還是不太夠。
更完整的做法，是將 SMTP 回應與後續的寄件結果保存下來。
當企業每天寄送大量通知時，單純知道「今天寄了多少封」並不一定足夠。
更重要的是：
某一封信到底發生了什麼？
因此可以為每封郵件建立唯一的通知編號，例如：
NTF-Email-0000009519
再搭配：
就可以讓企業更容易追蹤單封郵件。
例如客戶反映「沒有收到信」時，就可以進一步查看實際寄件紀錄，而不是只能看到「系統已送出」。
在設計科云通知中台時，我們也遇到這些企業實際會面對的問題。
因此目前的 SMTP Relay 不只是單純提供一個 SMTP Server，而是將帳戶、寄件 IP 與寄件狀態納入同一套服務。
目前支援：
整體流程可以簡化成：
企業系統
↓
SMTP 帳戶
↓
指定寄件 IP
↓
SMTP Relay
↓
收件人郵件伺服器
↓
SMTP 回應 / 退信
↓
寄件狀態追蹤
這樣企業原本分散在 ERP、CRM、網站或其他系統中的 Email 寄件需求，就可以集中到同一套通知服務中管理。
當企業只有一套系統時，SMTP 設定可能很簡單。
但當 ERP、CRM、網站、電商與其他系統都開始需要寄送 Email 後，帳戶管理、寄件 IP、寄件狀態與退信追蹤，就會逐漸變成需要處理的問題。
SMTP Relay 的價值，也就不只是「幫你把信寄出去」，而是讓企業可以把原本分散的寄件需求集中管理。
科云通知中台目前以企業 SMTP Relay 為核心，提供 SMTP 帳戶管理、依帳戶進行寄件 IP 分流，以及寄件狀態追蹤等功能。
未來也會持續擴充更多企業通知通道。
科云通知中台：
iThome鐵人賽
看影片追技術