امنیت

ممیزی تحویل‌پذیری ایمیل: چرا ایمیل‌ها به اسپم می‌روند؟

ایمیل‌های تراکنشی به اسپم می‌روند؟ با ممیزی تحویل‌پذیری ایمیل، رکوردهای DNS، گرم کردن دامنه و خواندن هدر ایمیل ردشده را قدم‌به‌قدم بررسی کنید.

امنیت

ایمیل تراکنشی مشتری را فرستادید، لاگ SMTP می‌گوید 250 OK، ولی مشتری می‌گوید چیزی ندیده. یا بدتر: فرم بازیابی رمز عبور کار نمی‌کند و کاربر فکر می‌کند سایت خراب است. اینجا مشکل ارسال نیست؛ مشکل تحویل پذیری ایمیل است. سرور شما پیام را تحویل داده، اما سرور گیرنده آن را در صندوق اسپم انداخته یا کلاً رد کرده. تا وقتی این تفاوت را نپذیرید، هر تغییری در کد بی‌فایده است.

اول بفهمید ایمیل کجا مرده است

قبل از هر کاری، باید بفهمید پیام در کدام مرحله از زنجیره گم شده. سه حالت داریم و درمان هرکدام کاملاً متفاوت است:

  • رد شده (Bounce): سرور گیرنده با کد 5xx جواب داده. این را در لاگ MTA خودتان می‌بینید.
  • پذیرفته ولی اسپم شده: کد 250 گرفته‌اید اما پیام در Junk است. اینجا مشکل اعتبار است، نه ارسال.
  • پذیرفته و گم شده: نادر است ولی وقتی گیرنده فیلتر داخلی سازمانی دارد رخ می‌دهد.

برای حالت دوم، تنها راه مطمئن شدن این است که یک صندوق پستی واقعی روی Gmail و Outlook بسازید و به آن تست بفرستید. ابزارهای «تست اسپم» که فقط امتیاز می‌دهند گمراه‌کننده‌اند؛ آن‌ها رفتار واقعی گیرنده را شبیه‌سازی نمی‌کنند.

رکوردهای DNS: جایی که بیشتر سایت‌ها می‌بازند

سه رکورد باید درست باشند و هر سه با یک دامنه هم‌راستا. اگر یکی نباشد، بقیه هم بی‌اثر می‌شوند.

SPF

یک رکورد TXT روی دامنهٔ فرستنده. ساده‌ترین شکل درستش این است:

v=spf1 include:_spf.google.com include:spf.servername.ir -all

نکتهٔ مهم: -all یعنی هر سروری که در لیست نیست صریحاً رد شود. خیلی‌ها ~all می‌گذارند که فقط «نرم» رد می‌کند و اسپمرها از همین استفاده می‌کنند. اگر مطمئنید همهٔ منابع ارسال را می‌شناسید، -all بگذارید.

اشتباه رایج: دو رکورد SPF جدا روی یک دامنه. استاندارد می‌گوید در این حالت نتیجه permerror است و گیرنده‌های سختگیر کلاً رد می‌کنند. با dig TXT example.com +short چک کنید که فقط یک رکورد v=spf1 ببینید.

DKIM

امضای رمزنگاری‌شده روی هدر پیام. کلید عمومی را در DNS می‌گذارید و سرور ارسال با کلید خصوصی امضا می‌کند. اگر DKIM نباشد، هر تغییری در مسیر پیام (مثل forward شدن) اعتبارش را از بین می‌برد. طول کلید را 2048 بگذارید؛ 1024 هنوز کار می‌کند ولی برخی گیرنده‌ها امتیاز منفی می‌دهند.

DMARC

رکوردی که به گیرنده می‌گوید با پیام‌های ناموفق در SPF و DKIM چه کند:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100

همیشه با p=none شروع کنید و گزارش‌ها را چند هفته بخوانید. اگر مستقیم p=reject بگذارید و یک منبع ارسال قدیمی جا مانده باشد، همان روز ایمیل تراکنشی‌تان می‌خوابد. بعد از اینکه گزارش‌ها نشان داد همهٔ منابع تحت کنترل‌اند، به quarantine و بعد reject بروید.

گرم کردن دامنهٔ تازه: چیزی که همه دست‌کم می‌گیرند

