نقشه راه Nylas برای عبور ایمیل‌های عامل‌های هوش مصنوعی از فیلتر اسپم

اگر امروز یک عامل هوشمند را برای ارسال ایمیل به هزاران کاربر فعال کنید، احتمالاً نیمی از پیام‌ها مستقیماً به پوشه اسپم می‌روند. این اتفاق حتی زمانی رخ می‌دهد که محتوای پیام کاملاً درست باشد و عامل هیچ اشتباهی نکرده باشد؛ چراکه مشکل از منطق مدل نیست، بلکه از «اعتبار» دامنه‌ای است که پیام از آن ارسال می‌شود. دامنه‌های کاملاً جدید که هیچ سابقه ارسال ندارند، اغلب توسط ارائه‌دهندگان صندوق پستی (Mailbox Providers) به عنوان اسپمر شناسایی می‌شوند. ارائه‌دهندگان با دامنه‌های ناشناسی که ناگهان حجم زیادی از ایمیل‌ها را ارسال می‌کنند، دقیقاً همان‌طور رفتار می‌کنند که با اسپمرهای حرفه‌ای برخورد می‌کنند.

برای جلوگیری از افتادن پیام‌های عامل‌های هوشمند در پوشه اسپم، Nylas یک توالی تحویل مشخص شامل احراز هویت، کنترل سرعت ارسال (Pacing) و پایش لحظه‌ای را معرفی کرده است. طبق راهنمای عملی منتشرشده در ۲۲ ژوئن ۲۰۲۶، این فرآیند مستلزم اثبات مالکیت دامنه و شبیه‌سازی دقیق الگوهای ارسال انسانی است تا سیستم‌های امنیتی ارائه‌دهندگان را تحریک نکند.

در واقع، پیاده‌سازی صندوق پستی برای یک عامل (Agent) تنها یک فراخوانی API ساده نیست، بلکه مدیریت اعتبار دامنه‌ای است که شما مالک آن هستید. تحویل ایمیل (Deliverability) در واقع فرآیند اثبات این موضوع است که ایمیل واقعاً متعلق به شماست، ارسال آن با سرعتی است که ارائه‌دهندگان به آن اعتماد کنند و تماشای سیگنال‌هایی است که نشان می‌دهد آیا گیرندگان واقعاً ایمیل شما را می‌خواهند یا خیر. از آن‌جا که یک «حساب عامل» (Agent Account) از دامنه‌ای ارسال می‌کند که شما مالک آن هستید، جایگاه این صندوق ورودی در صندوق‌های گیرنده (Inbox Placement) مستقیماً بر عهده شماست و باید مانند هر ایمیل سازمانی دیگری در شرکتتان مدیریت شود.

این چالش برای حساب‌های عامل‌محور بسیار شدیدتر است و تحویل ایمیل در این مدل‌ها به پنج عامل کلیدی وابسته است: احراز هویت (Authentication)، تنظیم DMARC، گرم کردن حجم ارسال (Volume Warming)، پایش بازگشت‌ها (Bounce Monitoring) و ردیابی شکایت‌ها (Complaint Tracking). برای توسعه‌دهندگان، این به معنای تغییر تمرکز از منطق داخلی عامل به اعتبار زیرساخت‌های ارتباطی است. اینC مقاله یک راهنمای عملی (Playbook) برای رساندن عامل به صندوق ورودی و نگه داشتن آن در آنجاست که از هر دو روش HTTP API برای بک‌اند و Nylas CLI برای ترمینال استفاده می‌کند. این رویکرد زیرساختی، مکمل پیشرفت‌های دیگر در حوزه توسعه است؛ برای مثال، استک اورفلو نیز اخیراً با معرفی یک API جدید برای عامل‌ها تلاش کرده تا با ایجاد حافظه مشترک، جلوی تکرار اشتباهات این مدل‌ها بگیرد.

زیربنای احراز هویت

احراز هویت اولین سد است؛ اگر سرورهای گیرنده نتوانند تأیید کنند پیام متعلق به شماست، هیچ‌کدام از تلاش‌های بعدی نتیجه نمی‌دهد. Nylas از DKIM (DomainKeys Identified Mail) استفاده می‌کند تا یک امضای رمزنگاری‌شده به پیام اضافه کند. این امضا ثابت می‌کند که پیام در مسیر انتقال تغییر نکرده و واقعاً از دامنه شما ارسال شده است. هم‌زمان، SPF (Sender Policy Framework) به زیرساخت‌های ارسال اجازه می‌دهد تا از طرف شما پیام بفرستند و تأیید می‌کند که سرور ارسال‌کننده مجاز است.

