DMARC چیست و چگونه امنیت ایمیل را تقویت می‌کند؟

سال‌ها پیش، مشتری‌ای زنگ زد که چند مشتریِ قدیمی، ایمیل‌هایی از دامنهٔ او دریافت کرده‌اند با این مضمون که «شمارهٔ حساب تغییر کرده، مبلغ را به حساب جدید واریز کنید». مشتری هیچ‌کدام از آن ایمیل‌ها را نفرستاده بود؛ اما ایمیل‌ها کاملاً شبیه نامه‌های رسمی شرکتش بودند — همان لوگو، همان امضا، همان دامنه. آن روز، اولین باری بود که با حملهٔ جعل ایمیل (Email Spoofing) از نزدیک روبه‌رو شدم. آن تجربه، مسیر نگاه من به سه استاندارد امنیت ایمیل را کامل عوض کرد: SPF (Sender Policy Framework)، DKIM (DomainKeys Identified Mail)، و مهم‌تر از هر دو، DMARC. این مقاله، همان چیزی است که امروز برای حفاظت از دامنه‌های مشتریانم در برابر جعل ایمیل و افت در تحویل‌پذیری استفاده می‌کنم.

DMARC دقیقاً چیست؟

DMARC مخفف Domain-based Message Authentication, Reporting, and Conformance است — و اگر این نام کامل را درک کنید، تقریباً نصف مفهومش را فهمیده‌اید. سه بخش:

• Authentication: تأیید هویت. DMARC تصمیم می‌گیرد که یک ایمیل، واقعاً از دامنه‌ای که ادعا می‌کند آمده یا نه.
• Reporting: گزارش‌گیری. DMARC به سرورهای دریافت‌کنندهٔ ایمیل اجازه می‌دهد که گزارش‌هایی از وضعیت تأیید ایمیل‌های ارسالی به دامنهٔ شما، به خودتان بفرستند.
• Conformance: انطباق. DMARC سیاستی است که به سرور گیرنده می‌گوید «اگر ایمیل تأیید نشد، چه کار کن؟» — رد کن، به اسپم بفرست، یا رها کن.

پس در یک جمله: DMARC یک رکورد متنی (TXT Record) در DNS (Domain Name System) دامنهٔ شماست که به دنیا اعلام می‌کند: «ایمیل‌های من باید با SPF یا DKIM تأیید شوند؛ اگر تأیید نشدند، با آن‌ها این‌طور رفتار کن؛ و گزارش‌ها را به این نشانی بفرست.» اگر با SPF و DKIM آشنایی ندارید، پیش از این مقاله، DKIM و امضای دیجیتال ایمیل‌ها و SPF چیست و چگونه از جعل ایمیل جلوگیری می‌کند را بخوانید؛ این مقاله فرض می‌کند که با این دو استاندارد آشنایید.

SPF و DKIM دو نگهبان دامنه هستند؛ DMARC فرماندهی است که به آن دو می‌گوید چه کار کنند و به شما گزارش می‌دهد چه شد.

چرا DMARC از SPF و DKIM قوی‌تر است؟

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

دلیل اول: SPF و DKIM به‌تنهایی «قابل دور زدن» هستند

SPF مشخص می‌کند کدام سرورها مجاز به ارسال ایمیل از دامنهٔ شما هستند. اما این مکانیزم، یک ضعف کلاسیک دارد: اگر دامنهٔ شما در فیلد From نباشد و در فیلد Return-Path باشد، SPF ممکن است پاس شود، بدون آنکه دامنهٔ واقعی تأیید شده باشد. مهاجم‌های حرفه‌ای از همین حفره استفاده می‌کنند. DKIM هم قوی است، اما اگر امضای DKIM توسط یک سرور میانی (مثل فورواردر) شکسته شود، گیرنده نمی‌داند چه کار کند. DMARC، این تصمیم را می‌گیرد.

دلیل دوم: DMARC به دامنهٔ نمایش‌داده‌شده در ایمیل نگاه می‌کند

مهم‌ترین تفاوت، همین است. SPF و DKIM به دامنهٔ «فنی» ایمیل نگاه می‌کنند، اما DMARC به دامنه‌ای نگاه می‌کند که کاربر می‌بیند — همان چیزی که در فیلد From نمایش داده می‌شود. یک مهاجم می‌تواند دامنهٔ فنی را از یک سرور جعلی بفرستد، اما دامنهٔ نمایش را yourbrand.com بگذارد. SPF و DKIM به این حمله حساس نیستند؛ DMARC با مکانیزم «هم‌راستایی» (Alignment) این را می‌گیرد.

