n8n 開源範本：批次電子郵件驗證，整合 AI 代理工具

我開發了一組四個 n8n 範本，專為一項任務設計：在電子郵件進入自動化序列、客戶關係管理系統（CRM）或交由代理人處理之前，檢查其是否值得寄送。

這些範本包括「Google 試算表潛在客戶清單」，它會讀取尚未驗證的列，進行批次驗證，並將狀態和分數寫回。重複執行時只會處理新行，因此可以安全地排程。

「冷郵件前清理 CSV」範本，讓您上傳來自 Apollo、Instantly 或 HubSpot 的匯出檔案，並獲得三個清單：send_safe（安全寄送）、review（待審核）和 drop（捨棄）。灰名單（Greylisted）的地址會等待並重試一次，而不是直接丟棄。

「註冊 webhook」範本會回傳 allow（允許）、review（審核）或 block（封鎖），其政策設定在單一的 Code 節點中，您可以自行調整鬆緊。而「AI 代理工具」則是一個 AI 代理，將驗證器作為其唯一的工具，並透過系統提示詞告知每個結果的意義以及應如何處理。

有些細節比預期花費更多時間處理。結果是透過電子郵件地址而非行序來匹配的。驗證器會按網域將地址分組，因此回傳時順序會改變；如果按位置匹配，會悄悄地將錯誤的判斷寫入錯誤的行。

「未知」和「無法投遞」的結果是分開處理的。「我們無法查明」（灰名單、逾時）並不等同於「此郵箱已失效」，將它們合併會導致刪除真實的聯絡人。Gmail、Outlook、Yahoo 和 iCloud 在 SMTP 階段會接受任何地址，因此這些地址會被標記為 risky（有風險）或 free_provider_unverifiable（免費供應商無法驗證），而非錯誤的「有效」。全面接收網域（catch-all domains）也是如此。

每個記錄都具有相同的結構：狀態始終是四個值之一，並且所有 11 個檢查鍵始終存在。您的 Code 節點中不會散佈著 ?? false 這樣的判斷。所有功能都使用核心的 HTTP Request 節點（而非社群節點）和 Header Auth 憑證，因此 JSON 中不會包含任何機密資訊。所有四個範本都包含中文版本。

此外，儲存庫中還包含一個 OpenAPI 檔案（可匯入 Dify、Coze、GPT Actions）、MCP 配置和 llms.txt。聲明：這些範本採用 MIT 授權，但它們會呼叫我在 Apify 上建立並運行的電子郵件驗證 Actor，該服務是按驗證地址數量付費的（提供免費方案）。

儲存庫連結：GitHub - sumitrmardy/email-verifier-api: Bulk email verification API for n8n, AI agents & MCP，SMTP, MX, catch-all, disposable. Schema-stable JSON, never null. EN / 中文 · GitHub。

歡迎提供回饋，特別是來自使用不同 n8n 版本、節點匯入方式可能不同的人。這是我最想聽到的部分。