如何校驗 email 地址以提升郵件送達率

背景

在發送 email 的時候,若是郵件收件人是一個不存在的 email 帳號、或者收件人帳號存在問題、收件箱沒法接收 email, 那麼 email server 就會將該沒法接收的信息響應回來, 這種狀況稱之爲 bounce email,對應的衡量指標是 bounce 率。bounce email 是影響郵件送達率(email delivery rate)的一個重要因素。根據 Sendgrid 統計結果, bounce 率在 5% 以上,送達率爲71%;但若是 bounce 率在2%或如下,平均送達率能夠提升到91%。html

目前咱們平臺每月郵件發送量在千萬封左右,包括通知類和營銷類郵件,其中 marketing campaigns 佔了大部分。 由於 marketing campaigns 會讓客戶自定義 contacts,這部分是潛在 bounce email 的一個風險,因此在發送郵件前檢測收件人 email 地址是否可送達,過濾掉其中的垃圾和無效的 email 地址,能夠有效減小 bounce rate。這篇文章咱們會詳細介紹如何經過校驗 email 地址以及最佳實踐 , 來提升郵件送達率。git

爲何 Bounce 影響 email 送達率

上面 Sendgrid 對 bounce email 的統計數據, 能夠較明顯地看出 bounce 率和送達率的相關關係。但其中的相關性不只僅只是 bounce 佔了總髮送郵件數的比例大才影響送達率,而是 bounce 率高會進而影響到正經常使用戶的郵件送達。github

每個 email 帳號都有一個發件人信譽的分數(reputation),來幫助收件人的 email 服務提供商(ESP)決定郵件的質量。分數越高,郵件的送達率也會越高,反之亦然。若是頻繁的 bounce ,會致使收件的 Email Server 「質疑」 發件人郵箱帳號是否爲真實帳號,當到達必定程度, 該 sender 帳號會被列入各類 ESP 的垃圾郵件索引,最後發送給其餘用戶就會被 blocked。而且 bounce 會影響發件人 domain 和 ip 的 reputation。正則表達式

因此 email bounces 能夠說是 marketing campaigns 的一個「噩夢」。校驗 email 地址有助於將郵件發送給正確的收件人,同時使 email 賬戶保持可用狀態,並提升 reputation。對業務來講,也會提高 email campaign 的質量。api

如何校驗 email 地址

完整的 email 地址的校驗過程主要包括如下4個維度:安全

  1. 語法檢查
  2. 檢查是否爲一次性郵箱(disposable)
  3. 確認 domain 對應 DNS 記錄是否存在
  4. Ping 收件人郵箱

語法檢查

拼寫的語法錯誤是 email 地址檢查最多見的問題之一。 根據經常使用的 email 地址正則表達式,能夠確認出地址是否有格式問題。通常檢查的表達式相似於 abc@aftership.com, 包括3個部分: local part 、@分隔符 和 domain。服務器

較重點檢查的是 local part 部分,由如下3部分組成:dom

  • 字母數字 – A 到 Z(包括大小寫), 0-9
  • 可打印字符 – !#$%&'*+-/=?^_~`
  • 一個標點符號. – 可是 local part 不能以 . 開頭或結尾、或者連續使用,好比 example..dot@aftership.com是一個非法的 email 地址。

不一樣的 email 服務提供商對 local part 有不一樣的規定,這裏 mailgun 提供了一份常見 ESP 的 校驗規則ide

domain 跟對域名的命名約定是一致的:包括只使用字母數字和-符號且不能連續使用。工具

除了根據正則表達式對 email 地址作檢查,還須要考慮的一些點是 IETF 標準non-ASCII domains

檢查是否爲一次性郵箱

一次性郵箱是指那些小段時間內有效的 email 地址,被稱做 disposable email。 disposable email 是一個正確語法的地址,且能夠接收和發送 email, 正常只能用一次,通常是用來註冊新帳號繞過登陸、發送惡意郵件等場景。

常見的 disposable email 提供商包括 Nada 和 Mailinator 等。識別它們的方法是判斷 domain 是否爲disposable domain。目前開源社區有維護一些實時更新的 disposable domain 列表, 經過在列表裏搜索 domian 的方式快速過濾掉 diposable email。

確認 domain 對應 DNS 記錄是否存在

DNS 查詢是指向 DNS 服務器請求 DNS 記錄的過程。DNS 記錄包括多種 domain 記錄,這裏咱們主要確認 MX record(_mail exchanger record, 郵件交換記錄_)。該解析記錄用來指定 email server 接收特定域名的 email。舉個例子,咱們對 aftership.com 查詢 DNS 記錄以下:
image

能夠看到 aftership.com對應有4條 MX 記錄。MX 記錄存在表示 domain 對應的 ESP 是存在, 不然不是一個有效的 email 地址。

Ping 收件人郵箱

確認完 MX record 記錄存在, 能夠經過與 SMTP server 創建鏈接,來完成對 email 地址有效性的校驗。如上一步所示,MX records 通常會有多條(_有的 SMTP server 會設置 record 的權重值_),SMTP server 的地址是: MX 記錄 + SMTP Relay 端口。 Ping 收件人郵箱的原理是使用 SMTP ,鏈接到其中有效的 SMTP server,並請求收件人地址,請求後 server 會有響應, 根據響應信息來判斷地址是否存在。

若是 SMTP server 響應 250 OK, 那麼這個 email 地址是可能就是一個有效地址;若是返回 550-5.1.1 相似錯誤那麼就是一個無效的地址。

example@aftership.com 這個 email 地址爲例, 下面是一個完整的 SMTP 鏈接的驗證過程。
image

