如何不寄信就驗證電子郵件地址

為什麼要不寄信就驗證

測試電子郵件地址最直覺的方式，就是寄一封信過去，看會不會退信。這雖然可行，卻是最糟的方法。退信只會在郵件已經抵達信箱服務商之後才發生，也就是說，這次失敗已經被計入您的寄件者信譽。如果用這種方式測試名單，您是以損害自身信譽為代價，才得知哪些地址有問題。而且您也無法悄悄測試，因為真實的收件人會收到真實的郵件。

不寄信驗證則徹底扭轉這個局面。它能在您把任何一次活動投入某個地址之前，就確認該地址能否收信。沒有郵件進入收件匣，沒有退信，信譽也毫髮無傷。之所以能做到，是因為郵件系統建立在一套讓伺服器彼此詢問的協定上，驗證工具可以提出這些問題，卻不真的完成投遞。

方法有好幾種，從簡單的格式檢查，到與收件伺服器的完整對話都有。每種方法各自回答問題的一部分，而了解每種方法能告訴您什麼、不能告訴您什麼，正是善用它們的關鍵。

方法 1：語法驗證

最快的檢查純粹看結構。電子郵件地址格式由一份名為 RFC 5322 的規範所定義，它明確規定合法地址的樣貌：本地部分、@ 符號與網域，以及哪些字元可以出現在哪些位置的規則。

語法驗證會依這些規則檢查地址。它能抓出沒有 @ 符號、含有空格或非法字元、網域缺漏或格式錯誤，以及本地部分違反規範的地址。它完全不需要網路連線，因此即時且免費，並能過濾掉相當比例的不良地址，其中大多是資料輸入時的簡單打字錯誤。

它的限制是根本性的。語法驗證只能證明地址格式正確，無法證明地址存在。valid.but.fake@gmail.com 這個地址的語法完全合法，卻幾乎可以肯定不是真實信箱。請把語法驗證當成第一道篩選，絕不能當成最終判定。

方法 2：網域與 MX 記錄查詢

下一步從地址轉向其網域。每個能收信的網域都會公布稱為 MX 記錄（Mail Exchanger 的縮寫）的 DNS 記錄。這些記錄指出代表該網域接收郵件的伺服器。

MX 查詢會向 DNS 查詢該網域的 MX 記錄。如果網域有有效的 MX 記錄，表示它已設定為可收信，且存在連線端點。如果網域沒有 MX 記錄，就完全無法收信，該網域上的每個地址不論拼字如何都無效。這一步非常擅長抓出失效網域，而隨著公司倒閉或更名，這類網域在舊名單上屢見不鮮。

它的限制在於，網域檢查作用的層級不對。確認 gmail.com 有 MX 記錄，只能告訴您 Google 可以收信，卻無法告訴您某個特定的 Gmail 信箱是否存在。網域與 MX 驗證可以縮小範圍，但無法判定個別地址。

方法 3：SMTP 檢查，也就是 Ping

這是真正在不寄信的情況下檢查特定信箱的方法。它常被稱為對電子郵件地址進行 ping，不過這個名稱容易誤導，因為它與網路診斷用的 ICMP ping 指令毫無關係。在電子郵件驗證中，ping 指的是與收件伺服器進行一段 SMTP 對話。

SMTP（Simple Mail Transfer Protocol，簡易郵件傳輸協定）是郵件伺服器之間互相傳遞郵件所用的語言。一般投遞會依照固定的指令順序進行。SMTP 檢查會走完這個順序，但提前一步停下。

運作方式如下。驗證工具會連線到收件人的郵件伺服器，也就是 MX 查詢找到的那台伺服器。它以 EHLO 或 HELO 互相問候並表明身分，以 MAIL FROM 指令宣告寄件者，接著發出 RCPT TO，指定要驗證的確切地址。收件伺服器會回應一個狀態碼。250 代表伺服器會接受寄往該地址的郵件；550 代表伺服器拒絕該地址，通常是因為信箱不存在。驗證工具讀取這個代碼後，就發出 QUIT 關閉連線。它從不發送 DATA 指令。DATA 是實際傳送郵件內文的步驟，由於對話在 DATA 之前就結束，因此不會投遞任何郵件。信箱已經檢查過，收件人卻什麼也沒收到。

這正是不寄信驗證的核心，也是真正的複雜之處開始的地方。

SMTP 檢查會遇到哪些問題

SMTP 檢查聽起來很確定，但幾種常見的伺服器行為，會讓原始的手動檢查變得不可靠。

Catch-all 網域

有些網域設定為 Catch-all（全收），也就是說，不論信箱是否存在，伺服器都會接受寄往該網域任何地址的郵件。Catch-all 伺服器對真實地址、拼錯的地址與完全隨機的地址，一律回傳 250。因此，對 Catch-all 網域執行 SMTP 檢查，無法在信箱層級得到任何確定的答案，因為答案永遠是「是」。要偵測 Catch-all，必須用一個隨機地址探測該網域，並觀察它是否同樣被接受。這是偵測，而不是品質分數，它告訴您該地址無法被個別確認。

灰名單（Greylisting）

有些伺服器在第一次遇到陌生寄件者時，會刻意回傳暫時性失敗代碼，預期正當的郵件伺服器會在稍後重試。簡單的檢查若把這個暫時性代碼當成永久失敗，就會把完全正常的地址誤標為無效。正確的處理方式是辨識出暫時性代碼，不把它當成最終答案。

探測封鎖

這是手動檢查真正的致命傷。Google 和 Microsoft 等大型服務商會監控來自單一 IP 位址的重複 SMTP 探測，並將其視為偵察行為，也就是垃圾郵件發送者用來挖掘有效地址的那種手法。它們的回應是直接封鎖發出探測的 IP。因此，如果您試著從自己的伺服器或 Telnet 工作階段手動執行 SMTP 檢查來驗證名單，只會得到少數幾個答案，接著就發現 IP 被封鎖，其餘檢查都因錯誤的原因而失敗。手動 SMTP 驗證無法擴充，在大量使用時根本行不通。

方法 4：專業驗證服務

上述每種方法各自驗證拼圖的一部分，單獨使用時也各有明顯弱點。專業驗證服務的存在，就是為了將這些方法整合執行、正確處理各種特殊情況，並以手動檢查無法達到的規模運作。

VeriMails 會對每個地址層層執行所有檢查。它依 RFC 5322 進行語法驗證、執行 MX 與 DNS 查詢，並進行前述的即時 SMTP 交握，全程不會投遞任何郵件。在此基礎上，它還加入 Catch-all 偵測，正確辨識全部接收（Accept-all）的網域，而不是誤報為有效；拋棄式網域偵測，標記臨時用完即丟的地址；以及職能信箱偵測，標記 info@ 和 support@ 這類地址。它能辨識灰名單與其他暫時性回應並正確分類，而不是硬判為無效。而且它從專為驗證設計的基礎架構執行，因此讓手動檢查敗下陣來的探測封鎖問題，不會擋住它。

成果就是完全不寄信也能完成的實用驗證。您可以使用 REST API 即時驗證單一地址，非常適合在註冊表單送出的當下進行檢查；也可以使用批次 CSV 驗證在活動前清理整份名單。價格每封最低 $0.0019，10,000 點只要 $19，最高 500 萬點 $1,499 的方案；年繳方案按年計費，每月 $12.50 起。每個帳號註冊即送 100 點免費點數，無需信用卡，且點數永不過期，您可以在不寄出任何真實郵件的情況下驗證真實名單，親自看看差別。

常見問題