محتوای آموزشی وبلاگ نت‌آرام
در صندوق گزارش‌های دامنه فایلی با نام DMARC دریافت کرده‌اید. آن را که باز می‌کنید، مجموعه‌ای از IP، عدد و عبارت‌هایی مثل SPF، DKIM، pass و fail می‌بینید. آیا دیدن fail یعنی ایمیل‌های شرکت هک شده‌اند یا باید فوری تنظیمات را عوض کنید؟ نه لزوماً. ابتدا باید بفهمیم کدام سرویس پیام را فرستاده، نتیجه مربوط به کدام آزمون است و چه کسی گزارش را ساخته است.
این راهنما درباره گزارش تجمیعی DMARC یا Aggregate Report است؛ گزارشی که گیرنده‌های ایمیل درباره بخشی از پیام‌های دیده‌شده برای دامنه شما تهیه می‌کنند. این گزارش همه ایمیل‌های اینترنت و همه علت‌های اسپم را نشان نمی‌دهد. اگر با نقش SPF و DKIM آشنا نیستید، ابتدا راهنمای ساده SPF و DKIM و DMARC را بخوانید و بعد به این صفحه برگردید.
اول فایل را با احتیاط و بدون افشای اطلاعات باز کنید
این گزارش‌ها اغلب به آدرس تعیین‌شده در بخش گزارش‌گیری رکورد DMARC فرستاده می‌شوند و ممکن است پیوست فشرده حاوی فایل XML باشند. دامنه، IPها و اطلاعات زیرساخت شما می‌توانند داخل فایل باشند؛ آن را در سایت‌های ناشناس تحلیل آنلاین بارگذاری نکنید و برای افراد نامرتبط نفرستید. از بازکردن پیوست غیرمنتظره یا اجرای فایل ناشناس خودداری کنید؛ نوع فایل و فرستنده را از مسیر مطمئن بررسی کنید.
برای دیدن متن، پس از اطمینان از منبع و استخراج امن فایل، XML را با یک ویرایشگر متن روی سیستم خودتان باز کنید. نیازی نیست برنامه‌ای را اجرا کنید. اگر ابزار سازمانی مطمئنی برای گزارش دارید، مجوز دسترسی و محل نگهداری داده‌هایش را بررسی کنید. نمونه‌های زیر ساختگی‌اند؛ به جای داده واقعی خودتان، اطلاعات حساب یا کلید خصوصی را جایی منتشر نکنید.
سه بخش مهم را در یک ردیف پیدا کنید
در گزارش، هر بخش record می‌تواند گروهی از پیام‌ها با ویژگی‌ها و نتیجه مشترک را نشان دهد. سه قسمت اصلی برای شروع مفیدند:
| نام فیلد | به زبان ساده چه می‌گوید؟ |
| --- | --- |
| source_ip | نشانی سروری که گیرنده هنگام دریافت این گروه از پیام‌ها دیده است. این عدد به‌تنهایی ثابت نمی‌کند مالک آن سرویس مجاز شماست. |
| count | تعداد پیام‌های همین گروه در بازه گزارش؛ تعداد همه پیام‌های دامنه در تمام اینترنت نیست. |
| policy_evaluated | نتیجه ارزیابی و اقدام ثبت‌شده در ارتباط با سیاست DMARC، از جمله نتیجه هم‌ترازی SPF و DKIM. |
| header_from | دامنه موجود در نشانی From که به‌عنوان دامنه نویسنده پیام ارزیابی می‌شود. |
| auth_results | نتیجه خام آزمون SPF یا امضای DKIM برای هویت‌هایی که گیرنده بررسی کرده است. |
بازه زمانی و نام سازمان گزارش‌دهنده را هم در report_metadata پیدا کنید. زمان آغاز و پایان در فایل ممکن است به شکل عدد زمانی Unix باشد و به زمان محلی شما نمایش داده نشود. گزارش مربوط به گذشته است؛ اگر امروز تنظیمی را عوض کرده‌اید، گزارشی که همین حالا رسیده ممکن است هنوز دوره قبل از تغییر را پوشش دهد.
یک نمونه کوتاه را خط به خط بخوانیم
این نمونه ساده برای آموزش است و ساختار گزارش واقعی ممکن است جزئیات بیشتری داشته باشد. نشانی IP در مثال برای مستندسازی استفاده می‌شود:
کد / دستور<record>
<row>
<source_ip>192.0.2.40</source_ip>
<count>12</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim><domain>example.com</domain><result>pass</result></dkim>
<spf><domain>sender.example.net</domain><result>pass</result></spf>
</auth_results>
</record>
در این نمونه، گیرنده ۱۲ پیام با این ترکیب از نشانی نمونه دیده است. SPF در بخش auth_results برای دامنه sender.example.net موفق بوده، اما در بخش policy_evaluated نتیجه SPF برای DMARC ناموفق است؛ یکی از علت‌های ممکن، هم‌تراز نبودن آن دامنه با example.com است. در مقابل، نتیجه DKIM در بخش ارزیابی DMARC موفق گزارش شده است. بنابراین وجود SPF fail در این ردیف به‌تنهایی به معنی شکست کل DMARC نیست؛ یک مسیر معتبر و هم‌تراز DKIM می‌تواند کافی باشد.
مقدار disposition برابر none نیز به معنی «حتماً در Inbox نشست» نیست. این مقدار مربوط به اقدام ثبت‌شده در ارزیابی سیاست است و گیرنده ممکن است بر اساس فیلترهای دیگر تصمیم متفاوتی بگیرد. تعریف دقیق فیلدها در استاندارد گزارش تجمیعی DMARC آمده است.
چرا SPF موفق است اما DMARC هنوز مشکل دارد؟
SPF بررسی می‌کند آیا سرور برای هویت مربوط به ارسال مجاز است یا نه. DMARC علاوه بر موفق بودن SPF یا DKIM، به هم‌ترازی دامنه هم نگاه می‌کند: هویت تأییدشده باید طبق حالت هم‌ترازی فعال، با دامنه From رابطه مورد قبول داشته باشد. قواعد حالت سخت‌گیرانه و عادی یکسان نیستند.
برای مثال، یک سرویس ارسال ممکن است SPF را برای دامنه خودش با موفقیت تأیید کند، اما آن دامنه با دامنه From فروشگاه شما هم‌تراز نباشد. اگر امضای DKIM معتبر و هم‌تراز هم وجود نداشته باشد، DMARC می‌تواند ناموفق شود. راه‌حل معمولاً تغییر کورکورانه سیاست DMARC نیست؛ باید در پنل همان سرویس، روش تأیید دامنه فرستنده و امضای DKIM یا تنظیم هویت SPF هماهنگ را طبق راهنمای خودش تکمیل کنید.
ابتدا یک ایمیل آزمایشی به صندوقی که در اختیار دارید بفرستید و در جزئیات فنی پیام، نتایج Authentication-Results گیرنده را ببینید. به دامنه کنار هر نتیجه و نتیجه DMARC توجه کنید؛ یک pass در جای دیگر لزوماً همان pass هم‌تراز برای DMARC نیست. ظاهر و محل نمایش سرآیند در سرویس‌های ایمیل مختلف فرق می‌کند. هیچ رمز یا کد ورود را در این مرحله به اشتراک نگذارید.
حالا فرستنده مجاز را از فرستنده ناشناس جدا کنید
برای هر source_ip مهم و هر دامنه هویت، یک فهرست ساده بسازید. شرکت ممکن است از چند مسیر استفاده کند: صندوق سازمانی، سایت و فرم‌ها، سرویس خبرنامه و نرم‌افزار صدور فاکتور. از مسئول هر سرویس بخواهید IP یا روش شناسایی ارسال و دامنه امضای رسمی آن را تأیید کند. فقط از روی نام ظاهری سرویس یا حدس درباره مالک IP نتیجه نگیرید.
اگر منبع متعلق به یکی از سرویس‌های مجاز شماست و هر دو مسیر هم‌تراز ناموفق‌اند:
- اول دامنه From و سرویس واقعی ارسال آن پیام را مشخص کنید. ممکن است افزونه سایت از سرویسی متفاوت با صندوق شرکت استفاده کند.
- در پنل همان سرویس، بخش تأیید دامنه ارسال و DKIM را باز کنید و رکوردهای عمومی پیشنهادی را در DNS فعال دامنه، طبق دستور خودش وارد یا اصلاح کنید. کلید خصوصی DKIM نباید برای دیگران فرستاده شود.
- اگر SPF نیاز به اصلاح دارد، فهرست همه فرستنده‌های مجاز را حفظ کنید و رکورد فعلی را بدون شناخت بازنویسی نکنید. چند رکورد SPF مستقل برای یک نام می‌تواند خطا ایجاد کند؛ آموزش محدودیت DNS در SPF برای بررسی این وضعیت کمک می‌کند.
- پس از اعمال تغییر، پاسخ DNS و یک پیام آزمایشی جدید را بررسی کنید. برای دیدن اثر در گزارش تجمیعی باید منتظر گزارشی بمانید که واقعاً بازه بعد از تغییر را پوشش دهد.
اگر منبع را نمی‌شناسید: آن را فوراً به فهرست فرستنده‌های مجاز اضافه نکنید. ممکن است فرستنده جعلی، مسیر ارسال قدیمی، فوروارد یا سرویسی باشد که هنوز شناسایی نشده است. دامنه From، شمار پیام و بازه را نگه دارید و با مدیر ایمیل بررسی کنید. گزارش به‌تنهایی هویت صاحب هر پیام یا قصد فرستنده را ثابت نمی‌کند.
آیا همین حالا سیاست را روی Reject بگذاریم؟
پیش از سخت‌گیرانه‌تر کردن سیاست، همه سرویس‌های مجاز و مسیرهای ارسال مهم را آزمایش کنید. اگر یک سامانه قدیمی امضای هم‌تراز نداشته باشد، سیاست سخت‌گیرانه می‌تواند باعث رد یا قرنطینه بخشی از نامه‌های سالم شود. نحوه اعمال و استثناها به گیرنده و سیاست او نیز بستگی دارد. تغییر سیاست را مرحله‌به‌مرحله، با بررسی گزارش‌ها و برنامه بازگشت انجام دهید؛ صرف مشاهده چند fail دلیل کافی برای تغییر فوری نیست.
اگر هیچ گزارشی نمی‌رسد، اول آدرس گزارش‌گیری، دسترسی به صندوق، رکورد DNS فعال و بازه مورد انتظار را بررسی کنید. همه گیرنده‌ها الزاماً گزارش نمی‌فرستند و گزارش یک سرویس نماینده همه پیام‌ها نیست. استفاده از صندوق گزارش اختصاصی و محدودکردن دسترسی به آن، بررسی را منظم‌تر می‌کند.
نتیجه اصلاح را چطور تأیید کنیم؟
از هر سرویس مجاز یک پیام آزمایشی به صندوق کنترل‌شده بفرستید. دامنه From، نتیجه DMARC و جزئیات SPF و DKIM را در سرآیند گیرنده ثبت کنید. سپس گزارش‌های بازه بعدی را با فهرست فرستنده‌ها مقایسه کنید و برای منبع‌های شناخته‌شده‌ای که همچنان مشکل دارند به همان سرویس برگردید. موفقیت DMARC احتمال تشخیص درست هویت فرستنده را بهتر می‌کند، اما تضمین ورود همه پیام‌ها به Inbox نیست.
برای مدیریت و ثبت نام دامنه مورد استفاده ایمیل، صفحه ثبت دامنه نت‌آرام را ببینید. تنظیم ارسال باید با محل واقعی DNS و ارائه‌دهنده ایمیل همان دامنه هماهنگ باشد.
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام