فیلترهای ایمیل مایکروسافت که با هدف محافظت از کاربران در برابر پیام‌های مخرب طراحی شده‌اند، به‌طور غیرمنتظره‌ای در حال رد کردن پیام‌های تجاری و مشروع هستند. این اختلال که از اوایل نوامبر آغاز شده، باعث شده است ایمیل‌های ارسالی به سرویس‌هایی نظیر Outlook، Hotmail، Live و MSN در صورتی که دارای رکورد DMARC نباشند، با خطا مواجه شده و برگشت بخورند.
علت فنی اختلال: نبود پروتکل‌های احراز هویت
تحلیل‌ها نشان می‌دهد که این مشکل ناشی از عدم وجود یا پیکربندی نادرست پروتکل‌های احراز هویت ایمیل است. برخلاف سیاست‌های قبلی مایکروسافت که تنها فرستندگان حجیم (بیش از ۵۰۰۰ پیام در روز) را ملزم به استفاده از DMARC می‌کرد، اکنون فرستندگان کوچک‌تر و معمولی نیز با مشکل مواجه شده‌اند. پیام‌های ارسالی که فاقد رکورد‌های زیر باشند، با خطاهای 550 5.7.1 یا 550 5.7.23 مواجه می‌شوند:
- DMARC (Domain-based Message Authentication, Reporting, and Conformance)
- SPF (Sender Policy Framework)
- DKIM (DomainKeys Identified Mail)
ماهیت خطرناک اختلال: شکست خاموش
یکی از چالش‌برانگیزترین جنبه‌های این وضعیت، ماهیت متناقض و “خاموش” آن است. در برخی موارد، پیام‌ها با موفقیت تحویل می‌شوند و در برخی دیگر، به دلیل نقص در SPF یا DKIM رد می‌شوند. این عدم ثبات باعث می‌شود فرستنده تصور کند مشکل از سمت خود اوست یا یک اختلال موقت، در حالی که گیرنده نیز ممکن است هرگز متوجه نشود که پیامی ارسال شده است. این موضوع می‌تواند منجر به از دست رفتن فاکتورها، تاییدیه رمز عبور و مکاتبات حیاتی تجاری شود.
راهکارهای مقابله و رفع مشکل
برای جلوگیری از مسدود شدن ایمیل‌ها، سازمان‌ها باید اقدامات زیر را انجام دهند:
- بررسی وضعیت رکوردها: با استفاده از دستوراتی مانند
dig +short TXT _dmarc.example.comمی‌توان وجود رکورد DMARC را بررسی کرد. - پیاده‌سازی رکورد نظارتی: اضافه کردن یک رکورد TXT ساده با مقدار
v=DMARC1; p=noneمی‌تواند مانع از رد شدن ایمیل‌ها شود. این حالت (p=none) بدون تغییر در نحوه برخورد با ایمیل‌های جعلی، تنها به دریافت گزارش‌ها کمک می‌کند. - بررسی کامل زیرساخت: سازمان‌ها باید تمامی سرویس‌هایی که از طرف آن‌ها ایمیل ارسال می‌کنند (مانند سیستم‌های CRM، پلتفرم‌های HR و ابزارهای بازاریابی) را شناسایی و اطمینان حاصل کنند که تمامی آن‌ها دارای پروتکل‌های SPF و DKIM معتبر هستند.
در نهایت، هدف نهایی باید حرکت از حالت نظارتی (p=none) به حالت سخت‌گیرانه (p=reject) باشد تا از جعل دامنه و حملات Phishing و Business Email Compromise (BEC) جلوگیری شود.