دلیل سوم: DMARC گزارش می‌دهد، SPF و DKIM نمی‌دهند

این تفاوت، در نگاه اول کوچک به نظر می‌رسد اما در تجربهٔ من، بزرگ‌ترین ارزش DMARC است. SPF و DKIM فقط تصمیم می‌گیرند؛ DMARC به شما می‌گوید که «چه کسی به نام دامنهٔ شما ایمیل می‌فرستد و نتیجه چه بوده». در پروژه‌ای که DMARC را فعال کردیم، گزارش‌ها نشان دادند که چند سرویس تبلیغاتی به‌طور ناخواسته از دامنهٔ مشتری استفاده می‌کردند بدون آنکه در SPF ثبت شده باشند. پیش از DMARC، این اطلاعات به‌سختی به دست می‌آمد.

سه سیاست DMARC و معنای هرکدام

DMARC سه سطح سیاست دارد که در فیلد p رکورد مشخص می‌شوند. انتخاب درست بین این سه، تفاوت بین «امنیت واقعی» و «امنیت نمایشی» است:

سیاست اول: p=none — فقط مشاهده

این سیاست، به سرور گیرنده می‌گوید: «اگر ایمیل تأیید نشد، کاری نکن؛ فقط به من گزارش بده.» در نگاه اول بی‌فایده به نظر می‌رسد، اما در تجربهٔ من بهترین شروع ممکن است. با p=none، شما بدون آنکه ریسک حذف ایمیل‌های واقعی را داشته باشید، متوجه می‌شوید چه کسی به نام دامنهٔ شما ایمیل می‌فرستد — چه مشروع، چه جعلی.

سیاست دوم: p=quarantine — قرنطینه

ایمیل‌هایی که تأیید نمی‌شوند، به پوشهٔ اسپم یا قرنطینه می‌روند. این سیاست، مرحلهٔ میانی است و زمانی مناسب است که مطمئن شده‌اید همهٔ سرویس‌های مشروع شما در SPF و DKIM ثبت شده‌اند. مزیت: حمله‌ها بی‌اثر می‌شوند. ریسک: اگر سرویس مشروعی را از قلم انداخته باشید، ایمیل‌های واقعی به اسپم می‌روند.

سیاست سوم: p=reject — رد کامل

قوی‌ترین سیاست: ایمیل تأییدنشده، قبل از رسیدن به گیرنده، کاملاً رد می‌شود. این سیاست، حمله‌های جعل را بی‌اثر می‌کند، اما ریسکش هم بالاست — هر سرویس مشروع ناشناخته، ایمیل‌هایش از دست می‌رود. توصیهٔ من: هرگز مستقیم سراغ p=reject نروید؛ حداقل چند هفته با p=none گزارش بگیرید، بعد quarantine، و در نهایت reject.

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100; fo=1

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

DMARC را مثل پله‌برقی ببینید: هرگز از طبقهٔ همکف به طبقهٔ سوم نپرید؛ مرحله‌به‌مرحله بالا بروید تا کسی آسیب نبیند.

DMARC در عمل: مسیر تصمیم‌گیری سرور گیرنده

برای اینکه درک عمیقی از DMARC داشته باشید، باید بدانید سرور گیرنده دقیقاً چه کار می‌کند. مسیر تصمیم‌گیری، این‌طور است:

1. ایمیل به سرور گیرنده می‌رسد.
2. سرور گیرنده، SPF را بررسی می‌کند: آیا سرور فرستنده مجاز به ارسال از این دامنه است؟ نتیجه: pass یا fail.
3. سرور گیرنده، DKIM را بررسی می‌کند: آیا امضای دیجیتال ایمیل معتبر است؟ نتیجه: pass یا fail.
4. سرور گیرنده، رکورد DMARC دامنهٔ From را از DNS می‌خواند. اگر رکوردی نبود، DMARC اعمال نمی‌شود.
5. سرور گیرنده، «هم‌راستایی» بین دامنهٔ From و دامنه‌ای که SPF/DKIM تأیید کرده‌اند را بررسی می‌کند.
6. اگر حداقل یکی از دو (SPF یا DKIM) هم‌راستا و پاس بود، ایمیل تأیید می‌شود.
7. اگر هیچ‌کدام هم‌راستا نبود، سرور گیرنده به سیاست DMARC نگاه می‌کند و بر اساس p=none، quarantine یا reject تصمیم می‌گیرد.
8. در نهایت، سرور گیرنده یک گزارش (اگر rua تنظیم شده باشد) به نشانی شما می‌فرستد.