هر دو پروتکل DKIM و SPF پیش از آنکه یک دامنه سفارشی بتواند حساب‌های کاربری را میزبانی کند، تأیید می‌شوند؛ بنابراین یک دامنه تأیید شده برای حساب عامل، پیشاپیش از نظر DKIM و SPF احراز هویت شده است.

توسعه‌دهندگان می‌توانند ثبت و تأیید دامنه را از طریق Nylas CLI مدیریت کنند. توالی دستورات زیر برای برقراری ارتباطات احراز هویت استفاده می‌شود:

• nylas domains create agents.yourcompany.com (ثبت دامنه در سیستم)
• nylas domains dns agents.yourcompany.com (نمایش رکوردهایی که باید در DNS منتشر شوند)
• nylas domains verify agents.yourcompany.com (شروع فرآیند تأیید پس از انتشار رکوردها)

همین جریان کاری از طریق Manage Domains API نیز قابل اجرا است که در پاسخ، میزبان (Host)، نوع (Type) و مقدار (Value) هر رکورد را برای کپی کردن در پنل ارائه‌دهنده DNS برمی‌گرداند. در حالی که تأیید دامنه معمولاً در چند دقیقه انجام می‌شود، انتشار DNS بسته به مقدار TTL رکورد می‌تواند تا ۲۴ ساعت زمان ببرد.

لایه‌بندی حفاظتی با DMARC

پس از تنظیم DKIM و SPF، پروتکل DMARC (Domain-based Message Authentication, Reporting, and Conformance) لایه نهایی برای جلوگیری از جعل هویت (Spoofing) است. DMARC به سرورهای گیرنده دستور می‌دهد که در صورت شکست پیام در احراز هویت (در حالی که ادعا می‌کند از دامنه شماست)، چه واکنشی نشان دهند و همچنین گزارش دهد که چه کسی در حال ارسال پیام به نام شماست. DMARC بر پایه DKIM و SPF بنا شده است؛ یک پیام زمانی از فیلتر DMARC عبور می‌کند که یا SPF یا DKIM تأیید شوند و با دامنه موجود در آدرس قابل مشاهده «From» همراستا (Aligned) باشند.

از آن‌جا که یک حساب عامل با کلید DKIM دامنه شما امضا می‌شود و از دامنه تأیید شده شما ارسال می‌گردد، همراستاسازی به محض انتشار رکورد DMARC فعال می‌شود. چون DMARC یک رکورد مجزا در DNS است و از طریق API مدیریت نمی‌شود، باید به صورت دستی اضافه گردد. Nylas توصیه می‌کند یک رکورد TXT در _dmarc.yourdomain.com اضافه کنید و آن را در سه مرحله عملیاتی کنید تا از مسدود شدن ایمیل‌های قانونی جلوگیری شود:

• پایش (p=none): از رکورد v=DMARC1; p=none; rua=mailto:[email protected]; pct=100 استفاده کنید. ایمیل‌ها به صورت عادی تحویل می‌شوند، اما ارائه‌دهندگان گزارش‌های تجمیعی را به آدرس rua می‌فرستند تا تأیید شود ایمیل‌های عامل به درستی احراز هویت و هم‌راستا شده‌اند.
• قرنطینه (p=quarantine): پس از اینکه گزارش‌ها پاک و بدون خطا بودند، ایمیل‌های شکست‌خورده را به اسپم بفرستید. این مرحله را با pct=25 شروع کنید تا سیاست تنها روی یک‌چهارم ایمیل‌های مشکوک اعمال شود و سپس آن را به ۱۰۰٪ برسانید.
• رد کردن (p=reject): وضعیت نهایی که در آن سرورهای گیرنده هر پیامی را که در DMARC شکست بخورد، کاملاً رد می‌کنند و اجازه ورود به صندوق را نمی‌دهند.

توسعه‌دهندگان باید برای هر مرحله، چند هفته گزارش‌های پاک دریافت کنند و سپس سیاست را سخت‌گیرانه‌تر کنند. بسیار حیاتی است که آدرس rua به صندوق پستی یا سرویس مانیتورینگی متصل باشد که واقعاً چک شود.

