اسکن ۶۷۱,۶۹۳ دامنه نشان می‌دهد که بیش از نیمی از آن‌ها فاقد تنظیمات DMARC قابل اجرا هستند و این امر عوامل ایمیلی مبتنی بر هوش مصنوعی را در معرض آسیب به اعتبار و شکست در تحویل قرار می‌دهد. یک دامنه با پیکربندی اشتباه می‌تواند اعتبار مشترک ارسال را برای کل ناوگانی از عوامل خودگردان مخدوش کند.

آنچه اسکن فاش کرد

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

  • اجراکننده (p=quarantine یا reject) – ۴۹.۳۱٪ از دامنه‌ها
  • نظارتی (p=none همراه با گزارش‌ها) – ۲۵.۶۱٪
  • بی‌اثر (p=none بدون گزارش) – ۲۵.۰۴٪

رکوردهای بی‌اثر، که بیش از ۱۱۷,۰۰۰ مورد از آن‌ها هستند، صرفاً جای‌گذار (placeholder) می‌باشند: یک رشته بیست‌کاراکتری که فقط تیکِ انطباق را می‌زند اما هیچ محافظت واقعی ارائه نمی‌دهد. بدتر از آن، ۱۶۶,۴۴۲ دامنه یک سیاست DMARC را منتشر می‌کنند اما یک آدرس گزارش‌دهی (RUA) غیرفعال را لیست می‌کنند که عملاً باعث می‌شود بدون داشتن دید کافی عمل کنند.

ماه قبل از اسکن، شاهد افزایش تعداد مطلق رکوردهای DMARC بودیم، اما نسبت آن‌ها که واقعاً یک سیاست را اجرا می‌کردند کاهش یافت. تقریباً سه‌چهارم ورودی‌های جدید، تگ‌های "p=none" هستند که کاری فراتر از ثبت گزارش (logging) انجام نمی‌دهند.

چرا عوامل هوش مصنوعی اهمیت می‌دهند

عوامل، هر اعتباری را که دامنه ارسال با خود حمل می‌کند، به ارث می‌برند. اگر یک عامل را به دامنه‌ای با رکورد SPF ضعیف یا سیاست DMARC بی‌اثر اضافه کنید، هر پیام خروجی از این ناوگان به مخزن اعتبار مشترک اضافه می‌شود. یک دامنه با پیکربندی ضعیف می‌تواند باعث برگشت ایمیل (bounce-back)، محدودسازی نرخ ارسال (throttling) یا لیست سیاه شدن کامل برای هر عاملی شود که از آن استفاده می‌کند.

هزینه‌های پنهان

  • از دست رفتن اعتبار بلافاصله در میان تمام عواملی که از دامنه مشترک استفاده می‌کنند، پخش می‌شود.
  • کاهش قابلیت تحویل باعث افزایش تیکت‌های پشتیبانی و از بین رفتن اعتماد کاربر می‌شود.
  • ریسک انطباق زمانی افزایش می‌یابد که سازمان‌ها نتوانند تلاش‌های جعل (spoofing) را نظارت کنند؛ نبود یک آدرس RUA فعال به معنای نبود داده‌های جرم‌شناسی (forensic) است.

چگونه آن را اصلاح کنیم

۱. آدرس گزارش‌دهی را اعتبارسنجی کنید – یک پرس‌وجوی DNS اجرا کنید تا تأیید شود که آدرس RUA قابل حل است و می‌تواند گزارش‌های تجمیعی را دریافت کند. بدون داشتن دید کافی، نمی‌توانید به سوءاستفاده‌ها واکنش نشان دهید. ۲. گزارش‌های خام را بررسی کنید – گزارش‌های XML یا JSON را مستقیماً حداقل به مدت دو هفته دریافت کنید. داشبوردهای فروشندگان اغلب خطاها را پنهان می‌کنند یا داده‌ها را به گونه‌ای تجمیع می‌کنند که روندهای حیاتی را مخفی می‌سازند. ۳. includeهای SPF را پاکسازی کنید – هر مکانیزم "include" را که نمی‌توانید به وضوح شناسایی کنید، حذف کنید. یک رکورد SPF بیش از حد گسترده، راه را برای جعل باز کرده و تعداد جستجوهای DNS را بالا می‌برد که خطر شکست کامل SPF را به همراه دارد. ۴. عوامل را در یک زیردامنه ایزوله کنید – یک زیردامنه اختصاصی برای ایمیل‌های تولید شده توسط هوش مصنوعی مستقر کنید، کلید DKIM مخصوص به خود را ایجاد کنید و یک سیاست DMARC سخت‌گیرانه (p=reject) اعمال کنید. این مهار، هرگونه اشتباه را به جای کل دامنه اصلی شرکت، به یک فضای نام (namespace) واحد محدود می‌کند.

اجرای یک دستور سریع dig روی دامنه خود قبل از جلسه بعدی استقرار، می‌تواند ورودی‌های مفقود شده MX، SPF یا DMARC را که در بررسی‌های کد (code reviews) نادیده گرفته شده‌اند، آشکار کند.

دیدگاه مخالف

داده‌ها نشان می‌دهند که این موضع محتاطانه در مقیاس بزرگ می‌تواند مضر باشد: اکثر رکوردهای جدید بی‌اثر باقی می‌مانند و عدم اجرا، دامنه را در برابر سوءاستفاده آسیب‌پذیر می‌کند. گذار از حالت نظارتی به حالت اجرایی یک آزمون تدریجی است، نه یک جهش دوگانه (binary leap) ناگهانی.

نتیجه‌گیری

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