این مسیر را در ذهن داشته باشید؛ در ادامه، هرجا به «هم‌راستایی» و «گزارش» اشاره می‌کنم، به همین مسیر برمی‌گردیم.

هم‌راستایی (Alignment): مفهوم کلیدی که اکثر آموزش‌ها جا می‌اندازند

اگر فقط یک مفهوم را از این مقاله به‌خاطر بسپارید، همین «هم‌راستایی» باشد. به همین دلیل، یک بخش جداگانه به آن اختصاص داده‌ام. هم‌راستایی به این معناست: دامنهٔ From (که کاربر می‌بیند) باید با دامنه‌ای که SPF یا DKIM تأیید کرده، تطابق داشته باشد.

دو نوع هم‌راستایی وجود دارد:

هم‌راستایی سخت (Strict)

با aspf=s و adkim=s تنظیم می‌شود. در این حالت، دامنهٔ From باید دقیقاً با دامنهٔ تأییدشده یکسان باشد. مثلاً example.com فقط با example.com هم‌راستا است، نه با زیردامنه‌های آن.

هم‌راستایی نرم (Relaxed)

حالت پیش‌فرض است: aspf=r و adkim=r. در این حالت، زیردامنه‌ها هم پذیرفته می‌شوند. یعنی news.example.com هم با example.com هم‌راستا در نظر گرفته می‌شود. برای اکثر پروژه‌ها، همین حالت پیش‌فرض کافی است.

در تجربهٔ من، اینجا جایی است که اکثر خطاهای DMARC رخ می‌دهند. کاربران SPF را برای mail.example.com تنظیم می‌کنند، اما ایمیل‌ها با دامنهٔ example.com ارسال می‌شوند، و DMARC به‌خاطر نبود هم‌راستایی، آن‌ها را رد می‌کند. راه‌حل: همیشه گزارش‌های DMARC را با دقت بخوانید؛ هم‌راستایی را با داده، نه با حدس، تشخیص دهید.

DMARC از SPF و DKIM قوی‌تر است چون دامنه‌ای که کاربر می‌بیند را با دامنه‌ای که فنی تأیید شده، مقایسه می‌کند. همان یک مقایسه، عملاً بیشتر جعل‌ها را از بین می‌برد.

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

یکی از بزرگ‌ترین ارزش‌های DMARC، گزارش‌هایی است که دریافت می‌کنید. دو نوع گزارش وجود دارد:

گزارش تجمیعی (Aggregate Report — RUA)

این گزارش، به‌صورت دوره‌ای (معمولاً روزانه) به نشانی rua فرستاده می‌شود. این گزارش در قالب XML (eXtensible Markup Language) است و اطلاعات زیر را دارد:

• دامنه‌ای که به نام شما ایمیل فرستاده.
• IP فرستنده.
• نتیجهٔ SPF و DKIM.
• هم‌راستایی یا نبود آن.
• تعداد ایمیل‌های ارسال‌شده.

گزارش خطای روزانه (Forensic Report — RUF)

این گزارش، جزئیات تک‌ایمیل‌هایی که رد شده‌اند را می‌فرستد. اما نکتهٔ مهم: بسیاری از سرورهای بزرگ (از جمله Gmail و Yahoo) این گزارش را ارسال نمی‌کنند یا فقط به‌صورت محدود ارسال می‌کنند، به‌دلیل نگرانی‌های حریم‌خصوصی. پس در عمل، اکثر تحلیل‌ها بر پایهٔ RUA انجام می‌شود.

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

پیاده‌سازی سه‌مرحله‌ای DMARC

پس از فهم مفاهیم، وقت پیاده‌سازی است. در تجربه‌ام، بهترین رویکرد یک مسیر سه‌مرحله‌ای است که در پروژه‌های خودم اجرا می‌کنم:

مرحلهٔ اول (هفتهٔ اول تا دوم): فقط مشاهده

یک رکورد DMARC با سیاست p=none تنظیم کنید و rua را به یک نشانی اختصاصی وصل کنید:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1

در این مرحله، هیچ ایمیلی رد یا قرنطینه نمی‌شود؛ فقط گزارش می‌گیرید. هدف: فهمیدن اینکه چه سرویس‌هایی به نام دامنهٔ شما ایمیل می‌فرستند. حداقل دو هفته وقت بگذارید؛ در پروژه‌های بزرگ، یک ماه.

مرحلهٔ دوم (هفتهٔ سوم تا ششم): قرنطینه

پس از اینکه همهٔ سرویس‌های مشروع را شناسایی و در SPF ثبت کردید، سیاست را به quarantine تغییر دهید. در این مرحله، در تنظیمات رکورد، از pct=10 استفاده کنید و به‌تدریج به pct=100 برسید:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com; fo=1