برنامه چهار هفته‌ای گرمایش دامنه

راه‌اندازی یک دامنه جدید نیازمند افزایش تدریجی حجم ارسال است تا اعتبار (Reputation) ایجاد شود. یک دامنه کاملاً جدید هیچ اعتباری ندارد، بنابراین هرگونه جهش ناگهانی در تعداد پیام‌ها شبیه به رفتار اسپمرها به نظر می‌رسد و فیلتر می‌شود. گرم کردن (Warming up) یعنی افزایش تدریجی حجم ارسال طی تقریباً چهار هفته، در حالی که گیرندگان واقعی ایمیل‌ها را باز کرده و به آن‌ها پاسخ دهند. از آن‌جا که اعتبار بین دامنه‌ها منتقل نمی‌شود، هر دامنه سفارشی جدید باید طبق برنامه گرمایش خود پیش برود.

Nylas یک مسیر صعودی برای رسیدن به هدف روزانه ۵۰۰ تا ۱۰۰۰ پیام پیشنهاد می‌کند، به گونه‌ای که حجم ارسال هر روز ۱۰ تا ۲۰ درصد رشد کند:

• هفته اول: ۵ تا ۱۵ ایمیل در روز. ارسال را بسیار پایین شروع کنید و روی گیرندگانی تمرکز کنید که تعامل بسیار بالایی دارند.
• هفته دوم: ۳۰ تا ۷۵ ایمیل در روز. حجم ارسال را به طور پیوسته افزایش دهید.
• هفته سوم: ۱۵۰ تا ۳۰۰ ایمیل در روز. به سمت حجم‌های متوسط حرکت کنید.
• هفته چهارم: ۵۰۰ تا ۱۰۰۰+ ایمیل در روز. رسیدن به ظرفیت کامل هدف.

دو عامل به اندازه اعداد حیاتی هستند: زمان‌بندی و تعامل. عامل‌ها نباید تمام پیام‌ها را یک‌باره بفرستند (Burst)، بلکه باید ارسال‌ها را در طول ساعات کاری پخش کنند و بین پیام‌ها تأخیری ایجاد کنند تا الگوهای طبیعی انسانی شبیه‌سازی شود. علاوه بر این، پیام‌ها فقط باید برای کسانی ارسال شوند که انتظار دریافت ایمیل را دارند. باز کردن ایمیل، کلیک روی لینک‌ها و به‌ویژه «پاسخ دادن»، قوی‌ترین سیگنال‌های مثبتی هستند که یک دامنه می‌تواند تولید کند.

یک ارسال گرمایشی، همان ارسال عادی حساب عامل است. این کار از طریق API یا ترمینال به شرح زیر انجام می‌شود:

nylas email send --to [email protected] --subject "Your booking confirmation" --body "Thanks for booking with us. Here are your details..."

پایش از طریق Webhookهای تحویل

تله‌متری لحظه‌ای برای حفظ حساب ضروری است؛ شما نمی‌توانید چیزی را که نمی‌بینید مدیریت کنید. توسعه‌دهندگان باید روی چهار وب‌هوک (Webhook) تحویل خاص در Nylas ثبت‌نام کنند تا دقیقاً بدانند برای پیام‌های خروجی چه اتفاقی می‌افتد:

• message.delivered: تأیید می‌کند که پیام به سرور گیرنده رسیده است.
• message.bounced: نشان‌دهنده بازگشت سخت (Hard Bounce) است (مثلاً آدرس ایمیل وجود ندارد).
• message.complaint: نشان می‌دهد که گیرنده ایمیل را به عنوان اسپم علامت‌گذاری کرده است.
• message.rejected: زمانی فعال می‌شود که یک پیوست (Attachment) حاوی ویروس باشد.

از طریق CLI، تنها یک دستور برای ثبت این محرک‌ها کافی است:
nylas webhook create --url https://yourapp.example.com/webhooks/nylas --triggers message.delivered,message.bounced,message.complaint,message.rejected

همین اشتراک را می‌توان از طریق API با یک درخواست POST /v3/webhooks شامل trigger_types و callback_url ایجاد کرد. ثبت این سیگنال‌ها در تله‌متری داخلی، تنها راه برای ماندن در محدوده آستانه‌هایی است که باعث توقف ارسال (Pause) نمی‌شوند.

