نحوه خواندن گزارش‌های DMARC: یک راهنمای عملی

ظرف ۲۴ تا ۷۲ ساعت پس از انتشار یک رکورد DMARC، اولین گزارش تجمیعی از راه می‌رسد و بلافاصله هر سرور قانونی و غیرمجازی که در آن دوره ایمیل ارسال کرده است را به عنوان دامنه شما نشان می‌دهد. نکته، همانطور که در ... مستند شده است. DMARC.orgمشخصات پروتکل این است که این گزارش‌ها، فایل‌های XML با فرمت ماشین هستند که برای تجزیه‌کننده‌های خودکار طراحی شده‌اند، نه برای خوانندگان انسانی.

دانستن نحوه خواندن گزارش‌های DMARC، آن داده‌های خام را به هوش عملیاتی تبدیل می‌کند. این قابلیت مشاهده واقعاً ارزشمند است، اما تنها پس از رمزگشایی XML به چیزی که بتوانید بر اساس آن اقدام کنید. آمار هرزنامه‌های ایمیلی نشان دهید که چرا این قابلیت مشاهده اهمیت دارد: جعل هویت و جعل هویت رایج است، بنابراین برای شناسایی منابعی که ایمیل را به عنوان دامنه شما ارسال می‌کنند، به گزارش‌های DMARC نیاز دارید.

نحوه خواندن گزارش‌های DMARC

اولین خوانش ۱۵ تا ۳۰ دقیقه طول می‌کشد. خوانش‌های بعدی از همان فرستنده‌ها، پس از آشنایی با الگو، ۲ تا ۳ دقیقه طول می‌کشد. مراحل زیر، یک گزارش جامع DMARC را از ابتدا تا انتها بررسی می‌کند.

در اینجا یک قطعه XML ناشناس وجود دارد که ساختار گزارش مورد استفاده در مراحل بررسی زیر را نشان می‌دهد:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>[email protected]</email>
    <report_id>10296513920663916120</report_id>
    <date_range>
      <begin>1716768000</begin>
      <end>1716854400</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>847</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <auth_results>
      <dkim>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>198.51.100.23</source_ip>
      <count>312</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <auth_results>
      <dkim>
        <domain>unknownsender.net</domain>
        <result>fail</result>
      </dkim>
      <spf>
        <domain>unknownsender.net</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>
</feedback>

مرحله ۱: یک صندوق ورودی یا سرویس برای دریافت گزارش‌ها تنظیم کنید