معنای pct=10 این است که ده درصد ایمیل‌های تأییدنشده، قرنطینه می‌شوند؛ نود درصد بقیه، بدون تغییر عبور می‌کنند. این تدریج، ریسک قطع شدن ایمیل‌های واقعی را به‌شدت کاهش می‌دهد.

مرحلهٔ سوم (هفتهٔ هفتم به بعد): رد کامل

وقتی مطمئن شدید که همه‌چیز سر جای خودش است، سیاست را به reject تغییر دهید. این همان مرحله‌ای است که جعل ایمیل به‌نام دامنهٔ شما، عملاً غیرممکن می‌شود:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; fo=1

روش گام‌به‌گام این فرآیند را در راه‌اندازی DMARC گام‌به‌گام با جزئیات بیشتر آورده‌ام. اگر با SPF و DKIM هم آشنایی کامل ندارید، پیشنهاد می‌کنم ابتدا این دو را تنظیم کنید — بدون آن‌ها، DMARC کار نمی‌کند. راهنمای SPF در تنظیم SPF برای دامنه‌های ایرانی و راهنمای DKIM در پیاده‌سازی DKIM در سرور ایمیل آمده است.

DMARC در پروژه‌های وردپرسی

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

سناریو اول: وردپرس ایمیل می‌فرستد، اما از دامنهٔ سرور استفاده می‌کند

به‌طور پیش‌فرض، وردپرس از تابع wp_mail استفاده می‌کند که با PHP (Hypertext Preprocessor) و کتابخانهٔ ارسال ایمیل سرور کار می‌کند. در نتیجه، ایمیل‌ها ممکن است با دامنهٔ @server.example.com یا با دامنهٔ سرور ارسال شوند، نه با دامنهٔ سایت. اگر DMARC را روی reject تنظیم کرده باشید، این ایمیل‌ها رد می‌شوند، چون هم‌راستا نیستند. راه‌حل: از یک افزونهٔ SMTP (Simple Mail Transfer Protocol) استفاده کنید که ایمیل‌ها را با احراز هویت و دامنهٔ درست ارسال کند. اصول SMTP در وردپرس را در SMTP و ارسال ایمیل از وب‌سایت باز کرده‌ام.

سناریو دوم: سرویس ایمیل تراکنشی جدا

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

سناریو سوم: چند سرویس همزمان

در پروژه‌های بزرگ‌تر، ممکن است همزمان از چند سرویس ایمیل استفاده کنید: خبرنامه، ایمیل تراکنشی، ایمیل سازمانی. هرکدام نیاز به SPF و DKIM خودشان دارند. رکورد SPF باید همه را در یک خط فهرست کند، با محدودیت نهایی ۱۰ مکانیزم DNS. اگر از این حد عبور کنید، SPF بی‌اثر می‌شود و DMARC خطا می‌دهد. راه‌حل: از یک زیردامنهٔ اختصاصی برای ارسال استفاده کنید — مثلاً mail.example.com — که SPF و DKIM مجزایی دارد.

در پروژه‌ای که یک فروشگاه ووکامرسی بزرگ داشتیم، پس از فعال‌سازی DMARC، متوجه شدیم که یک سرویس ارسال خبرنامه، از یک زیردامنه استفاده می‌کند که در SPF ما نبود. این کشف، جلوی افت بزرگ تحویل‌پذیری در ماه بعد را گرفت.

فعال‌سازی DMARC در وردپرس، پیش از هرچیز یعنی اطمینان از اینکه همهٔ سرویس‌های ایمیل شما هم‌راستا هستند — این بررسی، خودش ارزش یک پروژهٔ کوچک را دارد.

ابزارهای تحلیل گزارش DMARC

گزارش‌های DMARC در قالب XML می‌آیند که خواندن دستی آن‌ها تقریباً غیرممکن است. چند ابزار که در پروژه‌ها استفاده کرده‌ام:

ابزارهای آنلاین

• سرویس‌های تحلیل DMARC: ایمیل گزارش را به یک صندوق مشترک هدایت می‌کنید و سرویس، آن را به داشبورد قابل‌فهم تبدیل می‌کند. نسخه‌های رایگان برای دامنه‌های کوچک کافی است.
• ابزارهای بررسی رکورد: این ابزارها به‌سرعت نشان می‌دهند که رکورد DMARC شما در DNS درست ثبت شده یا نه. برای عیب‌یابی اولیه، بهترین شروع است.

ابزارهای دستی