آستانه‌های اعتبار و اجرای محدودیت‌ها

شرکت Nylas نرخ بازگشت (Bounce Rate) و نرخ شکایت (Complaint Rate) هر حساب عامل را به صورت جاری (Rolling) ردیابی می‌کند. نرخ بازگشت از تقسیم بازگشت‌های سخت بر حجم ارسال اخیر به دست می‌آید. نرخ شکایت نیز از تقسیم گزارش‌های اسپم بر حجم اخیر محاسبه می‌شود و فقط در مورد دامنه‌های گیرنده‌ای شمارش می‌گردد که شکایت‌ها را به فرستنده گزارش می‌دهند.

عبور از این آستانه‌ها منجر به وضعیت‌های زیر در حساب می‌شود:

آستانه نرخ بازگشت (Bounce Rate):

• زیر ۲٪: وضعیت سالم (ارسال عادی).
• ۵٪ یا بیشتر: تحت بررسی (ارسال ادامه دارد؛ اما بازگشت‌های مداوم منجر به توقف می‌شود).
• ۱۰٪ یا بیشتر: متوقف شده (ارسال‌های خروجی شکست می‌خورند تا زمانی که Nylas توقف را برطرف کند).

آستانه نرخ شکایت (Complaint Rate):

• زیر ۰.۱٪: وضعیت سالم (ارسال عادی).
• ۰.۱٪ یا بیشتر: تحت بررسی (ارسال ادامه دارد؛ اما شکایت‌های مداوم منجر به توقف می‌شود).
• ۰.۵٪ یا بیشتر: متوقف شده (ارسال‌های خروجی شکست می‌خورند تا زمانی که Nylas توقف را برطرف کند).

دقت کنید که آستانه شکایت بسیار پایین است؛ حتی چند گزارش معدود در یک حساب با حجم ارسال کم می‌تواند وضعیت را به «تحت بررسی» تغییر دهد. در حالی که وضعیت «تحت بررسی» برای اپلیکیشن خاموش است (خطایی نمی‌دهد)، وضعیت «متوقف شده» بازخوردی فوری در فراخوانی ارسال برمی‌گرداند.

تحلیل خطا در کد

وقتی محدودیت‌های اعتبار اجرا می‌شوند، درخواست‌های ارسال با کدهای وضعیت خاصی شکست می‌خورند که هر کدام نیاز به مدیریت متفاوتی دارند:

• 400 Bad Request: توقف ارسال به دلیل اجرای سیاست‌های اعتبار. ارسال را متوقف کرده و منبع بازگشت یا شکایت را شناسایی و اصلاح کنید.
• 403 Forbidden: دامنه فرستنده تأیید نشده است یا محدودیت سوءاستفاده (Abuse Restriction) اعمال شده است. تأییدیه را کامل کنید یا برای رفع مسدودیت با پشتیبانی تماس بگیرید. در مورد مسدودیت به دلیل سوءاستفاده، بدنه پاسخ دقیقاً عبارت send blocked by abuse restriction را برمی‌گرداند.
• 429 Too Many Requests: سقف نرخ ارسال (Rate Limit) برای هر حساب یا هر دامنه رد شده است. سرعت ارسال را کاهش داده و مجدداً تلاش کنید.

نکته کلیدی این است که توقف ناشی از اعتبار (Reputation Pause) به‌طور خودکار با گذشت زمان یا تایمر برطرف نمی‌شود. برای بازگشت به حالت عادی، باید با پشتیبانی تماس بگیرید و منبع بازگشت/شکایت و راهکار اعمال شده برای رفع آن را ارائه دهید. این موضوع با خطای 429 متفاوت است که به محض کاهش سرعت ارسال، برطرف می‌شود.

محدودیت‌های عملیاتی

علاوه بر اعتبار، عامل‌ها با سقف‌های سختگیرانه کوتای ارسال مواجه هستند که خطای 429 برمی‌گردانند. هر حساب عامل دارای یک سقف ارسال روزانه است: ۲۰۰ پیام در طرح رایگان، و در طرح‌های پولی به طور پیش‌فرض هیچ سقف روزانه‌ای وجود ندارد.

