如何在 Make 中驗證電子郵件
Make 情境會在支撐行銷的表單、CRM 與電子郵件工具之間傳遞聯絡人，因此是攔截錯誤地址、避免擴散的最佳位置。透過 HTTP 模組，可在情境中途呼叫 VeriMails API，即時驗證每位聯絡人，再用 Router 把每個結果送到該去的地方。本指南將帶您逐步完成建置。
重點摘要
Make 情境設定檢查清單
把情境規劃成一道關卡：觸發資料進來，VeriMails 檢查電子郵件地址，再由 Router 篩選條件決定哪些可以繼續往下。
| 決策 | Make 設定 | 操作備註 |
|---|---|---|
| 觸發範圍 | 從最先接收聯絡人資料包的模組開始：表單監看、自訂 webhook、CRM 紀錄或試算表列。 | 在格式化或資料補充模組改變資料結構之前，先對應原始的電子郵件值。 |
| HTTP 請求 | 在觸發器之後加入 HTTP 模組，將電子郵件傳送到 VeriMails 端點，並把 API 金鑰存放在模組連線或帳號提供的安全憑證設定中。 | 請將 API 驗證呼叫放在任何建立訂閱者、潛在客戶或受眾成員的模組之前。 |
| Router 設計 | 建立一條給可送達聯絡人的路徑、一條給被拒聯絡人的路徑，以及一條處理非預期或空白狀態的備援路徑。 | Make 的各條路徑會分別篩選，因此請依結果為每條路徑命名，並在測試期間讓備援路徑保持可見。 |
| 暫留紀錄日誌 | 將無效、拋棄式與 Catch-all 聯絡人寫入試算表、資料儲存區或通知，並附上來源與原因欄位。 | 一份簡單的日誌就能讓雜訊多的潛在客戶來源一目了然，也為操作人員留下回溯紀錄。 |
| 啟用測試 | 在排程或啟用情境之前，先用能觸及每條路徑的範例資料包執行一次。 | 檢視情境歷程，就能看到解析後的 VeriMails 回應，以及處理該結果的路徑。 |
為什麼要驗證 Make 聯絡人
Make 串接了擷取與使用聯絡人資料的各個應用程式，正好位於驗證步驟最能發揮作用的位置。在情境中檢查地址，就能避免下游每個串接的應用程式繼承錯誤資料。
情境會把聯絡人推送到負責寄信和計費的系統
典型的 Make 情境會把新的表單填寫或 CRM 紀錄推送到電子郵件平台、廣告受眾或銷售工具。如果聯絡人無效，這個錯誤地址就會留在一個會向您收費、或會嘗試寄信給它的系統裡。在建立步驟之前放一個 VeriMails HTTP 模組，就能讓每個串接的應用程式保持乾淨。
表單與 webhook 觸發器錯誤最多
最常見的情境觸發器，例如新表單提交、webhook 資料與新增試算表列，同時也是電子郵件資料中雜訊最多的來源。錯字、棄用的地址和假資料不斷湧入。在觸發器輸出端加上驗證模組，就能在自動化的入口把它們攔下來。
即時驗證讓名單始終保持乾淨
在情境中驗證，代表每位聯絡人在流經的當下就完成檢查，而不是幾週後才在大量匯出時處理。名單持續保持乾淨，退信率沒有機會攀升，也不會寄信給一開始就錯誤的地址。
錯誤地址終究會退信並損害寄件者信譽
不論表單與收件匣之間隔了多少模組，無效地址最後都會退信。退信率超過百分之五，會讓整份名單的活動更容易被歸入垃圾郵件。在情境中加入 VeriMails 步驟，能從源頭消除這個風險，而不是讓電子郵件平台承擔後果。
VeriMails 檢查哪些項目
當 HTTP 模組為某位聯絡人呼叫 VeriMails API 時，VeriMails 會執行完整的一系列檢查，並回傳結構化結果供 Router 分流。每個地址的檢查方式如下：
語法驗證確認地址格式正確。 MX 與 DNS 記錄會被查詢，以確認網域存在且能夠收信。即時 SMTP 交握連線至收件郵件伺服器，確認該信箱確實可收信，過程中不會寄出任何郵件。 Catch-all 偵測找出會接收所有寄來地址的網域。拋棄式偵測標記臨時信箱網域。職能信箱偵測找出 info@、sales@、support@ 等通用地址。
VeriMails 回傳明確的驗證結果，回應速度快，足以直接嵌入即時情境中。Catch-all 網域會以明確的偵測結果回報，讓 Router 篩選條件能有意識地處理，而不是給一個模糊的分數。
Make 使用者的價格方案
即時驗證情境會在新聯絡人流經時扣除 VeriMails 點數，只需為實際驗證的地址付費。點數包每封電子郵件 $0.0019 起，10,000 點為 $19。高流量情境可選更大的點數包，最高 5 million 個地址、$1,499。
如果聯絡人流量穩定、偏好可預期的帳單，年繳方案以年度計費，每月 $12.50 起。每個新帳號註冊即送 100 點免費點數，無需信用卡，且點數永不過期，可以先建置並測試情境再決定。
流程圖解
依此流程，在 Make 情境中加入 VeriMails 作為品質關卡。
- 觸發範圍：在表單、試算表、webhook 或 CRM 模組建立聯絡人資料包後，立即對應電子郵件欄位。
- API 步驟：安全存放 VeriMails 金鑰，並將 API 回應欄位對應到情境中以進行分流。
- 結果處理：讓可送達的聯絡人走建立／更新路徑，並記錄無效或拋棄式聯絡人以供審查。
逐步說明
設定新聯絡人的觸發模組
建立新情境，並加入帶入聯絡人的觸發模組，例如監看表單提交模組、自訂 webhook、新的 CRM 紀錄或新增的試算表列。這個觸發器會輸出電子郵件地址，供情境後續步驟驗證與分流。
加入 HTTP 模組以呼叫 VeriMails API
加入 HTTP 模組，並設定它向 VeriMails 驗證端點發出請求。將觸發器的電子郵件欄位對應到請求中，加入 VeriMails API 金鑰進行驗證，並啟用回應解析，讓 Make 對應 JSON 驗證欄位供後續模組使用。
加入 Router 依結果分流
在 HTTP 模組之後放置 Router。Router 會將情境拆成多條路徑，每條都有自己的篩選條件。設定一條路徑只在 VeriMails 結果為可送達時執行，另加一條處理無法送達、拋棄式或 Catch-all 結果的路徑。也可以設定備援路徑，處理所有不符合條件的情況。
將可送達的聯絡人送到目標應用程式
在可送達路徑上，加入在電子郵件平台、CRM 或廣告受眾中建立或更新聯絡人的模組。只有已驗證、可送達的地址會走這條路徑，因此這些串接應用程式中的名單與受眾會自動保持乾淨。
處理錯誤地址並啟用情境
在不可送達路徑上，加入一個模組，把無法送達和拋棄式地址記錄到試算表，或發送通知以便審查。先用範例資料執行一次情境，確認每條路徑運作正確，再排程或啟用，讓每位新聯絡人都能即時驗證。
各種驗證結果的處理方式
每種驗證狀態都有明確路徑時，Make 情境最容易維運。不要讓缺漏或有風險的結果流入與已驗證聯絡人相同的模組。
- 可送達：送往 CRM、電子郵件工具或廣告受眾的建立／更新模組，並可選擇寫入驗證日期欄位。
- 無法送達：停止乾淨路徑，並將紀錄寫入封鎖名單或清理表。
- Catch-all：送往審慎審查路徑。這些聯絡人可能適合高價值的銷售跟進，但不應混入一般的活動寄送量。
- 拋棄式：排除在生命週期活動之外，並標記該潛在客戶來源以便檢查。
- 職能信箱：依工作流程目標分流。共用信箱可能適合營運類訊息，但不適合個人化開發信。
- 備援或錯誤：通知操作人員，並在請求或對應問題修正前停止寫入下游。