نود Verifi Email در N8N
نود Verifi Email در N8N
نود Verifi Email برای اعتبارسنجی ایمیلها در ورکفلوهای n8n استفاده میشود تا قبل از ارسال ایمیل، ساخت کاربر، ثبتنام یا ورود اطلاعات به CRM، از درست بودن فرمت و (در بسیاری سرویسها) قابلتحویل بودن ایمیل مطمئن شوید. این کار باعث کاهش بانس (Bounce)، افزایش کیفیت لیدها و جلوگیری از ورود دادههای خراب به سیستم میشود.
معرفی نود در N8N
این نود معمولاً بهعنوان یک نود یکپارچهسازی (Integration) با سرویسهای اعتبارسنجی ایمیل (Email Verification) عمل میکند و یک یا چند آدرس ایمیل را بررسی کرده و نتیجه را به شکل داده ساختیافته برمیگرداند.
- کارکرد اصلی: بررسی اعتبار ایمیل (فرمت، دامنه، وضعیت تحویلپذیری، ریسکی بودن، Disposable بودن و… بسته به سرویس)
- دستهبندی نود: Integration / Action
- اهمیت در ورکفلوها: جلوگیری از ارسال به ایمیلهای نامعتبر، پاکسازی لیستهای ایمیل، افزایش نرخ تحویل (Deliverability) و کاهش هزینه ارسال/اعتبار سرویسهای ایمیل
موارد استفاده
1) اعتبارسنجی ایمیل قبل از ثبتنام
در فرم ثبتنام (مثلاً از طریق Webhook)، ایمیل کاربر را با Verifi Email چک کنید و فقط اگر وضعیت مناسب بود، کاربر را در دیتابیس یا سرویس عضویت ثبت کنید.
2) پاکسازی لیست ایمیل مارکتینگ
لیست ایمیلها را از Google Sheets/Airtable بخوانید، برای هر ردیف اعتبارسنجی انجام دهید و ایمیلهای Invalid/Disposable را برچسبگذاری یا حذف کنید.
3) بررسی ایمیل قبل از ارسال کمپین
قبل از ارسال از طریق SendGrid/Mailgun/SMTP، ایمیلها را اعتبارسنجی کنید و فقط موارد Safe را ارسال کنید تا نرخ Bounce کاهش یابد.
4) امتیازدهی به لیدها (Lead Scoring)
اگر ایمیل Corporate و قابلتحویل بود امتیاز بیشتر بدهید، اگر Free/Disposable بود امتیاز کمتر بدهید و نتیجه را در CRM ذخیره کنید.
ترکیب با نودهای دیگر برای ورکفلوهای عملی
- Webhook Trigger + Verifi Email + IF + Google Sheets (ثبت یا رد)
- Google Sheets (Read) + Split in Batches + Verifi Email + Set + Airtable/Notion (آپدیت وضعیت)
- CRM (HubSpot/Salesforce) + Verifi Email + IF + Slack (هشدار برای لیدهای مشکوک)
پارامترها و تنظیمات
نام دقیق فیلدها ممکن است بر اساس نسخه n8n و پیادهسازی نود/سرویس متفاوت باشد، اما ساختار رایج تنظیمات در نودهای Email Verification معمولاً شامل موارد زیر است.
1) Credentials (کلید دسترسی سرویس)
- نام پارامتر: Credentials / API Key
- نوع داده: Credential (String)
- توضیح: کلید API برای اتصال به سرویس Verifi Email یا سرویس اعتبارسنجی متصل
- مثال عملی: API Key = 123456abcdef
نکته: کلید API را فقط در Credentials ذخیره کنید و داخل فیلدهای متنی Workflow قرار ندهید.
2) Operation (عملیات)
- نام پارامتر: Operation
- نوع داده: Option
- توضیح: انتخاب نوع عملیات؛ رایجترین حالت Verify/Validate Email است
- مثال عملی: Operation = Verify
3) Email (ایمیل برای بررسی)
- نام پارامتر: Email
- نوع داده: String
- توضیح: آدرس ایمیل که باید اعتبارسنجی شود. بهتر است از Expression استفاده شود تا از آیتم ورودی خوانده شود.
- مثال عملی: {{$json.email}}
نکته فرمت: ایمیل باید بدون فاصله اضافی باشد. در صورت نیاز قبل از این نود از Function/Code یا Set برای trim و lowercase استفاده کنید.
4) Timeout / Max Wait (زمان انتظار پاسخ)
- نام پارامتر: Timeout / Max Wait
- نوع داده: Number
- توضیح: حداکثر زمان انتظار برای پاسخ سرویس، مخصوصاً وقتی بررسی DNS/MX یا SMTP-Handshake انجام میشود
- مثال عملی: Timeout = 10000 (میلیثانیه)
5) Validate Domain / MX Check (بررسی دامنه و رکوردهای ایمیل)
- نام پارامتر: Check MX / Validate Domain
- نوع داده: Boolean
- توضیح: بررسی وجود رکوردهای MX و قابلیت دریافت ایمیل توسط دامنه (بسته به سرویس)
- مثال عملی: Check MX = true
نکته: در برخی سرویسها این بررسی هزینه بیشتری دارد یا کندتر است.
6) Disposable Check (تشخیص ایمیلهای یکبارمصرف)
- نام پارامتر: Check Disposable
- نوع داده: Boolean
- توضیح: تشخیص ایمیلهای موقت مثل mailinator و سرویسهای مشابه
- مثال عملی: Check Disposable = true
7) Catch All Detection (تشخیص دامنههای Catch-all)
- نام پارامتر: Detect Catch-All
- نوع داده: Boolean
- توضیح: تشخیص دامنههایی که همه ایمیلها را قبول میکنند و اعتبار واقعی صندوق مشخص نیست
- مثال عملی: Detect Catch-All = true
نکته: Catch-all بودن الزاماً به معنی نامعتبر بودن ایمیل نیست، اما ریسک را بالا میبرد.
8) Batch/Multiple Emails (بررسی چند ایمیل)
- نام پارامتر: Emails / Batch
- نوع داده: Array یا String (Comma-separated) بسته به نود
- توضیح: امکان ارسال چند ایمیل در یک درخواست (اگر سرویس پشتیبانی کند)
- مثال عملی: Emails = [“a@domain.com”,”b@domain.com”]
نکته: اگر نود از Batch پشتیبانی نکند، از Split in Batches یا اجرای آیتمبهآیتم استفاده کنید.
9) Additional Fields (فیلدهای تکمیلی)
- نام پارامتر: Additional Fields
- نوع داده: Object
- توضیح: برخی سرویسها پارامترهای اضافی مثل Tag، Source، یا گزینههای سطح بررسی ارائه میدهند
- مثال عملی: verificationLevel = “strict”
ورودیها و خروجیها
ورودی (Input)
این نود معمولاً یک آیتم ورودی با فیلدی مثل email دریافت میکند. نمونه ورودی:
{ "email": "test.user@example.com", "leadId": 1024, "source": "signup-form"}خروجی (Output)
خروجی بسته به سرویس ممکن است متفاوت باشد، اما معمولاً شامل وضعیت نهایی و جزئیات بررسی است. نمونه خروجی رایج:
{ "email": "test.user@example.com", "result": "valid", "deliverable": true, "isDisposable": false, "isCatchAll": false, "mxFound": true, "domain": "example.com", "score": 0.92, "reason": null, "raw": { "providerResponse": "..." }}- result: مقدارهایی مثل valid/invalid/unknown/risky
- deliverable: آیا احتمال تحویلپذیری بالا است یا خیر
- score: امتیاز کیفیت (اگر سرویس ارائه دهد)
- reason: علت invalid/risky بودن (مثل invalid_format, no_mx, mailbox_not_found)
نکات پیشرفته و ترفندها
1) استانداردسازی ایمیل قبل از بررسی
قبل از Verifi Email از یک نود Set یا Code استفاده کنید تا ایمیلها تمیز شوند:
- حذف فاصلههای ابتدا/انتها (trim)
- تبدیل به lowercase
- حذف کاراکترهای غیرمجاز
2) استفاده از IF برای مسیرهای مختلف
خروجی را با IF شاخهبندی کنید:
- اگر result = valid و deliverable = true → ادامه ثبتنام/ارسال ایمیل
- اگر isDisposable = true → رد کاربر یا درخواست ایمیل سازمانی
- اگر result = unknown → قرار دادن در صف بررسی دستی یا تلاش مجدد
3) کنترل نرخ درخواستها (Rate Limit) با Split in Batches و Wait
برای لیستهای بزرگ، درخواستها را دستهای انجام دهید و بین دستهها Wait قرار دهید تا به محدودیت API برخورد نکنید.
4) ذخیره نتیجه و جلوگیری از تکرار بررسی
اگر یک ایمیل قبلاً بررسی شده، نتیجه را در دیتابیس/Sheets ذخیره کنید و با یک مرحله Lookup از تکرار درخواست جلوگیری کنید. این کار هزینه و زمان را کاهش میدهد.
5) ساخت امتیاز (Scoring) سفارشی
با یک Function/Code یا Set میتوانید امتیاز داخلی بسازید:
- valid + deliverable: +10
- catch-all: +2
- free provider: +1
- disposable یا invalid: -10
محدودیتها و خطاها
محدودیتها
- برخی سرویسها نمیتوانند با قطعیت وجود mailbox را تایید کنند (بهخصوص در دامنههای Catch-all یا سرورهایی که پاسخ SMTP را محدود میکنند).
- بررسیهای عمیق (SMTP/MX) ممکن است کند باشد و به Timeout بخورد.
- ممکن است برای ایمیلهای خاص نتیجه unknown/risky برگردد که نیازمند تصمیمگیری در منطق ورکفلو است.
- در Batchهای بزرگ احتمال Rate Limit یا هزینه بالا وجود دارد.
خطاهای رایج و راهحلها
- 401/403 Unauthorized: API Key اشتباه است یا دسترسی محدود شده؛ Credentials را بررسی کنید و مطمئن شوید کلید فعال است.
- 429 Too Many Requests: محدودیت نرخ؛ از Split in Batches و Wait استفاده کنید یا همزمانی (Concurrency) را کاهش دهید.
- Timeout / ETIMEDOUT: زمان انتظار کم است یا سرویس کند؛ Timeout را افزایش دهید و در صورت نیاز فقط فرمت/MX را چک کنید.
- Invalid email format: داده ورودی تمیز نیست؛ قبل از نود ایمیل را trim کنید و از Expression درست (مثل {{$json.email}}) استفاده کنید.
- unknown/risky زیاد: دامنهها Catch-all هستند یا سرویس محدودیت دارد؛ منطق تصمیمگیری را بر اساس score/reason پیادهسازی کنید.
ایده ها
- سیستم تایید کیفیت لیدها: ورودی از فرم وب، بررسی ایمیل، و ثبت فقط لیدهای قابلتحویل در CRM.
- پاکسازی خودکار لیست خبرنامه: بررسی دورهای ایمیلهای لیست و غیرفعال کردن موارد invalid/disposable.
- کنترل کیفیت داده در تیم فروش: هر لید جدید قبل از Assign شدن به Sales با Verifi Email ارزیابی و امتیازدهی شود.
- فیلتر ضدتقلب برای ثبتنامها: ترکیب نتیجه Disposable/Catch-all با IP/Geo (از نودهای دیگر) برای تشخیص ثبتنامهای مشکوک.
- سیاست ارسال هوشمند: اگر risky بود بهجای ارسال فوری، وارد جریان warm-up یا ارسال با حجم کمتر شود.