دامنهٔ نو یا IP نو اعتبار ندارد. اگر روز اول ۵۰۰۰ ایمیل بفرستید، حتی با SPF و DKIM کامل، احتمال زیادی دارد که به اسپم برود. گیرنده‌ها به الگوی ارسال نگاه می‌کنند، نه فقط به رکوردها.

یک برنامهٔ عملی: روز اول ۵۰ ایمیل، روز دوم ۱۰۰، و هر روز حدود ۱.۵ برابر کنید تا به حجم واقعی برسید. این کار دو تا سه هفته طول می‌کشد. اگر عجله دارید، از یک سرویس ارسال تراکنشی معتبر استفاده کنید که IP مشترک با شهرت خوب دارد؛ هزینه‌اش بیشتر است ولی زمان راه‌اندازی را از سه هفته به چند ساعت می‌رساند.

اینجا اشتباه می‌کنند: تیم فنی دامنه را گرم می‌کند ولی همزمان روی همان IP ایمیل مارکتینگ انبوه می‌فرستد. نتیجه این است که شهرت IP در همان هفتهٔ اول می‌سوزد و بعد از آن هیچ ایمیلی، حتی تراکنشی، تحویل نمی‌شود. ارسال تراکنشی و تبلیغاتی را روی دامنه و IP جدا نگه دارید. این تفکیک از هر تنظیم دیگری مهم‌تر است.

حلقهٔ بازخورد و گزارش شکایت

وقتی کاربری روی «گزارش اسپم» می‌زند، گیرنده‌های بزرگ این را از طریق FBL (Feedback Loop) به فرستنده اطلاع می‌دهند. اگر ثبت‌نام نکرده باشید، این سیگنال را نمی‌بینید و فقط می‌بینید که نرخ تحویل کم شده.

برای Gmail از Postmaster Tools استفاده کنید و برای Outlook از SNDS. آستانهٔ شکایت زیر ۰.۱٪ است؛ بالای ۰.۳٪ معمولاً به مشکل جدی می‌خورید. اگر نرخ شکایت بالا رفت، اولین کار این است که لیست را پاک‌سازی کنید، نه اینکه متن ایمیل را عوض کنید.

رکورد rua در DMARC هم گزارش‌های تجمیعی می‌فرستد. این گزارش‌ها XML هستند و خام‌شان خواندنی نیست؛ با یک ابزار پارسر آن‌ها را به جدول تبدیل کنید و هر هفته نگاه کنید کدام IP به نام دامنهٔ شما ایمیل می‌فرستد. بارها دیده‌ام که یک سرور قدیمی فراموش‌شده هنوز به نام دامنه ایمیل می‌فرستد و اعتبار کل دامنه را پایین می‌کشد.

خواندن هدر یک ایمیل ردشده

وقتی ایمیل به اسپم می‌رود، هدر کامل پیام همه‌چیز را می‌گوید. در Gmail روی پیام، منوی سه‌نقطه و بعد «Show original» را بزنید. دنبال این خطوط بگردید:

  • Authentication-Results: نتیجهٔ SPF، DKIM و DMARC را نشان می‌دهد. اگر spf=fail دیدید، مشکل DNS است.
  • Received: مسیر پیام. اگر تعداد هاپ‌ها غیرعادی زیاد است، یک رله ناشناس در مسیر هست.
  • X-Spam-Score یا X-Spam-Status: اگر گیرنده SpamAssassin دارد، امتیاز و دلیلش را می‌نویسد.

مثال واقعی از یک هدر مشکل‌دار:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=example.com;
       dkim=fail header.d=example.com;
       dmarc=fail (p=NONE sp=NONE) header.from=example.com

اینجا SPF پاس شده ولی DKIM رد شده. یعنی رکورد DNS درست است اما کلید خصوصی روی سرور با کلید عمومی در DNS نمی‌خواند. معمولاً بعد از مهاجرت سرور یا بازتولید کلید رخ می‌دهد و کسی یادش نمی‌آید رکورد را آپدیت کند. با opendkim-testkey -d example.com -s selector -vvv می‌توانید این را مستقیم تست کنید.

ابزارها و بررسی‌های دوره‌ای

یک ممیزی کامل را می‌توانید در نیم ساعت انجام دهید اگر بدانید کجا را نگاه کنید. برای بررسی رکوردهای DNS و رزولوشن از ابزارهای بررسی DNS و شبکه استفاده کنید و نتیجه را با گزارش DMARC خودتان مقایسه کنید. اگر سرور ارسال‌تان روی زیرساخت خودتان است، مطمئن شوید که IP در هیچ بلاک‌لیست عمومی نیست؛ ابزارهای blacklist check این را در چند ثانیه می‌گویند.