سازمان شما یک نرخ ارسال مشترک (Pooled Rate) در هر ثانیه دارد: اپلیکیشن‌های Sandbox مجموعاً ۱ درخواست در ثانیه و اپلیکیشن‌های Production مجموعاً ۵ درخواست در ثانیه مجاز هستند. همچنین، یک پیام حداکثر می‌تواند ۵۰ گیرنده (در مجموع To, CC و BCC) داشته باشد و حجم کل آن باید ۲۵ مگابایت یا کمتر باشد.

توسعه‌دهندگان باید آگاه باشند که دعوت‌نامه‌های تقویم (Calendar Invitations) نیز در سقف ارسال روزانه محاسبه می‌شوند. اگر حسابی از سقف عبور کند، رویداد تقویم ذخیره می‌شود اما دعوت‌نامه به‌صورت خاموش نادیده گرفته (Skip) می‌شود. برای جلوگیری از مشکلات، مخاطبان بزرگ را در گروه‌های ۵۰ نفره یا کمتر دسته‌بندی کنید و نرخ ارسال را زیر سقف مشترک نگه دارید تا در میانه فرآیند گرمایش، با خطاهای 429 مواجه نشوید.

استانداردهای پایداری بلندمدت

برای جلوگیری از سقوط اعتبار و حفظ سلامت حساب عامل، عادت‌های زیر توصیه می‌شود:

• اعتبارسنجی آدرس‌ها: پیش از ارسال، آدرس‌ها را اعتبارسنجی کنید و هر آدرسی را که قبلاً بازگشت سخت (Hard Bounce) داشته است، نادیده بگیرید. بازگشت‌های سخت سریع‌ترین راه برای توقف حساب هستند.
• احترام به لغو عضویت: درخواست‌های Unsubscribe را فوراً اجرا کنید. در آستانه بسیار پایین ۰.۱٪، نادیده گرفتن حتی چند درخواست بسیار هزینه‌بر است.
• اتصال به هر چهار محرک تحویل: تمام وب‌هوک‌های تحویل را فعال کنید و زمانی که نرخ بازگشت، شکایت یا رد (Rejected) بالا می‌رود، ارسال‌های خود را به‌طور دستی متوقف کنید؛ این کار به شما اجازه می‌دهد مشکل را در تله‌متری خود ببینید پیش از آنکه Nylas توقف سخت‌گیرانه اجرا کند.
• ثبات دامنه: دامنه «فرستنده» (From) باید با دامنه‌ای که حساب‌ها روی آن تأیید شده‌اند، کاملاً یکسان باشد تا همراستاسازی DMARC حفظ شود. توجه داشته باشید که در حالی که فوروارد کردن ایمیل باعث شکست SPF می‌شود، اما DKIM زنده می‌ماند و به همین دلیل DMARC پذیرش هر یک از این دو را کافی می‌داند.
• گرمایش مجزای هر دامنه: اعتبار بین دامنه‌ها منتقل نمی‌شود. بنابراین دومین دامنه‌ای که اضافه می‌کنید، بدون توجه به سوابق دامنه اول، از صفر شروع می‌کند.

این انضباط فنی، یک عامل هوشمند را از یک ریسک احتمالی اسپم به یک ابزار ارتباطی شرکتی قابل اعتماد تبدیل می‌کند. با اولویت‌بندی احراز هویت، لایه‌بندی DMARC در مراحل مختلف، گرم کردن دامنه طی چهار هفته و استفاده از چهار وب‌هوک تحویل برای اجرای منطق «توقف و کاهش سرعت»، توسعه‌دهندگان می‌توانند تضمین کنند که پیام‌های عامل آن‌ها به صندوق ورودی می‌رسد.

گام بعدی شما

• اگر از ایمیل‌های خودکار در عامل‌هایتان استفاده می‌کنید، ابتدا وضعیت رکوردهای SPF و DKIM دامنه خود را بررسی کنید.
• یک سیستم مانیتورینگ برای Webhookهای message.bounced و message.complaint ایجاد کنید تا پیش از مسدود شدن حساب، از وضعیت اعتبار مطلع شوید.
• برای هر دامنه جدید، یک جدول زمان‌بندی چهار هفته‌ای برای افزایش حجم ارسال (Warm-up) طراحی کنید.

اما مدیریت هویت‌های دیجیتال در مقیاس وسیع، چالش‌های پیچیده‌تری را در لایه DNS ایجاد می‌کند — به تحلیل ما درباره پروتکل‌های جدید احراز هویت در محیط‌های توزیع‌شده مراجعه کنید.