تأیید کنید که یک صندوق ورودی اختصاصی در حال جمع‌آوری گزارش‌ها در آدرس مشخص‌شده در برچسب rua= رکورد DMARC شما است (برای مثال، [ایمیل محافظت شده]ارائه دهندگان صندوق پستی روزانه گزارش‌های کلی ارسال می‌کنند، بنابراین حتی یک دامنه کم ترافیک نیز ماهانه ده‌ها فایل XML را جمع می‌کند؛ بنابراین، یک صندوق ورودی مشترک عمومی به سرعت غیرقابل مدیریت می‌شود.

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

مرحله ۲: فایل XML را باز کرده و از حالت فشرده خارج کنید

فایل پیوست شده را از ایمیل گزارش دانلود کنید. اکثر گزارش‌ها به صورت آرشیوهای .xml.gz یا .zip دریافت می‌شوند که ابتدا باید از حالت فشرده خارج شوند (در macOS و لینوکس، دوبار کلیک کنید یا از gunzip استفاده کنید؛ در ویندوز، راست کلیک کرده و فایل را استخراج کنید).

فایل .xml حاصل را در هر ویرایشگر متنی مانند VS Code، Sublime Text یا Notepad++ باز کنید. همچنین می‌توانید آن را در یک مرورگر باز کنید، که اغلب اسکن XML را آسان‌تر می‌کند زیرا بخش‌ها به جای یک بلوک طولانی از متن، به صورت گره‌های قابل جمع شدن ظاهر می‌شوند.

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

مرحله ۳: شناسایی سازمان و سیاست گزارش‌دهی

پیدا کردن بلوک در بالای فایل. این بلوک سازمان گزارش‌دهنده (گوگل، مایکروسافت، یاهو، Mail.ru یا دیگران) و مهرهای زمانی یونیکس را برای شروع و پایان پنجره گزارش مشخص می‌کند. تبدیل این مهرهای زمانی به تاریخ‌های قابل خواندن، تأیید می‌کند که گزارش کدام دوره ۲۴ ساعته را پوشش می‌دهد.

پیدا کردن بلافاصله بعد از آن بلاک می‌شود. این خط‌مشی DMARC که در طول پنجره گزارش فعال بوده است (p=none، p=quarantine یا p=reject) و حالت‌های هم‌ترازی برای SPF (aspf) و DKIM (adkim) را نشان می‌دهد. مقدار r به معنای هم‌ترازی راحت و s به معنای سخت‌گیرانه است.

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

مرحله ۴: هر منبع ارسال را در بخش سوابق بررسی کنید

اسکرول به بلوک‌ها. هر رکورد نشان دهنده یک IP فرستنده و نتایج آن است که بر اساس تعداد پیام‌ها گروه‌بندی شده‌اند. در قطعه کد بالا، 209.85.220.41 تعداد 847 پیام ارسال کرده و از DMARC عبور کرده است؛ 198.51.100.23 تعداد 312 پیام ارسال کرده و هر دو SPF و DKIM را با شکست مواجه کرده است.

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

روی هر IP منبع ناآشنا، یک جستجوی DNS معکوس اجرا کنید. فرستندگان معتبر، نام‌های میزبان قابل تشخیصی را انتخاب می‌کنند (mail-sor-f41.google.com برای Gmail، sendgrid.net برای SendGrid و amazonses.com برای AWS SES). IPهای ناشناخته قبل از اینکه فرض کنیم معتبر هستند، نیاز به بررسی دارند.

مرحله ۵: بررسی هم‌ترازی SPF و DKIM برای هر فرستنده

درون هر رکورد، عبارت زیر را پیدا کنید: بلوک. این شامل نتیجه SPF و نتیجه DKIM برای آن IP منبع، به همراه دامنه‌ای است که هر روش احراز هویت در آن ارزیابی شده است.

DMARC برای اینکه کل پیام از DMARC عبور کند، فقط به یکی از SPF یا DKIM نیاز دارد که در حالت هم‌تراز عبور کند. این فیلد، حکم نهایی (هیچ، قرنطینه یا رد) را بر اساس سیاست فعال در طول پنجره گزارش نشان می‌دهد.

هر رکوردی را که هم SPF و هم DKIM در آن ناموفق نشان داده می‌شوند، و منبع آن قرار است یک فرستنده‌ی قانونی باشد، علامت‌گذاری کنید. این یک فرستنده‌ی پیکربندی‌شده‌ی نادرست است که باید قبل از اینکه بتوان با خیال راحت سیاست را تشدید کرد، اصلاح شود. رکوردی که spf=fail را نشان می‌دهد اما dkim=pass را نشان می‌دهد، معمولاً خوب است، زیرا پیام همچنان از DMARC عبور می‌کند.

هر فیلد XML در گزارش DMARC چه چیزی به شما می‌گوید؟

گزارش‌های تجمیعی DMARC از RFC 7489 پیروی می‌کنند. همه گزارش‌های منطبق با این استاندارد، صرف نظر از اینکه کدام ارائه‌دهنده صندوق پستی آنها را ارسال کرده است، از ساختار یکسانی استفاده می‌کنند. در طول بررسی هر گزارش، از این فیلد مرجع استفاده کنید:

• — سازمان گزارش‌دهنده (گوگل، مایکروسافت، یاهو و غیره). تأیید می‌کند که کدام ارائه‌دهنده صندوق پستی گزارش را ارسال کرده است. ارائه‌دهندگان بزرگ معمولاً گزارش‌های جداگانه‌ای را برای هر دامنه ارسال می‌کنند.
• — مهرهای زمانی یونیکس برای شروع و پایان دوره تحت پوشش. اکثر گزارش‌ها یک بازه زمانی ۲۴ ساعته را پوشش می‌دهند، اگرچه برخی از ارائه‌دهندگان گزارش‌ها را کمتر ارسال می‌کنند.
• — سیاست DMARC فعال در طول پنجره (برچسب p) به علاوه حالت‌های ترازبندی برای SPF (aspf) و DKIM (adkim). ترازبندی آرام (r) به زیر دامنه‌ها اجازه می‌دهد تا ترازبندی را رعایت کنند؛ سختگیرانه (s) نیاز به تطابق دقیق دارد.
• — آدرس IP که پیام‌ها را ارسال کرده است. Reverse-DNS این را برای شناسایی سرویس ارسال کننده استفاده می‌کند.
• — تعداد پیام‌های ارسال شده از این IP منبع در طول دوره گزارش. تعداد بالای پیام‌های ارسالی از IPهای ناشناخته، یک هشدار است.
• — حکم نهایی DMARC: هیچکدام (هیچ اقدامی انجام نشد)، قرنطینه (در پوشه هرزنامه قرار گرفت) یا رد شد (بازگشت خورد).
• — نتایج SPF و DKIM برای منبع. هر کدام دامنه احراز هویت شده و یک حکم قبولی/ردی را نشان می‌دهند. هم‌ترازی بین دامنه احراز هویت شده و دامنه فرستنده چیزی است که تعیین می‌کند آیا DMARC به طور کلی پذیرفته می‌شود یا خیر، نه فقط اینکه SPF یا DKIM به صورت جداگانه پذیرفته می‌شوند.

در گزارش‌های DMARC به دنبال چه چیزی باشیم؟

وقتی این چهار الگو را بشناسید، خواندن گزارش‌های DMARC بسیار آسان‌تر می‌شود. به جای اسکن کردن انبوهی از فایل‌های XML، می‌توانید هر رکورد را در یک دسته‌ی مشخص مرتب کنید.

فرستنده‌های قانونی که dmarc=pass را نشان می‌دهند

یک فرستنده شناخته‌شده، مانند ESP، پلتفرم بازاریابی، میز کمک یا CRM شما، که در گزارش با dkim=pass و spf=pass ظاهر می‌شود، به این معنی است که تنظیمات برای آن منبع به درستی کار می‌کند.

از طریق DNS معکوس، به خصوص برای رکوردهای با تعداد بالا، تأیید کنید که IP منبع متعلق به ارائه‌دهنده‌ی مورد نظر است. انتظار می‌رود حجم زیادی از ایمیل از یک IP شناخته‌شده با dmarc=pass ارسال شود. یک بار آن را تأیید کنید، سپس آن را به عنوان مبنایی برای گزارش‌های آینده در نظر بگیرید.

منابع مشکوک با تعداد پیام‌های بالا

آی‌پی‌های ناشناسی که صدها یا هزاران پیام با dmarc=fail ارسال می‌کنند، در یکی از این دو دسته قرار می‌گیرند: فرستندگان غیرمجازی که به‌طور فعال دامنه شما را جعل می‌کنند، یا یک فرستنده قانونی فراموش‌شده (یک ابزار بازاریابی قدیمی، یک ادغام فناوری اطلاعات در سایه) که هرگز به‌درستی احراز هویت نشده است.

با بررسی IP WHOIS و رکوردهای DNS معکوس، بررسی کنید. یک IP اسپم شناخته شده معمولاً به جعل ایمیل اشاره می‌کند، در حالی که یک پلتفرم SaaS فراموش شده معمولاً به یک مشکل احراز هویت اشاره می‌کند. این دو مورد به پاسخ‌های متفاوتی نیاز دارند: ایمیل‌های جعلی را مسدود یا رد کنید، اما ترازبندی SPF یا DKIM را برای فرستندگان قانونی اصلاح کنید.

SPF ناموفق است، اما DKIM موفق می‌شود: معمولاً در حال ارسال است

پیامی که SPF را رد می‌کند اما از DKIM عبور می‌کند، اغلب به ارسال ایمیل اشاره دارد. سرور ارسال در رکورد SPF فرستنده اصلی فهرست نشده است، بنابراین SPF شکست می‌خورد. اما DKIM متفاوت عمل می‌کند. هدرهای پیام را امضا می‌کند و آن امضا اغلب هنگام ارسال ایمیل دست نخورده باقی می‌ماند. به همین دلیل است که DKIM حتی در صورت شکست SPF نیز می‌تواند عبور کند.

هر زمان که SPF یا DKIM با هم تراز شوند، DMARC به طور کلی قبول می‌شود، بنابراین این رکوردها مشکلی ایجاد نمی‌کنند. برای دامنه‌هایی که گیرندگان آنها از ارسال ایمیل استفاده می‌کنند، این رفتار مورد انتظار است. این گزارش نشان می‌دهد که چگونه ارسال ایمیل بر احراز هویت تأثیر می‌گذارد، نه یک تنظیم DMARC ناموفق.

افزایش ناگهانی حجم ترافیک از IP های ناشناخته: معمولاً کلاهبرداری

یک IP که قبلاً دیده نشده بود، ناگهان حجم زیادی از پیام‌ها را ارسال می‌کند و SPF و DKIM آن از کار افتاده است. این یک امضای جعل کلاسیک است. شخصی از طریق زیرساخت خود ایمیلی ارسال می‌کند که ادعا می‌کند از دامنه شما است و سعی می‌کند با قرض گرفتن سیگنال‌های اعتماد دامنه شما، فیلترهای اسپم را دور بزند.

IP را در ابزارهای هوش تهدید مانند AbuseIPDB یا Cisco Talos بررسی کنید. اگر IP به هرزنامه یا سوءاستفاده مرتبط باشد، احتمالاً این افزایش ناگهانی مخرب است. در این زمان است که حرکت به سمت p=reject اهمیت پیدا می‌کند. هنگامی که همه فرستندگان قانونی هماهنگ شوند، اجرای کامل به مسدود کردن ایمیل‌های جعلی قبل از اینکه بتوانند به شما آسیب برسانند، کمک می‌کند. شهرت فرستنده ایمیل.

ابزارهایی برای تجزیه و تحلیل و مصورسازی گزارش‌های DMARC

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

برای اکثر تیم‌هایی که تازه شروع به کار کرده‌اند، MXToolbox برای بررسی‌های دستی گاه‌به‌گاه و Postmark DMARC Digests برای نظارت غیرفعال، ترکیبی رایگان و کاربردی است. زمانی که تعداد دامنه‌ها یا حجم گزارش‌های روزانه، بررسی دستی را غیرممکن می‌کند، به سراغ یک تحلیلگر اختصاصی مانند DMARCian بروید.

از گزارش‌ها تا اقدام: چه زمانی باید سیاست خود را سختگیرانه‌تر کنید

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

• مرحله موجودی (هفته‌های ۱ تا ۴ با p=none): هر منبع قانونی ارسال کننده را به عنوان دامنه خود شناسایی کنید. اگر هر منبعی نیاز به کار هم‌ترازی دارد، آن را تکمیل کنید. SPF، DKIM و DMARC قبل از اقدام به اجرای قانون، تنظیمات لازم را انجام دهید.
• مرحله هم‌ترازی (هفته‌های ۴ تا ۸ با p=none): تأیید کنید که هر منبع قانونی، SPF یا DKIM را با هماهنگی با دامنه‌ی فرستنده عبور می‌دهد. مواردی را که این اتفاق نمی‌افتد، با اضافه کردن منبع به SPF، فعال کردن امضای DKIM یا هر دو، برطرف کنید. هدف قبل از اقدام به اجرای قانون، نرخ عبور ثابت بالای ۹۵٪ در بین تمام فرستندگان قانونی در چندین چرخه‌ی گزارش متوالی است.
• مرحله اجرا (هفته ۸ به بالا در p=قرنطینه، سپس p=رد): به محض اینکه گزارش‌ها، هم‌ترازی ثابت و بدون خرابی با حجم بالا از سوی فرستنده‌های قانونی را نشان دهند، به p=قرنطینه بروید. به مدت ۲ تا ۴ هفته در آنجا بمانید و نظارت را ادامه دهید. سپس به p=reject بروید. نظارت را در p=reject حفظ کنید، زیرا فرستنده‌های جدید اضافه شده به پشته می‌توانند خرابی‌های هم‌ترازی جدیدی ایجاد کنند.

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

تبدیل داده‌های DMARC به تصمیم‌گیری‌ها

گزارش‌های تجمیعی DMARC داده‌های عملیاتی هستند. نکته این نیست که آنها را صرفاً به عنوان تئوری بخوانید، بلکه باید بر اساس آنچه آشکار می‌کنند، اقدام کنید. فرستنده‌های قانونی که در تنظیم آدرس‌ها دچار مشکل می‌شوند را اصلاح کنید. IPهای ناآشنا را بررسی کنید. هنگامی که منابع مورد اعتماد شما به طور مداوم در حال ارسال هستند، به سمت اجرای قانون حرکت کنید.

هدف، یک گزارش خسته‌کننده است: منابع شناخته‌شده، نرخ عبور ثابت و عدم افزایش ناگهانی حجم از IPهای ناشناخته. همین قابل پیش‌بینی بودن، p=reject را ایمن می‌کند و p=reject همان چیزی است که دامنه شما را از جعل هویت محافظت می‌کند.

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