نکته‌ای که کمتر به آن توجه می‌شود: اگر سایت‌تان هدف حملهٔ DDoS قرار بگیرد و سرور ارسال ایمیل هم روی همان زیرساخت باشد، افت عملکرد می‌تواند باعث timeout در تحویل و صف شدن پیام‌ها شود. در چنین شرایطی محافظت در برابر DDoS جدا از بحث امنیت، به پایداری تحویل ایمیل هم کمک می‌کند.

برای مستندسازی نتایج ممیزی و نگه‌داشتن سابقهٔ تغییرات رکوردها، یک دفترچهٔ ساده کافی است، ولی اگر تیم بزرگ است بهتر است این کار در چارچوب لاگ ممیزی انجام شود تا معلوم باشد چه کسی و کِی رکورد DKIM را عوض کرده.

پرسش‌های پرتکرار

چرا ایمیل‌های تراکنشی سایت من به اسپم می‌روند در حالی که SPF و DKIM درست است؟

درست بودن رکوردها شرط لازم است، نه کافی. سه دلیل رایج دیگر وجود دارد: شهرت پایین IP یا دامنهٔ تازه، نرخ بالای شکایت کاربران، و محتوای ایمیل که الگوهای اسپم دارد (لینک کوتاه‌شده، تصویر بزرگ بدون متن، subject تمام‌حروف بزرگ). اول هدر یک ایمیل واقعی را در Gmail باز کنید و Authentication-Results را بخوانید؛ اگر هر سه پاس بودند، مشکل اعتبار است نه تنظیمات.

گرم کردن دامنهٔ ایمیل چقدر طول می‌کشد؟

برای یک دامنهٔ کاملاً تازه با حجم ارسال متوسط، دو تا سه هفته زمان لازم است تا به حجم نهایی برسید. اگر حجم ارسال‌تان بالاست یا فوریت دارید، استفاده از سرویس ارسال با IP مشترک و شهرت تثبیت‌شده سریع‌تر است، ولی کنترل کمتری روی شهرت IP خواهید داشت.

تفاوت SPF و DKIM و DMARC در یک جمله چیست؟

SPF می‌گوید کدام سرورها مجاز به ارسال به نام دامنهٔ شما هستند، DKIM ثابت می‌کند پیام در مسیر دست‌کاری نشده، و DMARC تعیین می‌کند گیرنده با پیامی که این دو را پاس نکرده چه کند. هر سه باید روی یک دامنه تنظیم شوند تا اثر داشته باشند.

آیا باید ارسال تراکنشی و خبرنامه را روی یک دامنه بفرستم؟

نه. این کار رایج‌ترین اشتباهی است که در ممیزی تحویل پذیری ایمیل می‌بینم. اگر یک کمپین خبرنامه نرخ شکایت بالا بگیرد، شهرت همان دامنه آسیب می‌بیند و ایمیل بازیابی رمز عبور هم به اسپم می‌رود. دامنهٔ اصلی را برای تراکنشی نگه دارید و خبرنامه را روی یک زیردامنه با IP جدا بفرستید.

قدم بعدی مشخص است: یک ایمیل تست به یک صندوق Gmail بفرستید، هدر کاملش را باز کنید و خط Authentication-Results را بخوانید. اگر هر سه پاس بود، سراغ گزارش DMARC و نرخ شکایت بروید؛ اگر یکی رد شده بود، همان را اول درست کنید. بقیهٔ کارها بعد از این مرحله معنا پیدا می‌کنند.

پشتیبانی سرورنت

تیم فنی و تحریریه‌ی سرورنت — تخصص در زیرساخت، شبکه و میزبانی وب.

خدمات امنیت
اشتراک‌گذاری:

دیدگاه‌ها ۰

هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!

دیدگاه خود را بنویسید

سرویس مرتبط

خدمات امنیت

تست نفوذ توسط متخصصان دارای مدرک OSCP، امن‌سازی زیرساخت و مانیتورینگ امنیتی ۲۴ ساعته — گزارش‌هایی که مدیر می‌فهمد و مهندس اجرا می‌کند.