首先 telnet 連上收件人的 SMTP server, 經過 ehlo 標識發件人的身份,mail 設置 email 的發件人,最後 rcpt 設置 email 的收件人, rcpt只能設置 SMTP domain 的 email 地址, 不然分類器(SMTP rewriter)會重寫郵件中的電子郵件地址,使其與主 SMTP 地址相匹配 。若是 rcpt 沒有拒絕該請求,代表 SMTP server 校驗經過該地址,將會把收件人添加到郵件列表。下圖是一張使用 SMTP 協議發送 email 的全流程圖:
image
SMTP Ping 收件人地址的方法,是整個 email 地址校驗過程可能最有效的一環,SMTP server 能幫你確認收件人是否存在和可達。須要注意到這裏所說的「可能」,好比 example@aftership.com實際上是一個無效的地址, rcpt 響應250,email 地址不必定是可達的。

這裏又涉及一個概念,是 Catch-All Email Server,也叫 accept-all server,指那些被配置爲接受全部發送到 domain 的 email 的 SMTP server,不管指定的 email 地址是否存在。catch-all 會將錯誤地址重定向到一個通用的郵箱,以按期審查,可是帶來的問題是提升 bounce 率的風險且 catch-all 地址沒法被正確校驗。( 好比 Gmail 是一個 catch-all email server )
因此 Ping 收件人郵箱來校驗地址有效性, 須要確保對方的 SMTP server 是非 catch-all email server, rcpt命令響應250,才能說明地址是 deliverable,不然沒法校驗可達性。

更多關於連上 SMTP 服務器後校驗過程的其餘細節,好比爲何是用 rcpt 而不是其餘命令來驗證地址,能夠參考 Email box pinging

何時須要校驗 email 地址

校驗 email 地址能夠不是一個常常性的過程, 建議有下面幾種狀況時必須進行校驗:

  1. 新增的 email 地址: 正如上面提到的, 在進行 marketing campaign 時必須對 contacts 新增的收件人列表校驗 email 地址,過濾無效和非法收件人帳號
  2. 超過一個月未從新校驗過的 email 地址
  3. bounce 率達到或者超過 2%: 設置 bounce 率閾值來確保郵件送達率, 提升 sender 的 reputation
  4. 統計到的 email 事件,email 被打開的機率比較低

本地驗證 emil 地址 vs 使用第三方 email 驗證服務

通過以上步驟來完整地校驗 email 列表,哪怕只有一個地址的驗證也要多花很多時間。可是也能夠沒必要進行手動驗證,由於有許多第三方的 email 校驗服務,通常有提供 API 來完成對地址的校驗。調研了幾個相似服務(好比 emailchecker),它們提供的功能主要包括如下幾點:

  1. domain 校驗
  2. 單個 email 地址校驗
  3. 批量 email 地址校驗
  4. 語法檢查
  5. SMTP 校驗 (Ping收件人郵箱)
  6. 提供校驗 API
  7. bounce email 檢測
  8. GDPR 數據保護

因此這兩種驗證方案哪個是更好的選擇呢?本地驗證 email 地址無疑是首選, 由於自行校驗其實更快,更好地支持批量校驗郵件列表;要注意的是不少較好的第三方驗證服務是付費的,在線驗證時須要確認服務是否有 GDPR 數據保護以確保不會與第三方共享用戶我的數據,或者存在安全問題,可是第三方校驗不會有各類限制(多數 ISP 禁止在 25 端口上創建出站鏈接),且不存在影響 IP 段 和域名 reputation 的風險。

email-verifier

若是是本地驗證 email 地址,目前社區其實有一些開源的驗證 email 地址的工具, 其中 stars 數最可能是 trumail 項目,它提供了地址校驗 API。可是這個項目有兩個問題, 一是校驗慢,性能有些問題;二是不支持 disposable domain 的校驗,且該項目 archived, 已再也不維護。

在開發和維護 Messages Platform 上,做爲平臺方,咱們除了對業務提供高可用、簡單易接入的 email 消息通道服務外,下降 bounce 率和提升郵件送達率也是咱們重要的指標之一。因此咱們須要有一個高效的郵件校驗服務,過濾非法 email 地址(平臺郵件平均發送量在1000+w封/月),以提升送達率。基於咱們的技術棧是 Go, 在調研了 git 社區其餘開源的 email 驗證工具後,發現 Go 項目對 email verifier 這一塊建設是相對缺失,暫時尚未一個既提供多維度的 email 檢查(包括 diposable domain, 和 Role Account 等)且校驗地址可達性的工具。

因爲 trumail 已再也不維護,因此咱們內部實現了一個新的 email 校驗庫 – email-verifier, 目前已經在線上環境上運行。對比 trumail, 校驗 email 地址的效率更加明顯,檢查維度更多。

相比於現有其餘的 email 地址校驗工具, 咱們提供高性能、多維度、高準確性的免費 email 地址校驗方案,來解決在不一樣場景下對 email 地址校驗的痛點問題。 期待 email-verifier 也能在更好地幫助到社區解決相似問題。

總結

本文主要從 bounce email 引入,詳細介紹瞭如何在不發送郵件狀況下來校驗 email 地址,同時給出合適時間點校驗 email 地址的幾個建議;對比本地校驗和第三方校驗服務二者的優缺點以及爲何咱們會選擇自建校驗服務的緣由。最後是咱們在這一過程當中,基於校驗原理孵化的一個檢測工具。

通常來講, Marketing Campaigns 展開以後,確定會遇到 bounce email 影響 campaigns 質量的問題,這個時候在發郵件前校驗地址有效性的優勢就不難理解:一是提升郵件送達率;二是維護和提升 sender 帳號的 reputation,對業務方和平臺方都是必要的。

參考

相關文章
相關標籤/搜索