اگر تعداد ایمیل‌ها کم است، می‌توانید از ابزارهای متن‌باز برای تحلیل XML استفاده کنید. روش من: بازکردن فایل XML در یک ویرایشگر متن و نگاه کردن به مقادیر <source_ip>، <disposition> و <dkim>. با این روش، خطاهای رایج به‌سرعت دیده می‌شوند.

یک نکتهٔ عملی: هیچ‌وقت فقط به یک ابزار تکیه نکنید. در تجربه‌ام، سه سطح بررسی مکمل همدیگرند: یکی، ابزار تحلیل خودکار که روند کلی را نشان می‌دهد؛ دوم، بررسی دستی چند گزارش برای جزئیات؛ سوم، بررسی دوره‌ای رکورد SPF و DKIM با ابزارهای تخصصی برای اطمینان از اینکه چیزی تغییر نکرده.

خطاهای رایج در پیکربندی DMARC

در بازبینی پروژه‌های مختلف، پنج خطای رایج را در پیکربندی DMARC زیاد دیده‌ام:

• فعال‌سازی مستقیم p=reject: رایج‌ترین و پرهزینه‌ترین. اگر سرویس مشروعی را ندیده باشید، آن سرویس کاملاً قطع می‌شود. مسیر سه‌مرحله‌ای، دقیقاً برای پیشگیری از همین خطا طراحی شده.
• فراموش‌کردن rua: اگر نشانی گزارش را ندهید، DMARC فقط تصمیم می‌گیرد و هیچ‌وقت نمی‌فهمید چه اتفاقی افتاده. یک DMARC بدون rua، یک DMARC کور است.
• SPF بیش از ۱۰ مکانیزم: استاندارد SPF، محدودیت ۱۰ مکانیزم DNS دارد. اگر در پروژه‌ای این عدد را رد کنید، SPF شما بی‌اثر می‌شود. اگر مجبور به ارسال از سرویس‌های زیاد هستید، زیردامنهٔ اختصاصی بسازید.
• ناسازگاری دامنهٔ DKIM با دامنهٔ From: اگر DKIM روی mail.example.com امضا کرده، اما دامنهٔ From شما example.com باشد، DMARC به‌خاطر نبود هم‌راستایی، ایمیل را رد می‌کند — مگر اینکه حالت relaxed فعال باشد. همیشه گزارش‌ها را بررسی کنید.
• بی‌توجهی به ساب‌دامین‌ها: در استاندارد DMARC، رکورد روی دامنهٔ اصلی، به‌طور پیش‌فرض ساب‌دامین‌ها را پوشش نمی‌دهد. اگر روی example.com DMARC دارید اما کسی از news.example.com جعل می‌کند، این جعل گرفته نمی‌شود. راه‌حل: یک رکورد جدا برای ساب‌دامین، یا استفاده از تگ sp در رکورد اصلی.

یک تذکر مهم: در پروژه‌های خودم، پس از هر تغییر در پیکربندی SPF یا DKIM، یک بازبینی از رکورد DMARC انجام می‌دهم و لاگ گزارش‌ها را برای دو هفته پایش می‌کنم. تجربه‌ام می‌گوید این عادت، در پیشگیری از بحران‌های ناخواسته تفاوت بزرگ می‌سازد.

سخن آخر: تفاوت دفاع و پاسخ‌گویی

SPF و DKIM، دو استاندارد دفاعی هستند؛ هر کدام در جای خودشان، جلوی بخشی از حملات را می‌گیرند. اما DMARC یک لایهٔ متفاوت است — لایه‌ای که هم دفاع می‌کند، هم گزارش می‌دهد، هم سیاست تعیین می‌کند. این سه‌گانه با هم، تصویری کامل از امنیت ایمیل دامنهٔ شما می‌سازند. اگر امروز فقط یک کار بتوانید انجام دهید، فعال‌سازی DMARC با سیاست p=none است — این کار، بدون هیچ ریسکی، به شما نشان می‌دهد که در دنیای ایمیل، چه کسی به نام دامنهٔ شما فعالیت می‌کند. به‌طور معمول، در ماه اول، شما از نتایج شگفت‌زده می‌شوید. اگر تجربه‌ای از فعال‌سازی DMARC دارید — به‌خصوص موردی که با خطای هم‌راستایی یا سرویس‌های ناشناخته روبه‌رو شده — خوشحال می‌شوم در دیدگاه‌ها بخوانم. برای خوانندهٔ بعدی که در آغاز این مسیر است، همان تجربه، از هر مستند رسمی مفیدتر خواهد بود. ✉️