ایمیل هفتگی از noreply@dmarcreport.com آمده و ضمیمه‌اش یک فایل XML است که باز می‌کنی و فقط می‌بینی چند تگ تودرتو و صدها ردیف IP. سؤال واقعی این است: کدام‌یک از این IPها مال خودمان است و کدام‌یک دارد به نام دامنهٔ ما ایمیل می‌فرستد؟ اگر جواب این سؤال را ندانی، هیچ‌وقت نمی‌توانی از p=none جلوتر بروی.
گزارش DMARC دقیقاً چه چیزی به تو میگوید
هر رکورد _dmarc که با rua=mailto:dmarc@example.com تنظیم شده باشد، باعث میشود گیرندههای بزرگ مثل Gmail و Outlook روزی یک یا چند بار یک فایل XML برایت بفرستند. این فایل دو بخش دارد: <report_metadata> که میگوید کدام سرور و در چه بازهٔ زمانی گزارش را ساخته، و <record> که به ازای هر ترکیب «IP فرستنده + دامنهٔ From» یک بلوک جدا می‌سازد.
داخل هر <record> سه چیز مهم است. اول <source_ip> که آدرس فرستنده است. دوم <count> که تعداد پیام‌ها در آن بازه را میدهد. سوم <policy_evaluated> که نتیجهٔ ارزیابی SPF و DKIM را با <spf>pass</spf> یا <dkim>fail</dkim> نشان میدهد. اگر هر دو fail باشند، آن رکورد یک پیام جعلی است.
XML خام را چطور بدون ابزار سنگین بخوانیم
لازم نیست اول یک پنل گرافیکی نصب کنی. با xmllint که روی اکثر توزیع‌ها هست، در چند ثانیه به جواب می‌رسی. فرض کن فایل را از ایمیل جدا کرده‌ای و اسمش report.xml است:
xmllint --xpath '//record[policy_evaluated/spf="fail" and policy_evaluated/dkim="fail"]/row/source_ip/text()' report.xmlاین دستور فقط IPهایی را چاپ میکند که هم SPF و هم DKIM را رد کرده‌اند. اگر خروجی خالی بود، خبر خوب است. اگر چند IP برگشت، همان‌ها مشکوک‌های واقعی هستند. برای دیدن تعداد پیام هر کدام:
xmllint --xpath '//record/row[source_ip="203.0.113.45"]/count/text()' report.xmlیک نکتهٔ عملی: گزارشها معمولاً gzip شده‌اند. اول gunzip report.xml.gz و بعد دستور بالا. اگر روزی چند گزارش می‌گیری، یک حلقهٔ ساده روی پوشه بزن و خروجی را در یک فایل تجمیع کن؛ دستی باز کردن XML فقط برای اولین بار جواب میدهد.
تفکیک فرستندهٔ مجاز از جعلی
معیار ساده است و به حدس نیاز ندارد. هر IP که در گزارش با spf=pass و dkim=pass ظاهر شود، فرستندهٔ مجاز است؛ یعنی یا سرور ایمیل خودت است، یا سرویس تراکنشی مثل ایمیل مارکتینگ که SPF و DKIM را برایش تنظیم کرده‌ای. هر IP که هر دو را fail بدهد، جعل است. حالت مبهم، وقتی است که یکی pass و یکی fail باشد؛ مثلاً SPF پاس شده ولی DKIM نه. اینجا معمولاً یک forwarder یا mailing list وسط است که پیام را بازفرست کرده و امضای DKIM را شکسته.
برای اینکه مطمئن شوی IP مجاز واقعاً مال توست، معکوسش را بپرس:
dig -x 203.0.113.45 +shortاگر خروجی به دامنهٔ سرویس ایمیل خودت اشاره کند، مجاز است. اگر به یک هاست ناشناس یا یک ISP خارجی اشاره کند، همان جاعل است. برای بررسی رکوردهای SPF و DKIM خودت هم می‌توانی از ابزارهای بررسی DNS و شبکه استفاده کنی تا مطمئن شوی رکوردها درست منتشر شده‌اند.
اینجا اشتباه می‌کنند
رایج‌ترین خطایی که دیده‌ام این است: مدیر سایت گزارش را می‌بیند، چند IP ناشناس پیدا میکند و بلافاصله سیاست را از p=none به p=reject می‌برد. دو هفته بعد شکایت می‌آید که فرم تماس سایت ایمیل‌ها را نمی‌فرستد و مشتری‌ها هیچ‌چیز دریافت نمی‌کنند.
علت این است که آن IP ناشناس، سرور ایمیل خود شرکت بوده که از یک ساب‌دامین یا از یک سرویس ابری ارسال می‌کرده و کسی یادش رفته SPF را برایش به‌روز کند. علامتش هم دقیقاً همین است: ارسال از داخل سازمان قطع میشود، ولی ارسال از سرویس‌های بیرونی سالم می‌ماند. قبل از هر تغییری، فهرست IPهای مجاز را با تیم زیرساخت چک کن، نه فقط با گزارش.
چه زمانی میشود p=reject گذاشت
معیار عددی دارد، نه حسی. اگر در بازهٔ حداقل دو هفته‌ای، بیش از ۹۹ درصد پیام‌های گزارش‌شده با SPF و DKIM پاس شوند و همهٔ IPهای پاسشده در فهرست مجاز تو باشند، وقتش رسیده. مسیر امن این است: p=none برای جمع‌آوری داده، بعد p=quarantine با pct=25 برای مدتی، و در نهایت p=reject.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; fo=1"پارامتر pct را دست‌کم نگیر. با pct=25 فقط یک‌چهارم پیام‌های جعلی قرنطینه میشوند و اگر اشتباهی کرده باشی، سه‌چهارم ترافیک سالمت هنوز رد نمی‌شود. این یک تور نجات واقعی است، نه تشریفات.
هزینه‌ای که باید بپذیری: p=reject برگشت‌پذیر نیست در لحظه. اگر فردا یک سرویس جدید برای ارسال اضافه کنی و SPF را به‌روز نکنی، ایمیل‌هایش بی‌صدا رد میشوند و تو فقط از شکایت کاربر می‌فهمی. پس هر تغییر در زیرساخت ایمیل باید با تغییر هم‌زمان رکورد DMARC همراه باشد.
گزارشها را کجا نگه داریم
XML خام را دور نریز. گزارشها تنها سند تاریخی‌ات هستند وقتی می‌خواهی بفهمی یک نفوذ از کجا شروع شده. آن‌ها را در همان جایی نگه دار که لاگ‌های دیگرت را نگه می‌داری و مطمئن شو دست‌نخورده می‌مانند؛ روش کار در لاگ ممیزی چیست و چگونه آن را دست‌نخورده نگه داریم؟ توضیح داده شده. اگر سرورت را از دست بدهی و گزارشها هم روی همان سرور باشند، هیچ مدرکی نداری.
پرسش‌های پرتکرار
گزارش DMARC را از کجا دریافت کنم؟
با اضافه کردن rua=mailto:آدرس به رکورد TXT دامنه در _dmarc.example.com. گیرندههای بزرگ مثل Gmail و Outlook خودشان گزارش را به آن آدرس میفرستند و لازم نیست جایی ثبتنام کنی. فقط باید آن صندوق را واقعاً بخوانی، وگرنه گزارشها بیفایده انبار میشوند.
تفاوت SPF و DKIM و DMARC چیست؟
SPF میگوید کدام IPها اجازهٔ ارسال دارند و روی پاکت SMTP بررسی میشود. DKIM یک امضای رمزنگاری روی هدرها میگذارد و ثابت میکند پیام در مسیر دستکاری نشده. DMARC بالای آن دو مینشیند و تعیین میکند اگر هر دو شکست خوردند، گیرنده چه کند: هیچ، قرنطینه، یا رد.
چرا بعد از p=reject ایمیلهای خودم رد میشوند؟
تقریباً همیشه یک فرستندهٔ مجاز از قلم افتاده. یا SPF برای یک سرویس جدید به‌روز نشده، یا DKIM روی ساب‌دامین درست تنظیم نیست. اول گزارش‌های ruf را بخوان، IP ردشده را با dig -x بررسی کن و بعد سیاست را موقتاً به p=quarantine برگردان تا مشکل حل شود.
هر چند وقت یکبار گزارشها را بررسی کنم؟
در هفتههای اول هفتگی، بعد از تثبیت سیاست ماهی یکبار کافی است. اما هر بار که زیرساخت ایمیلت تغییر میکند، همان هفته گزارش را دوباره نگاه کن. تغییر سرویس ارسال بدون بررسی گزارش، شایعترین دلیل قطع شدن ایمیلهای تراکنشی است.
اگر هنوز روی p=none ماندهای و نمیدانی از کجا شروع کنی، اول یک هفته گزارش جمع کن، IPهای پاسشده را در یک فایل فهرست کن، و بعد سراغ تغییر سیاست برو. اگر زیرساخت ایمیل و امنیت دامنهات را ترجیح میدهی به تیم دیگری بسپاری، خدمات امنیت سرورنت همین مسیر را پوشش میدهد. اما در هر حالت، تا وقتی فهرست IPهای مجازت را روی کاغذ نداری، دست به p=reject نزن.
دیدگاه‌ها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!