外部發信服務踩雷記
有件麻煩事一直造成困擾，就是寄信這回事。這其實又是在解決別的團隊 N 年前就解決的問題。
競爭力其實是很複雜的一件事，
有些產品的價格很有競爭力，是因為該給員工的沒有給；
有些產品的價格很有競爭力，是因為在看不到的地方讓大家省錢花時間。
開發客製化系統，除了要解決「套版」「Open Source」工具無法解決的問題，也得跟上市面上各種「大平台」的潮流。
以購物網站來說，除非沒有人在逛，不然理論上每天有一堆信要寄…
1. 會員註冊驗證信
2. 會員歡迎信
3. 會員密碼重設信
4. 會員密碼已變更通知
5. 網站線上聯絡表單通知信
6. 購物訂單狀況相關通知信
7. 購物已收到款項通知信
8. 購物已出貨通知信
9. 會員生日通知信
10. 會員折價券通知信
11. 會員折價券到期通知
12. 會員購物車未結帳商品通知信
13. 訂單問答店家回信
14. 訂單問答客人回覆
15. 各種為了 retention 的程序化信件。
還沒講到 edm / 會員電子報呢。
一、以前用免費信箱帳號面臨的問題
平常鮮少遇到「花多少錢能把這做好」這種事，只有「會動就好，能省則省。」本來在寄信這回事，用的是一些免費省錢花時間的方案，但各有一些缺陷…
(一)、用店家自己的企業信箱(如 mail2000 或一些虛擬主機附的信箱)，缺點有:
1.查不到寄件備份，除非每一封寄出的信都 bcc 給開發人員或 log 專用的 email，不然出問題時只能人工去重現，或是隔空抓藥。
2.改了密碼，但是網站後台的 SMTP 密碼沒改，信寄不出去。
3.因為寄了太多對消費者來說是垃圾的信，連累到一般正常往來的郵件收發，讓企業人員的公務信件常常寄到垃圾桶去。
4.越來越少人還在用什麼 Outlook 或是 @ 後面帶公司域名的企業信箱。對一些小企業小店家來說，甚至每天在 FB 私訊或是回的 Line 比 email 還多。
5.網頁表單的信有寄出去嗎? 有寄出去，但是因為店家容量超小的企業信箱滿了，信被退回到寄件伺服器那邊。通常是店家接到消費者抱怨說「線上反應問題都不處理」的時候才會發現。
(二)、用 Google 免費帳號/網頁公司的 Google 企業帳號**代發，寄件備份是有了，缺點有:
1.網站後台的「寄件設定」可以看到一組 Google 帳密，閒雜人等登入之後可以看到不該看到的信件紀錄。
2.訂購表單一陣子都沒訂單，登入帳號一看，原來已經被停用啦！信根本寄不出來，哪來的訂單?
3.因為外部應用程式寄信政策問題，設定打開之後隔一陣子又被鎖 5.5.1 Authentication Required
出現這種訊息，有時候是真的被偷登了，有時候是網頁表單寄件程式的請求被擋掉。
4.Gmail 傳送限制 每日寄信額度 500 封。
5.寄件程式設定有誤時，回信通通回給寄件伺服器，而不是到應該收到信的人手上。
6.信箱改了登入密碼，但是網站後台的 SMTP 設定沒跟著一起改，信又寄不出去了。
總之有各種原因發信服務沒有正常運作，但沒人知道的情況。
各種以為信有寄出去，但是應該收到信的人根本沒收到的情況。
二、尋找解決方案?
首先出國去考察……技術人員只能「坐在電腦前面」就要解決問題，沒有「行出國考察之名，順便行OOXX之實」的份兒。
使用了如智*生活館 – 輕鬆架站方案 的「訂購表單」，或是上網時整天跳廣告說上網賣東西超簡單超輕鬆的那些開店平台，或是「大中華市場」「亞洲市場」的一些線上服務，已經沒有人還在叫店家管理者設定 SMTP 了。
叫使用者整天處理 SMTP 的爛問題，大概就跟點表單還在跳 outlook ，出門買東西還在數零錢、結帳時刷好幾組條碼一樣麻煩。現在網站發信都流行用 Mailgun, Amazon SES 之類的外部發信服務。
三、導入外部發信服務
近幾年已經有許多技術人員的部落格，陸續發表一些國考上榜心得，或是養小孩………呃不，是外部寄信服務的使用心得，基本特色如下:
1. 有免費的每日寄信額度，要買的話也不貴，通常幾千封才 1 刀，(還有國外刷卡手續費。)
2. 不用寫半行程式碼，也不需要在網址加參數加到落落長，就可以追蹤使用者是否有開信，或點擊了哪些連結。
3. 寄出去的信都有紀錄。
4. 統一監控寄件系統運作狀態。
5. 不用擔心有人把信件回覆寄給寄件伺服器。
6. 通常是使用 API 串接發信，有些也提供 SMTP 帳密發信。
7. 這種服務商通常都國外開的，碰到問題怎麼辦? 看當初是誰說要用這個的，叫他去處理啊?
自己用 wordpress 跟 plugin 跟 opencart 試用一陣子之後，覺得也還不錯，也沒有什麼機敏信件，於是決定導入公司的產品與客戶內進行全民公測，然後這種實戰場合才是災難的開始，
四、不做不錯，多做多錯，很多坑
第一雷 : 雲端是個好東西，但要會用
全世界的外部寄信服務，用兩隻手都數不完，像是 7 Best Transactional Email Services: Sendgrid vs. Mandrill & More 就介紹了好幾個，但夠佛的就屬這兩套：
– 從 Amazon EC2 執行個體直接或透過 AWS Elastic Beanstalk 呼叫 Amazon SES(Simple Email Service) 時，每月可以傳出 62,000 則訊息給任何收件人。
– 從 Microsoft Azure 上使用 SendGrid 應用程式發信，每個月可以免費寄 25,000 封信。
免費封數額度多到數字還要加逗點，聽起來很棒，對吧?
但是雲端服務嘛，很多新手都被雷過…
看網路上的教學開個什麼應用程式，結果產生了成就感，還有許多的信用卡帳單費用，
幾年前公司在試用的時候，也發生用完沒關，結果產生費用的狀況。跟免費額度沒關係，有些東西開了就是要付錢，天底下沒有白吃的午餐。
使用任何服務前請確定有足夠的專業人員，以免出事的時候那個人被狂 call，或是後續沒人接手。
第二雷 : SMTP 發信(SMTP credentials) 跟 API 發信，都擠(どっち)?
API 發信有各種好處，不用擔心哪個主機又給你擋 Port，還有主機啥服務沒開，碰到一些需要更彈性、更刁鑽的發信需求時也更方便。Mailgun 更是號稱 API 發信比 SMTP 發信還快三倍!
可是公司不是用套裝程式，也不是一個大平台，沒辦法滑鼠點一點就把所有客戶直接切換上線。現有的程式都是使用 SMTP 帳密發信，那麼是誰要去把「以後開發的程式」跟「測試用的程式」改成用 API 發信的?
這個月才發生中華電信網路大當機 Facebook、Gmail、YouTube無法使用，結果從機房的主機發出來的寄信要求通通「無法解析遠端名稱: smtp.gmail.com 」，訂購表單都掛了，馬上緊急換成 Office365 的 SMTP。
如果哪天又海纜斷掉，哪邊的 DNS 又幹嘛了，或是骨幹網路層或中華電信又幹嘛了，那 API 寄信可以像上面的處置方式這麼快速切換、熱插拔嗎?
第三雷: 感覺功能限制多多? 因為新手村任務沒解完
帳號辦好之後，發現一天只能寄信個幾十封? 還只能寄給經過授權過的收件人? 只能寄信給認證過的網域收件人? 怎麼不像大家說得這麼好用?
因為這些系統都準備很多「大地遊戲」讓你跑，要跑完之後才有許多免費額度可以用。
像是沒綁定域名，發送額度就很少，發送情況也很受限。
像 Mailgun 沒綁定信用卡時，寄信就會跳訊息：
Free accounts are for test purposes only. Please upgrade or add the address to authorized recipients in Account Settings.
還以為真的不花錢，就不能寄給任意素昧平生、一期一會的消費者啊? 先把官方的 support 看熟再來。
綁了信用卡還不夠，像是一開始沒有信用：
Your account is on probation and domains are limited to 100 messages / hour. The restriction is removed if you keep sending good traffic.
Amazon SES 也要填申請表，參照指南 Opening an SES Sending Limits Increase Case 跟 Managing Your Amazon SES Sending Limits ，才能擁有更多的方便功能與更高的使用額度。
DNS 生效是挺快的，但是要讓一個服務上軌道，養一個發信帳號，還是需要一段時間啊。
第四雷 : 被 Yahoo 跟 Hotmail 雷到
這些外部寄件服務寄出來的信，先不討論 header，通常一般使用者看到的會長這樣：
不會是寄件人名稱< email>，而是透過某某某，還會自動加上 reply-to 相關標記。
但在使用 Mailgun 時遇到一個情況：
程式產生一組資料，要同時寄給管理員和消費者。
寄件人後面顯示的是一組店家的 hotmail 帳號，收件人也是同一個 hotmail 帳號，
Mailgun 的 log 顯示狀態代碼 250 投遞成功，
但是 hotmail 的信箱、垃圾信件匣中卻完全看不到這封信。
處置方式A : 讓寄件人顯示的 email 帳號不要是 hotmail 或 yahoo mail 就好，但 Gmail 跟 Office365 就完全沒有這種問題。
處置方式B : 讓寄件人顯示的 email 帳號是 noreply@domain.com 之類的，保證不衝突，只是有點醜。
處置方式C : 店家收到的信，寄件人要顯示消費者的 email；消費者收到的信，寄件人要顯示店家的 email，如果消費者沒填 email (有些訂購表單專門設計給不會用 email 的族群)，則顯示其他的 email。
然後 mailgun 寄給 hotmail，過一陣子又炸了，寄出去的信完全被擋掉，所以最後還是又換回 gmail smtp。
也許是需要買這個?
第五雷 : 提供把信寄到垃圾信件匣的服務
從前拿 Google 免費帳號，或是 Google 企業帳號來寄網站上的信，偶爾會把信寄到 Gmail 的垃圾信匣去，然後用 Outlook 的使用者就會來反映程式會漏信！真是寶寶心裡苦寶寶不能說。
但改用其他外部寄件服務後，以 Mailgun 為例：
寄給 Gmail 信箱幾乎是百發百中，信都安安穩穩的躺在收件匣中，但是其他信箱就滿慘的。
Hotmail 跟 Office 365 信箱寄到垃圾信件匣的機率因人而異，一樣寄三封信，有的人完全在信件匣，有的則是三封都進垃圾信件匣。
Yahoo 信箱就更慘，我還沒看過信不是出現在垃圾信件匣的。
換個 domain 也一樣，屢試不爽。
反觀 Amazon SES ，在各家免費信箱的收件匣投遞成功率就高得多，甚至 DKIM 都還沒設定！真不知道眉角在哪裡。
這些外部寄件服務都會介紹說他們如何提高信件的 deliverability，
或是可以向 Email Service Provider 申訴說我的 domain 很乖，
如果還不行，也許就需要買個獨立 IP 吧?
第六雷 : 大中華市場
這些外部寄件服務畢竟是…
以 mailgun 為例，寄到 QQ 信箱會得到伺服器回應 550 Ip frequency limited. http://service.mail.qq.com/cgi-bin/help?subtype=1&&id=20022&&no=1000725
騰訊的說明大概是這樣:
550 Ip frequency limited
出错原因：该服务器IP的发信频率超过腾讯邮箱限制。腾讯邮箱对来自相同IP的外部发信服务器有一定的频率限制：
1、超过每分钟发信量限制，此IP地址被禁止发信若干分钟。
2、超过每小时发信量限制，此IP地址被禁止发信若干小时。
3、超过每日发信量限制，此IP地址本日内禁止再发信。
4、以上频率限制数值属于腾讯邮箱保密数据，恕不公开。
我本來以為這是被鎖，不能用的意思，不愧是大中華市場有自己的玩法。
但一樣是 SMTP credentials，程式沒有特別寫重發機制的情況下，
從 Mailgun 的 log 中發現，Mailgun 會自動一直重發， 等待 8~24 小時後該 QQ 信箱就會收到信了。大概是等 IP 解鎖之後，QQ 信箱就收到信了吧?
如果信要馬上讓 QQ 信箱收到，也許我又需要這個獨立 IP ?
Amazon SES 則是當下就直接狀態 550 退信給寄件人，不會自動重發，
看來需要讓 Amazon SES 寄信給 QQ 信箱，則是需要充值 AWS 大禮包了。
專用 IP 地址
每個專用 IP 地址的價格是每月 24.95 USD。每個月底您收到的帳單包含專用 IP 地址及產生的任何其他 Amazon SES 電子郵件傳送費用。
試用了一些大陸地區會寄信給消費者的平台服務，除了用 Amazon SES 或是阿里雲寄的，還有一些使用本地的外部寄件服務，例如:
SendCloud 通過各種認證後，每天有 200 封的免費額度
SUBMAIL 赛邮云通信 每天前 500 封免費
国内有没有好点的邮件代发商？ – 创业 – 知乎
不得不說，台灣連到大陸一些線上工具的的網速實在慢。明明平常看愛奇藝什麼的就不會這樣啊?
第七雷: 要如何翻舊帳?
用這些外部寄件服務的好處是有紀錄，
方便釐清問題是「信沒有寄出去」還是「使用者沒收到」，
方便釐清問題是「信件內容真的有誤」還是「使用者的問題」，
甚至用這些紀錄做一些警示功能，例如每個網站各開一組 SMTP credentials，當某組 SMTP credentials 寄太多信時，就要向它的主人要錢。
但事實上這些記錄的查詢方式沒有想像中的平易近人，大部分只能知道特定時間內，各種發送與投遞情況的「數量」，查不到每一封的詳細內文記錄。
Mailgun 比較好上手一點，Log 的資訊比較多，而且連程式都不用寫，直接有個網頁介面可以查詢：
(mailgun log 範例，一則是開信者的資訊，一則是投遞失敗的內容)
但要查看郵件內文，則需要 json parser 來輔助，就又多了幾步。
而且信件收發、開信、點擊的紀錄只有保留 30 天，不是永久保存的，發出去的信件內文甚至只有保存 3 天。想到之前同事串簡訊王，也是隔一段時間之後平台上的發送紀錄通通會清掉，發送過的簡訊通通狀態變成空狀態，也是要另外做處理。
然後還有一些疑難雜症，有時候會發生信確實有寄出，但是 mailgun log 裡面完全沒有 Accepted 跟 Delivered 的紀錄。或是某消費者 Opened Email 的紀錄占了數十筆，比店家看信的次數還多，不曉得發生了什麼事。
Amazon SES 則是似乎根本查不到發過的郵件內文，可能要用 AWS CloudTrail 跟 AWS CloudWatch 自己兜。
所以如要高枕無憂，可能還是需要自行另外備份更久以前的 log ，跟專門做個查詢程式。技術上要最簡單達成的 log 紀錄與查詢功能，大概是系統每次寄信時，每封信都 Bcc 給一個專用存 log 的 email 吧。
結論
如何得到良好的網站發信體驗？就是花錢。
那麼花錢買了這些服務，在 DNS 、主機上、發信服務上面設定跟驗證了一大堆 DKIM、SPF、DMARC 什麼的東西，就可以保證郵件 100% 不會進到垃圾郵件匣，100%不會漏信？不可能。
如果有這種完美方法，然後那些發垃圾郵件的廠商剛好都不知道？
Mailgun 有一個 uservoice許願池，有想要什麼功能可以在上面許願，官方會從裡面挑功能來做。
有一個 Get stats by SMTP credentials 剛好我還滿需要的，希望大家可以一起去投票，謝謝。
至於要寄 eDM/電子報，這又是另一個故事了。
個人是使用 Mailchimp，每月免費額度 12000 封也很夠用了。
不過一般老百姓對於 eDM/電子報發送系統的需求：
– 看不懂英文
– 不想花錢
– 不要多記一組帳密，一條龍管理，勾一勾直接寄出去，不要匯入匯出。
– 編排工具要好用
– 自己無法產生數位內容，但是電子報要漂亮
– 但是要能方便管理收件名單
– 還要能方便檢視發送成效