DMARC چیست؟ جلوگیری از جعل و سوءاستفاده از ایمیل دامنه با DMARC

DMARC چیست؟ DMARC مخفف عبارت Domain-based Message Authentication, Reporting and Conformance است و به پروتکلی امنیتی برای احراز هویت ایمیل‌ها، مقابله با جعل آدرس فرستنده (Email Spoofing) و کاهش حملات فیشینگ گفته می‌شود. این فناوری با بررسی نتایج SPF و DKIM و تطبیق دامنه‌های احراز هویت‌شده با دامنه فرستنده، به سرور دریافت‌کننده کمک می‌کند تشخیص دهد آیا ایمیل از منابع مجاز ارسال شده است یا خیر. مدیر دامنه نیز می‌تواند تعیین کند ایمیل‌های نامعتبر چگونه پردازش شوند و گزارش‌هایی درباره استفاده از دامنه خود دریافت کند.

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

DMARC چیست و چه کاربردی در امنیت ایمیل دارد؟

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

با وجود اهمیت بالای ایمیل، معماری اولیه این فناوری به‌گونه‌ای طراحی نشده بود که به‌تنهایی بتواند هویت فرستنده را به‌شکل مطمئن تأیید کند. همین محدودیت باعث شده است جعل آدرس فرستنده یکی از روش‌های شناخته‌شده در حملات مهندسی اجتماعی باشد.

تصور کنید دامنه یک شرکت example.com است و مشتریان معمولاً ایمیل‌های رسمی آن را از آدرس [email protected] دریافت می‌کنند. مهاجم ممکن است تلاش کند پیامی ارسال کند که در قسمت فرستنده، همین آدرس نمایش داده شود؛ درحالی‌که پیام از سرور متعلق به شرکت ارسال نشده است.

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

DMARC برای کاهش این خطر طراحی شده است.

این پروتکل با استفاده از زیرساخت DNS و نتایج دو سازوکار SPF و DKIM، مشخص می‌کند آیا هویت دامنه‌ای که در ایمیل به کاربر نمایش داده می‌شود با هویت تأییدشده پیام ارتباط معتبر دارد یا خیر.

DMARC سه قابلیت اصلی ارائه می‌دهد:

• احراز هویت مبتنی بر دامنه: بررسی ارتباط دامنه فرستنده قابل‌مشاهده با دامنه‌های تأییدشده توسط SPF یا DKIM.
• اعمال سیاست امنیتی: اعلام اینکه با پیام‌هایی که بررسی DMARC را نمی‌گذرانند چگونه برخورد شود.
• گزارش‌گیری: دریافت اطلاعات درباره منابع ارسال‌کننده ایمیل و نتایج بررسی احراز هویت.

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

چرا جعل ایمیل دامنه یک تهدید امنیتی جدی است؟

جعل ایمیل یا Email Spoofing زمانی اتفاق می‌افتد که فرستنده تلاش می‌کند یک پیام را با هویتی متفاوت از هویت واقعی خود نمایش دهد.

این مسئله می‌تواند برای سازمان‌ها، وب‌سایت‌ها و حتی کاربران عادی پیامدهای قابل‌توجهی داشته باشد.

حملات فیشینگ با استفاده از نام دامنه معتبر

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

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

برای مثال، کاربری ممکن است ایمیلی ظاهراً از بخش پشتیبانی یک فروشگاه دریافت کند که ادعا می‌کند حساب او به تأیید مجدد نیاز دارد.

اگر آدرس فرستنده معتبر به نظر برسد، احتمال اعتماد کاربر به محتوای پیام افزایش پیدا می‌کند.

DMARC می‌تواند به سرورهای دریافت‌کننده کمک کند چنین جعل مستقیمی را شناسایی کرده و بر اساس سیاست منتشرشده برای دامنه با آن برخورد کنند.

حملات Business Email Compromise

حملات Business Email Compromise یا BEC نوعی کلاهبرداری مبتنی بر مکاتبات تجاری هستند.

در این حملات، مهاجم ممکن است خود را مدیرعامل، مسئول مالی، تأمین‌کننده یا یکی از کارکنان سازمان معرفی کند.

هدف معمولاً تغییر اطلاعات پرداخت، درخواست انتقال وجه یا دریافت اطلاعات محرمانه است.

برای نمونه، یک شرکت ممکن است پیامی ظاهراً از طرف مدیر مالی دریافت کند که در آن درخواست تغییر شماره حساب مقصد یک پرداخت مطرح شده است.

DMARC می‌تواند بخشی از حملات مبتنی بر جعل مستقیم دامنه را محدود کند؛ بااین‌حال تمام روش‌های BEC را متوقف نمی‌کند.

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

به همین دلیل مقابله با BEC علاوه بر DMARC به احراز هویت چندمرحله‌ای، کنترل دسترسی و فرایندهای مستقل تأیید درخواست‌های مالی نیاز دارد.

آسیب به اعتبار دامنه و برند

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

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

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

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

سوءاستفاده از ایمیل‌های فروشگاهی

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

این پیام‌ها به دلیل ارتباط با اطلاعات مالی و حساب کاربری، هدف مناسبی برای جعل هویت هستند.

مهاجم ممکن است از ظاهر ایمیل سفارش یا اعلان پرداخت سوءاستفاده کند تا مشتری را به صفحه‌ای غیرواقعی هدایت کند.

استفاده از DMARC در کنار SPF و DKIM می‌تواند احتمال پذیرش ایمیل‌هایی را که مستقیماً دامنه فروشگاه را جعل می‌کنند کاهش دهد.

DMARC چگونه کار می‌کند؟

برای درک نحوه عملکرد DMARC باید ابتدا بدانیم یک ایمیل از چه بخش‌هایی تشکیل شده و هویت فرستنده چگونه در سیستم‌های ایمیل بررسی می‌شود.

وقتی پیامی ارسال می‌شود، چند هویت دامنه‌ای ممکن است در فرایند انتقال آن حضور داشته باشند.

یکی از مهم‌ترین آن‌ها دامنه موجود در فیلد From است؛ یعنی همان آدرسی که معمولاً کاربر در نرم‌افزار ایمیل مشاهده می‌کند.

DMARC این دامنه را با دامنه‌هایی مقایسه می‌کند که از طریق SPF یا DKIM احراز هویت شده‌اند.

مرحله اول: دریافت ایمیل توسط سرور مقصد

فرض کنید کاربری پیامی از آدرس [email protected] به یک حساب Gmail ارسال می‌کند.

سرور مقصد پیام را دریافت کرده و اطلاعات لازم برای بررسی هویت آن را استخراج می‌کند.

این اطلاعات می‌تواند شامل آدرس IP سرور ارسال‌کننده، دامنه Envelope From، امضای DKIM و آدرس From قابل‌مشاهده باشد.

سپس بررسی‌های احراز هویت انجام می‌شوند.

مرحله دوم: بررسی SPF

SPF مخفف Sender Policy Framework است.

این سازوکار به مالک دامنه اجازه می‌دهد سرورها یا سرویس‌هایی را معرفی کند که مجاز به ارسال ایمیل با هویت مشخص‌شده در فرایند SMTP هستند.

سرور مقصد رکورد SPF مربوط به دامنه مناسب را بررسی می‌کند و نتیجه را با اطلاعات اتصال و پیام مقایسه می‌کند.

نتیجه ممکن است Pass، Fail یا وضعیت‌های دیگری مانند Softfail، Neutral، None، Temperror و Permerror باشد.

موفقیت SPF به‌تنهایی برای موفقیت DMARC کافی نیست.

دامنه احراز هویت‌شده توسط SPF باید با دامنه موجود در From نیز هم‌راستا باشد.

مرحله سوم: اعتبارسنجی DKIM

DKIM مخفف DomainKeys Identified Mail است.

در این فناوری، سرور ارسال‌کننده با استفاده از کلید خصوصی، امضایی رمزنگاری‌شده به ایمیل اضافه می‌کند.

سرور دریافت‌کننده با استفاده از کلید عمومی منتشرشده در DNS، اعتبار امضا را بررسی می‌کند.

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

بااین‌حال، DKIM به‌تنهایی ثابت نمی‌کند شخص یا سازمانی که در محتوای ایمیل معرفی شده واقعاً قابل‌اعتماد است.

همچنین برای موفقیت DMARC، دامنه امضاکننده DKIM باید با دامنه From هم‌راستا باشد.

مرحله چهارم: بررسی Alignment

Alignment یا هم‌راستایی دامنه، بخش کلیدی DMARC است.

ممکن است ایمیلی SPF موفق داشته باشد، اما دامنه‌ای که SPF برای آن تأیید شده با دامنه نمایشی فرستنده متفاوت باشد.

برای مثال:

• دامنه From: example.com
• دامنه تأییدشده SPF: other-service.net

در چنین شرایطی، SPF می‌تواند موفق باشد ولی SPF Alignment برقرار نباشد.

در مورد DKIM نیز همین موضوع مطرح است.

اگر امضای معتبر مربوط به دامنه‌ای نامرتبط باشد، به‌تنهایی باعث موفقیت DMARC برای example.com نمی‌شود.

برای موفقیت DMARC کافی است حداقل یکی از دو مسیر زیر برقرار باشد:

1. SPF موفق باشد و دامنه احراز هویت‌شده SPF با From هم‌راستا باشد.
2. DKIM موفق باشد و دامنه امضاکننده معتبر DKIM با From هم‌راستا باشد.

بنابراین الزامی نیست هر دو مسیر هم‌زمان موفق شوند.

مرحله پنجم: بررسی سیاست DMARC

اگر پیام بررسی DMARC را با موفقیت پشت سر نگذارد، دریافت‌کننده سیاست منتشرشده توسط مالک دامنه را بررسی می‌کند.

این سیاست می‌تواند یکی از سه مقدار اصلی زیر باشد:

• p=none
• p=quarantine
• p=reject

هرکدام از این مقادیر رفتار درخواستی متفاوتی را مشخص می‌کنند.

اجرای نهایی سیاست در اختیار سرور دریافت‌کننده است؛ بنابراین DMARC تضمین نمی‌کند تمام سرویس‌های ایمیل دقیقاً یک رفتار یکسان داشته باشند.

تفاوت DMARC با SPF و DKIM چیست؟

سه فناوری DMARC، SPF و DKIM مکمل یکدیگر هستند، اما کاربرد یکسانی ندارند.

چرا SPF به‌تنهایی کافی نیست؟

SPF به سرور دریافت‌کننده کمک می‌کند تعیین کند آیا سرور ارسال‌کننده برای هویت دامنه‌ای بررسی‌شده مجاز است یا خیر.

اما دامنه SPF همیشه همان دامنه‌ای نیست که کاربر در From مشاهده می‌کند.

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

DMARC با بررسی Alignment این فاصله را پوشش می‌دهد.

چرا DKIM به‌تنهایی کافی نیست؟

DKIM اعتبار امضای پیام را بررسی می‌کند.

اما یک ایمیل می‌تواند توسط دامنه‌ای امضا شود که هیچ ارتباطی با دامنه نمایشی فرستنده ندارد.

برای مثال، یک سرویس ارسال ایمیل ممکن است پیام را با دامنه خودش امضا کند.

اگر دامنه امضاکننده با دامنه From هم‌راستا نباشد، موفقیت آن امضا برای عبور از DMARC کافی نخواهد بود.

چرا استفاده هم‌زمان اهمیت دارد؟

SPF و DKIM دو مسیر متفاوت احراز هویت فراهم می‌کنند.

SPF بیشتر به هویت دامنه‌ای مرتبط با مسیر ارسال و سرور فرستنده توجه دارد، درحالی‌که DKIM بر امضای رمزنگاری‌شده پیام تکیه می‌کند.

استفاده صحیح از هر دو فناوری، تاب‌آوری زیرساخت ایمیل را افزایش می‌دهد.

برای مثال، در بعضی سناریوهای Forwarding، بررسی SPF ممکن است ناموفق شود، اما امضای DKIM معتبر و هم‌راستا باقی بماند.

در این حالت پیام همچنان می‌تواند DMARC را با موفقیت پشت سر بگذارد.

به همین دلیل پیاده‌سازی SPF و DKIM به همراه DMARC از اتکا به یک سازوکار منفرد مناسب‌تر است.

رکورد DMARC چیست و در DNS چگونه تعریف می‌شود؟

رکورد DMARC یک رکورد TXT در سامانه DNS دامنه است که سیاست احراز هویت و تنظیمات گزارش‌گیری ایمیل را اعلام می‌کند.

این رکورد معمولاً در نامی با پیشوند _dmarc منتشر می‌شود.

برای دامنه example.com، محل انتشار رکورد به‌صورت زیر است:

_dmarc.example.com

یک نمونه ساده از رکورد DMARC:

v=DMARC1; p=none; rua=mailto:[email protected]

این مثال یک تنظیم ابتدایی برای نظارت بر وضعیت احراز هویت ایمیل است.

پیش از استفاده از آن باید مطمئن شوید صندوق گزارش‌گیری ساخته شده یا سرویس مربوط به دریافت گزارش‌ها فعال است.

پارامتر v در DMARC

پارامتر v نسخه پروتکل را تعیین می‌کند.

مقدار متداول آن به‌شکل زیر است:

v=DMARC1

این مقدار باید در ابتدای رکورد DMARC قرار بگیرد.

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

پارامتر p و سیاست امنیتی دامنه

پارامتر p مشخص می‌کند مالک دامنه چه رفتاری را برای پیام‌های ناموفق درخواست می‌کند.

برای نمونه:

p=reject

این مقدار به دریافت‌کنندگان پشتیبان DMARC اعلام می‌کند پیام‌هایی را که بررسی DMARC را پشت سر نمی‌گذارند رد کنند.

انتخاب این مقدار باید پس از بررسی منابع قانونی ارسال ایمیل انجام شود.

پارامتر rua برای گزارش‌های تجمیعی

پارامتر rua مقصد گزارش‌های Aggregate را تعیین می‌کند.

مثال:

rua=mailto:[email protected]

گزارش‌های تجمیعی معمولاً اطلاعاتی درباره منابع ارسال، تعداد پیام‌ها، نتایج احراز هویت و سیاست اعمال‌شده ارائه می‌کنند.

این گزارش‌ها معمولاً در قالب XML تولید می‌شوند.

پارامتر ruf برای گزارش‌های خطا

پارامتر ruf برای معرفی مقصد گزارش‌های مربوط به برخی شکست‌های احراز هویت استفاده می‌شود.

نمونه:

ruf=mailto:[email protected]

نکته مهم این است که تمام سرویس‌های دریافت‌کننده ایمیل از ارسال این نوع گزارش پشتیبانی نمی‌کنند.

همچنین به دلیل ملاحظات حریم خصوصی، ممکن است داده‌های آن محدود شوند یا اصلاً ارسال نشوند.

بنابراین نباید طراحی سامانه نظارت DMARC را صرفاً بر دریافت گزارش‌های RUF استوار کرد.

پارامتر pct

این پارامتر در چارچوب DMARC مبتنی بر RFC 7489 برای تعیین درصد پیام‌های مشمول اجرای سیاست استفاده می‌شود.

برای مثال:

pct=25

این مقدار برای اجرای تدریجی سیاست روی بخشی از پیام‌های مشمول طراحی شده است.

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

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

پارامتر sp برای زیردامنه‌ها

پارامتر sp سیاست مورد درخواست برای زیردامنه‌های مشمول سیاست دامنه اصلی را مشخص می‌کند.

برای مثال:

sp=reject

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

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

پارامترهای adkim و aspf

این دو پارامتر حالت Alignment را تعیین می‌کنند.

adkim برای DKIM و aspf برای SPF استفاده می‌شود.

مقادیر اصلی عبارت‌اند از:

• r برای حالت Relaxed
• s برای حالت Strict

در حالت Relaxed، تطبیق بر مبنای دامنه سازمانی انجام می‌شود.

در حالت Strict، تطبیق دقیق نام دامنه لازم است.

برای بسیاری از سازمان‌هایی که چند سرویس ارسال ایمیل دارند، حالت Relaxed انعطاف‌پذیری بیشتری فراهم می‌کند.

سیاست‌های DMARC؛ تفاوت none، quarantine و reject

انتخاب سیاست DMARC یکی از مهم‌ترین تصمیمات امنیتی در مدیریت ایمیل دامنه است.

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

در مقابل، سیاستی که صرفاً بر نظارت تمرکز دارد، نمی‌تواند سطح یکسانی از مقابله با جعل دامنه ایجاد کند.

سیاست p=none

در این حالت مالک دامنه درخواست نمی‌کند پیام صرفاً به دلیل شکست DMARC قرنطینه یا رد شود.

مثال:

v=DMARC1; p=none; rua=mailto:[email protected]

این سیاست برای مرحله آغازین استقرار بسیار مفید است.

با استفاده از آن می‌توان اطلاعات لازم درباره فرستندگان مجاز و نامجاز را جمع‌آوری کرد.

از مزایای آن می‌توان به امکان شناسایی سرویس‌های ارسال ایمیل فراموش‌شده و بررسی مشکلات Alignment اشاره کرد.

اما p=none به معنای محافظت اجرایی در برابر جعل ایمیل نیست.

سرور دریافت‌کننده همچنان می‌تواند براساس فیلترهای مستقل خود پیام را مسدود کند، ولی این سیاست DMARC به‌تنهایی درخواست رد یا قرنطینه نمی‌دهد.

سیاست p=quarantine

این سیاست درخواست می‌کند پیام‌های ناموفق به‌عنوان پیام مشکوک پردازش شوند.

مثال:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

بسته به سیاست سرویس مقصد، پیام ممکن است وارد پوشه Spam شود یا تحت بررسی‌های سخت‌گیرانه‌تری قرار بگیرد.

این سیاست می‌تواند مرحله‌ای بین نظارت و رد کامل پیام باشد.

برای سازمان‌هایی که منابع ارسال خود را تا حد زیادی شناسایی کرده‌اند، استفاده کنترل‌شده از Quarantine می‌تواند بخشی از فرایند استقرار باشد.

سیاست p=reject

در این حالت مالک دامنه درخواست می‌کند پیام‌هایی که DMARC را پشت سر نمی‌گذارند رد شوند.

نمونه:

v=DMARC1; p=reject; rua=mailto:[email protected]

این سیاست معمولاً قوی‌ترین گزینه اجرایی DMARC برای مقابله با جعل مستقیم دامنه محسوب می‌شود.

بااین‌حال، Reject تضمین نمی‌کند هر ایمیل جعلی در تمام سرویس‌های جهان مسدود شود.

سرور دریافت‌کننده درباره پردازش نهایی پیام اختیار دارد و ممکن است بر اساس سیاست محلی تصمیم دیگری بگیرد.

کدام سیاست DMARC مناسب‌تر است؟

برای دامنه‌ای که هنوز وضعیت منابع ارسال ایمیل آن مشخص نیست، فعال‌سازی مستقیم Reject ممکن است باعث اختلال شود.

در مقابل، باقی ماندن دائمی در حالت None نیز به معنی استفاده نکردن از مهم‌ترین قابلیت اجرایی DMARC است.

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

آموزش تنظیم DMARC در DNS دامنه

برای راه‌اندازی DMARC نیازی به نصب نرم‌افزار روی وب‌سایت نیست.

بخش اصلی تنظیمات از طریق پنل مدیریت DNS دامنه انجام می‌شود.

بااین‌حال، پیش از انتشار سیاست سخت‌گیرانه باید وضعیت SPF و DKIM بررسی شود.

مرحله اول: شناسایی سرویس‌های ارسال ایمیل

ابتدا مشخص کنید چه سرویس‌هایی با نام دامنه شما ایمیل ارسال می‌کنند.

این منابع ممکن است شامل موارد زیر باشند:

• سرور ایمیل اصلی شرکت
• سرویس ایمیل هاست
• سیستم ارسال ایمیل وردپرس
• نرم‌افزار CRM
• سامانه اطلاع‌رسانی پیامکی و ایمیلی
• سرویس بازاریابی ایمیلی
• سرویس ارسال فاکتور یا رسید پرداخت
• سیستم پشتیبانی مشتریان
• پلتفرم فروشگاه اینترنتی

نکته مهم این است که هر سرویس باید به‌درستی شناسایی شود.

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

این موضوع هنگام اعمال سیاست Reject می‌تواند مشکل‌ساز شود.

مرحله دوم: بررسی SPF

وارد پنل DNS شوید و رکورد SPF دامنه را بررسی کنید.

یک نمونه آموزشی از ساختار SPF:

v=spf1 ip4:192.0.2.10 -all

آدرس IP موجود در مثال، یک آدرس مستندسازی است و نباید بدون تغییر در تنظیمات واقعی استفاده شود.

در محیط عملی باید آدرس‌های معتبر و سرویس‌های مجاز مطابق مستندات ارائه‌دهندگان ایمیل تعریف شوند.

همچنین برای هر نام دامنه نباید چند رکورد SPF مستقل از نوع TXT با نسخه v=spf1 منتشر شود؛ زیرا این کار می‌تواند باعث خطای SPF شود.

در صورت استفاده از چند سرویس، باید تنظیمات در قالب یک سیاست معتبر مدیریت شوند.

مرحله سوم: بررسی DKIM

وارد بخش تنظیمات سرویس ایمیل خود شوید.

بسیاری از سرویس‌دهندگان حرفه‌ای، رکوردهای موردنیاز DKIM را در اختیار مدیر دامنه قرار می‌دهند.

این رکوردها ممکن است از نوع TXT یا CNAME باشند.

ساختار دقیق آن‌ها به ارائه‌دهنده خدمات ایمیل بستگی دارد.

بعد از انتشار رکورد، باید فعال بودن امضای DKIM برای ایمیل‌های خروجی بررسی شود.

صرف وجود رکورد در DNS به معنی امضای موفق تمام پیام‌ها نیست.

همچنین دامنه موجود در فیلد d= امضای DKIM باید برای DMARC با دامنه From هم‌راستا باشد.

مرحله چهارم: ایجاد رکورد DMARC

پس از بررسی SPF و DKIM، رکورد DMARC را ایجاد کنید.

در پنل DNS یک رکورد جدید با مشخصات زیر بسازید:

Type:

TXT

Name:

_dmarc

Value:

v=DMARC1; p=none; rua=mailto:[email protected]

به‌جای example.com باید دامنه واقعی خود را قرار دهید.

همچنین آدرس گزارش‌گیری باید به صندوق یا سرویس دریافت گزارش واقعی اشاره کند.

در برخی پنل‌ها باید نام کامل _dmarc.example.com وارد شود، اما در پنل‌هایی که نام دامنه را به‌صورت خودکار اضافه می‌کنند، مقدار _dmarc کافی است.

پیش از ذخیره، رفتار پنل DNS را بررسی کنید تا نام رکورد دوبار تکرار نشود.

مرحله پنجم: انتظار برای انتشار DNS

تغییرات DNS ممکن است بلافاصله در تمام Resolverها مشاهده نشوند.

مدت انتشار و مشاهده تغییرات به TTL رکورد، کش DNS و شرایط زیرساخت بستگی دارد.

بنابراین پس از ذخیره رکورد باید انتشار صحیح آن بررسی شود.

مرحله ششم: بررسی نتیجه تنظیمات

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

dig TXT _dmarc.example.com +short

در ویندوز نیز امکان استفاده از دستور زیر وجود دارد:

nslookup -type=TXT _dmarc.example.com

نتیجه باید شامل رکورد معتبر DMARC باشد.

این بررسی فقط وجود و محتوای رکورد DNS را مشخص می‌کند.

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

آموزش تنظیم DMARC در cPanel

بسیاری از مدیران وب‌سایت از cPanel برای مدیریت هاست، ایمیل و تنظیمات DNS استفاده می‌کنند.

در این محیط می‌توان رکورد DMARC را از طریق ابزار مدیریت DNS منتشر کرد؛ البته به شرط آنکه DNS دامنه واقعاً توسط همان زیرساخت مدیریت شود.

ورود به Zone Editor

ابتدا وارد cPanel شوید و بخش Zone Editor را باز کنید.

دامنه موردنظر را انتخاب کرده و وارد قسمت مدیریت رکوردهای DNS شوید.

در این قسمت امکان مشاهده و ویرایش رکوردهای مرتبط با دامنه وجود دارد.

اگر Nameserverهای دامنه به سرویس دیگری مانند Cloudflare اشاره می‌کنند، باید تغییرات را در DNS معتبر همان سرویس انجام دهید.

افزودن رکورد در یک Zone غیرفعال تأثیری بر نتیجه بررسی عمومی DNS ندارد.

بررسی Email Deliverability

در بسیاری از نسخه‌های cPanel بخشی با عنوان Email Deliverability وجود دارد.

این بخش می‌تواند برای بررسی برخی تنظیمات مرتبط با SPF و DKIM مفید باشد.

اگر سیستم هشدار مربوط به رکوردهای احراز هویت نمایش دهد، باید علت آن بررسی شود.

البته وضعیت این صفحه به‌تنهایی تأییدکننده پیاده‌سازی صحیح DMARC برای تمام سرویس‌های ارسال‌کننده نیست.

انتشار رکورد TXT

پس از اطمینان از محل مدیریت DNS، رکورد TXT مربوط به DMARC را منتشر کنید.

بهتر است تنظیم اولیه با سیاست None آغاز شود.

پس از انتشار، با استفاده از ابزارهای DNS و بررسی پیام‌های واقعی، صحت عملکرد را تأیید کنید.

تنظیم DMARC در Cloudflare

Cloudflare یکی از سرویس‌های رایج برای مدیریت DNS دامنه است.

اگر Nameserverهای دامنه شما روی Cloudflare قرار دارند، معمولاً باید رکورد DMARC را از پنل DNS همین سرویس مدیریت کنید.

ایجاد رکورد جدید

وارد داشبورد Cloudflare شوید.

دامنه را انتخاب کنید و به بخش DNS Records بروید.

یک رکورد جدید از نوع TXT اضافه کنید.

در قسمت Name مقدار زیر را وارد کنید:

_dmarc

سپس متن سیاست DMARC را در قسمت Content یا Value قرار دهید.

برای شروع می‌توانید از سیاست نظارتی استفاده کنید.

نکات مهم درباره DNS در Cloudflare

رکوردهای TXT برای DMARC مانند رکوردهای وب‌سایت از حالت پروکسی HTTP استفاده نمی‌کنند.

وجود Cloudflare نیز به‌تنهایی به معنی فعال بودن DMARC نیست.

همچنین اگر DNS دامنه در Cloudflare مدیریت می‌شود، تغییر رکورد در پنل هاست لزوماً اثری نخواهد داشت.

پس از ذخیره، رکورد منتشرشده را با ابزارهای بررسی DNS کنترل کنید.

Alignment در DMARC چیست؟

Alignment به معنی هم‌راستایی دامنه احراز هویت‌شده با دامنه موجود در فیلد From ایمیل است.

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

حالت Relaxed Alignment

در حالت Relaxed، دامنه‌های مرتبط که از نظر دامنه سازمانی یکسان هستند می‌توانند هم‌راستا محسوب شوند.

برای مثال:

• From: [email protected]
• DKIM d=: mail.example.com

در این شرایط، اگر سایر الزامات برقرار باشند، هم‌راستایی DKIM می‌تواند موفق باشد.

این حالت برای سازمان‌هایی که از زیردامنه‌های مختلف برای ارسال ایمیل استفاده می‌کنند مناسب است.

حالت Strict Alignment

در حالت Strict، دامنه‌ها باید دقیقاً یکسان باشند.

برای مثال:

• From: [email protected]
• DKIM d=: example.com

در این حالت هم‌راستایی برقرار است.

اما اگر DKIM از mail.example.com استفاده کند، با وجود ارتباط سازمانی، تطبیق Strict با example.com برقرار نخواهد بود.

آیا Strict همیشه امن‌تر است؟

Strict محدودیت بیشتری در تطبیق دامنه اعمال می‌کند، اما انتخاب آن لزوماً برای همه سازمان‌ها مناسب نیست.

ممکن است یک سرویس معتبر ارسال ایمیل از زیردامنه‌ای استفاده کند که با ساختار Strict سازگار نیست.

در چنین شرایطی، بدون تنظیم دقیق زیرساخت، احتمال شکست DMARC افزایش پیدا می‌کند.

بنابراین انتخاب حالت Alignment باید با توجه به معماری واقعی سرویس‌های ایمیل انجام شود.

گزارش‌های DMARC چیست و چه اطلاعاتی ارائه می‌کنند؟

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

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

گزارش‌ها برای شناسایی پیکربندی اشتباه و تشخیص الگوهای مشکوک کاربرد دارند.

گزارش Aggregate یا RUA

گزارش Aggregate معمولاً اطلاعات آماری و تجمیعی درباره پیام‌ها ارائه می‌کند.

این اطلاعات ممکن است شامل موارد زیر باشد:

• دامنه مشمول سیاست DMARC
• آدرس IP منبع ارسال
• تعداد پیام‌های مشاهده‌شده
• نتیجه بررسی SPF
• نتیجه بررسی DKIM
• نتیجه ارزیابی سیاست DMARC
• وضعیت Alignment
• تصمیم گزارش‌شده درباره پردازش پیام

این گزارش‌ها معمولاً در قالب XML ارسال می‌شوند.

بنابراین مطالعه مستقیم آن‌ها برای بسیاری از مدیران سایت ساده نیست.

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

گزارش Failure یا RUF

گزارش‌های Failure برای ارائه اطلاعات درباره برخی رخدادهای عدم موفقیت احراز هویت طراحی شده‌اند.

بااین‌حال، پشتیبانی از آن‌ها در سرویس‌های دریافت‌کننده یکسان نیست.

ملاحظات حریم خصوصی و سیاست‌های ارائه‌دهندگان نیز می‌تواند باعث محدود شدن ارسال چنین گزارش‌هایی شود.

بنابراین نبود گزارش RUF لزوماً نشان‌دهنده نبود حمله یا نبود خطای احراز هویت نیست.

چگونه گزارش‌های DMARC را تحلیل کنیم؟

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

سپس نتیجه احراز هویت هر منبع بررسی شود.

اگر یک سرویس قانونی حجم زیادی ایمیل با DMARC Fail ارسال می‌کند، احتمال وجود مشکل پیکربندی مطرح است.

اما اگر IP ناشناسی پیام‌هایی با دامنه شما ارسال می‌کند، ممکن است با یک سرویس فراموش‌شده، سامانه واسط یا تلاش برای جعل دامنه مواجه باشید.

صرف ناشناس بودن IP برای اثبات حمله کافی نیست.

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

آیا گزارش DMARC محتوای تمام ایمیل‌ها را نشان می‌دهد؟

خیر.

گزارش‌های Aggregate معمولاً داده‌های آماری و فنی ارائه می‌کنند و برای مشاهده کامل محتوای تمام پیام‌ها طراحی نشده‌اند.

گزارش‌های Failure نیز بسته به پشتیبانی و سیاست دریافت‌کننده ممکن است داده‌های محدودتری داشته باشند.

برای حفظ حریم خصوصی، بهتر است دسترسی به گزارش‌ها محدود و مدت نگهداری آن‌ها مشخص باشد.

چگونه از گزارش DMARC برای شناسایی سوءاستفاده از دامنه استفاده کنیم؟

گزارش‌های DMARC صرفاً برای عیب‌یابی نیستند و می‌توانند بخشی از فرایند پایش امنیت دامنه باشند.

برای استفاده مؤثر از آن‌ها باید یک روش مشخص برای بررسی تغییرات و تشخیص الگوهای غیرعادی وجود داشته باشد.

تهیه فهرست فرستندگان معتبر

ابتدا فهرستی از تمام سرویس‌هایی تهیه کنید که مجاز به ارسال ایمیل با نام دامنه هستند.

برای هر سرویس اطلاعاتی مانند نام ارائه‌دهنده، هدف ارسال، دامنه DKIM و دامنه SPF را ثبت کنید.

این فهرست به شما کمک می‌کند منابع ناشناس را سریع‌تر شناسایی کنید.

بررسی افزایش ناگهانی پیام‌های ناموفق

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

ممکن است یکی از سرویس‌های قانونی دچار مشکل شده باشد.

همچنین احتمال دارد فردی در حال تلاش برای ارسال پیام با هویت جعل‌شده دامنه باشد.

برای تشخیص این وضعیت، منبع IP، زمان وقوع و الگوی پیام‌ها اهمیت دارد.

بررسی تغییرات در سرویس‌های ارسال

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

ممکن است سرویس جدید به تنظیمات DNS یا فعال‌سازی DKIM اختصاصی نیاز داشته باشد.

اگر این تغییرات ثبت نشوند، شناسایی علت شکست احراز هویت در آینده دشوار خواهد شد.

بررسی مستمر پس از اعمال Reject

رسیدن به سیاست Reject پایان فرایند مدیریت DMARC نیست.

ساختار ارسال ایمیل سازمان ممکن است تغییر کند.

برای مثال، استفاده از سرویس جدید اطلاع‌رسانی یا جابه‌جایی ارائه‌دهنده ایمیل می‌تواند وضعیت احراز هویت را تغییر دهد.

به همین دلیل بررسی دوره‌ای گزارش‌ها پس از اجرای سیاست سخت‌گیرانه نیز ضروری است.

DMARC چگونه از ایمیل‌های وردپرس محافظت می‌کند؟

وردپرس در بسیاری از وب‌سایت‌ها برای ارسال اعلان‌ها و پیام‌های سیستمی استفاده می‌شود.

این پیام‌ها ممکن است شامل بازیابی رمز عبور، اطلاع‌رسانی ثبت‌نام، فرم تماس یا اعلان‌های مدیریتی باشند.

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

مشکل ارسال ایمیل با تابع پیش‌فرض PHP

برخی سایت‌های وردپرسی از قابلیت ارسال ایمیل سرور یا تابع wp_mail() استفاده می‌کنند.

این تابع بسته به پیکربندی وردپرس، افزونه‌ها و زیرساخت سرور می‌تواند به روش‌های مختلفی پیام را ارسال کند.

بنابراین استفاده از wp_mail() به‌تنهایی تضمین نمی‌کند SPF و DKIM به‌درستی برقرار باشند.

اگر دامنه From با دامنه احراز هویت‌شده هم‌راستا نباشد، پیام ممکن است DMARC را پشت سر نگذارد.

استفاده از SMTP معتبر

برای بسیاری از سایت‌ها، استفاده از یک سرویس ایمیل تراکنشی یا SMTP معتبر می‌تواند مدیریت احراز هویت را ساده‌تر کند.

اما صرف نصب افزونه SMTP کافی نیست.

باید بررسی شود که:

• سرور ارسال‌کننده مجاز است.
• DKIM فعال و معتبر است.
• دامنه From درست انتخاب شده است.
• حداقل یکی از دو مسیر SPF یا DKIM با From هم‌راستا است.
• ایمیل‌های آزمایشی با موفقیت اعتبارسنجی می‌شوند.

اهمیت DMARC برای فرم‌های تماس

یکی از اشتباهات رایج در فرم‌های تماس وردپرس، قرار دادن آدرس ایمیل بازدیدکننده در فیلد From است.

برای مثال، کاربری فرم تماس سایت را با آدرس شخصی خود تکمیل می‌کند و سامانه تلاش می‌کند پیام را مستقیماً با همان آدرس به‌عنوان فرستنده ارسال کند.

در این حالت ممکن است سرور سایت مجوز ارسال ایمیل از طرف دامنه بازدیدکننده را نداشته باشد.

راهکار مناسب این است که From از دامنه تحت کنترل وب‌سایت انتخاب شود و آدرس بازدیدکننده در بخش Reply-To قرار بگیرد.

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

اهمیت DMARC برای امنیت ووکامرس

فروشگاه‌های ووکامرسی حجم قابل‌توجهی ایمیل تراکنشی ارسال می‌کنند.

اعلان‌های سفارش، رسید پرداخت، وضعیت ارسال، ایجاد حساب و بازیابی رمز عبور از مهم‌ترین پیام‌های این سامانه هستند.

این ایمیل‌ها علاوه بر اهمیت عملیاتی، با اعتماد کاربران و امنیت حساب‌های آن‌ها ارتباط دارند.

محافظت از اعتبار ایمیل‌های سفارش

اگر فردی بتواند دامنه فروشگاه را جعل کند، ممکن است پیام‌هایی ظاهراً شبیه تأیید سفارش یا درخواست پرداخت برای مشتریان ارسال کند.

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

البته همچنان باید به طراحی امنیتی قالب ایمیل، لینک‌های معتبر و آموزش مشتریان توجه شود.

جلوگیری از اختلال در تحویل اعلان‌ها

وقتی سیاست DMARC سخت‌گیرانه اعمال می‌شود، پیکربندی اشتباه سرویس ارسال ووکامرس می‌تواند باعث رد پیام‌های قانونی شود.

به همین دلیل قبل از فعال‌سازی Reject باید چند نوع پیام آزمایشی بررسی شود.

از جمله:

• ایمیل ثبت سفارش
• ایمیل تغییر وضعیت سفارش
• بازیابی رمز عبور
• اعلان ایجاد حساب
• پیام‌های مدیریتی فروشگاه

هدف این است که تمام مسیرهای واقعی ارسال ایمیل شناسایی شوند.

استفاده از زیردامنه مخصوص ایمیل‌های تراکنشی

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

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

این معماری می‌تواند مدیریت اعتبار ارسال و سیاست‌های احراز هویت را ساده‌تر کند.

بااین‌حال، پیکربندی SPF، DKIM، DMARC و دامنه From باید متناسب با ساختار واقعی سرویس انجام شود.

استفاده از زیردامنه به‌تنهایی مشکل احراز هویت را حل نمی‌کند.

آیا DMARC از ورود ایمیل به پوشه اسپم جلوگیری می‌کند؟

یکی از برداشت‌های اشتباه این است که فعال‌سازی DMARC باعث می‌شود تمام ایمیل‌های سایت وارد Inbox شوند.

در واقع DMARC یک سازوکار احراز هویت دامنه است، نه تضمین‌کننده تحویل ایمیل.

سرویس‌های ایمیل هنگام تصمیم‌گیری درباره پذیرش و دسته‌بندی پیام، عوامل متعددی را بررسی می‌کنند.

اعتبار IP و دامنه

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

اعتبار ارسال تحت تأثیر عواملی مانند شکایت کاربران، نرخ ارسال و الگوهای رفتاری قرار می‌گیرد.

کیفیت محتوای ایمیل

وجود محتوای فریبنده، لینک‌های مشکوک یا الگوهای رایج اسپم می‌تواند بر طبقه‌بندی پیام اثر بگذارد.

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

تنظیمات زیرساخت ارسال

تنظیم صحیح Reverse DNS یا PTR، استفاده از TLS، رعایت استانداردهای قالب‌بندی ایمیل و مدیریت مناسب صف ارسال نیز اهمیت دارند.

تعامل کاربران

برخی سرویس‌های ایمیل از سیگنال‌های مرتبط با رفتار دریافت‌کنندگان برای ارزیابی کیفیت ارسال استفاده می‌کنند.

بنابراین حتی پس از اجرای صحیح DMARC باید کیفیت ارسال و نرخ شکایت بررسی شود.

نتیجه این است که DMARC می‌تواند یکی از اجزای مهم زیرساخت ارسال معتبر باشد، اما به‌تنهایی تضمین‌کننده ورود ایمیل به Inbox نیست.

آیا DMARC برای Gmail و سایر سرویس‌های ایمیل ضروری است؟

ارائه‌دهندگان بزرگ ایمیل در سال‌های اخیر الزامات احراز هویت پیام را سخت‌گیرانه‌تر کرده‌اند.

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

در الزامات مربوط به ارسال انبوه، هم‌راستایی دامنه From با حداقل یکی از هویت‌های SPF یا DKIM نیز اهمیت دارد.

در این چارچوب، وجود رکورد DMARC با سیاست p=none ممکن است برای تأمین حداقل الزام انتشار DMARC کافی باشد؛ اما این موضوع به معنای محافظت اجرایی در برابر جعل نیست.

برای سازمان‌هایی که امنیت دامنه اولویت بالایی دارد، هدف نهایی معمولاً فراتر از انتشار یک رکورد نظارتی است.

همچنین باید توجه داشت که شرایط سرویس‌دهندگان مختلف یکسان نیست و ممکن است در طول زمان تغییر کند.

بنابراین مدیران ایمیل باید علاوه بر استانداردهای فنی، الزامات ارائه‌دهندگان مقصد را نیز در زمان استقرار بررسی کنند.

محدودیت‌های DMARC در مقابله با حملات سایبری

DMARC یک کنترل امنیتی ارزشمند است، اما نمی‌تواند جایگزین تمام فناوری‌های محافظت از ایمیل شود.

شناخت محدودیت‌های آن باعث می‌شود انتظارات واقع‌بینانه‌ای از این پروتکل داشته باشیم.

عدم جلوگیری کامل از دامنه‌های مشابه

فرض کنید دامنه رسمی یک کسب‌وکار example.com باشد.

مهاجم ممکن است دامنه‌ای مشابه با تغییر جزئی حروف ثبت کند.

اگر ایمیل از دامنه مشابه ارسال شود، DMARC دامنه اصلی الزاماً ارتباطی با آن پیام ندارد.

بنابراین DMARC به‌تنهایی نمی‌تواند تمام حملات مبتنی بر Lookalike Domain یا Typosquatting را متوقف کند.

برای کاهش این ریسک، پایش دامنه‌های مشابه و آموزش کاربران نیز اهمیت دارد.

عدم محافظت در برابر حساب واقعی هک‌شده

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

در چنین شرایطی DMARC لزوماً نمی‌تواند تشخیص دهد پیام توسط مالک مجاز حساب نوشته شده یا توسط مهاجم.

فعال‌سازی MFA یا 2FA، کنترل نشست‌ها و پایش فعالیت حساب برای مقابله با این سناریو ضروری است.

عدم تشخیص مستقیم بدافزار

DMARC محتوا یا پیوست ایمیل را مانند یک موتور آنتی‌ویروس بررسی نمی‌کند.

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

بنابراین استفاده از فیلترهای ضدبدافزار، ضداسپم و سامانه‌های امنیت ایمیل همچنان لازم است.

محدودیت در Forwarding و Mailing List

ارسال مجدد ایمیل توسط سرویس‌های واسط ممکن است نتیجه SPF را تغییر دهد.

همچنین برخی فهرست‌های ایمیلی، محتوای پیام را تغییر می‌دهند و ممکن است امضای DKIM را نامعتبر کنند.

در چنین شرایطی، حتی پیام قانونی ممکن است با مشکل DMARC مواجه شود.

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

ARC نیز جایگزین مستقیم SPF، DKIM یا DMARC نیست.

اشتباهات رایج هنگام راه‌اندازی DMARC

بخش قابل‌توجهی از مشکلات DMARC ناشی از پیکربندی اشتباه یا نبود شناخت کافی از ساختار ارسال ایمیل سازمان است.

فعال‌سازی مستقیم Reject

اعمال سیاست Reject بدون بررسی منابع ارسال یکی از پرریسک‌ترین اشتباهات است.

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

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

تصور اینکه SPF Pass همیشه به معنی DMARC Pass است

موفقیت SPF بدون هم‌راستایی دامنه برای موفقیت DMARC کافی نیست.

این موضوع به‌خصوص در سرویس‌های ارسال ایمیل شخص ثالث اهمیت دارد.

فراموش کردن سرویس‌های ایمیل قدیمی

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

اگر این منابع در فهرست فرستندگان معتبر قرار نگیرند، اعمال سیاست سخت‌گیرانه ممکن است ارسال آن‌ها را مختل کند.

انتشار چند رکورد DMARC در یک نام

وجود چند رکورد DMARC معتبر و مستقل در یک محل DNS می‌تواند باعث شکست فرایند کشف سیاست شود.

برای هر نام دامنه مشمول، تنظیمات باید در قالب رکورد معتبر و مناسب مدیریت شوند.

اشتباه در نام رکورد DNS

گاهی مدیر سایت هنگام وارد کردن نام رکورد، دامنه را دوباره به آن اضافه می‌کند.

برای مثال ممکن است پنل به‌صورت خودکار example.com را اضافه کند، اما مدیر نیز نام کامل دامنه را وارد کرده باشد.

در این حالت رکورد در مسیر اشتباه منتشر می‌شود.

نبود صندوق گزارش‌گیری معتبر

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

نادیده گرفتن زیردامنه‌ها

ممکن است دامنه اصلی سیاست مناسبی داشته باشد، اما ساختار ارسال و سیاست زیردامنه‌ها به‌درستی بررسی نشده باشد.

در سازمان‌های بزرگ، این موضوع می‌تواند باعث ایجاد نقاط ضعف یا اختلال عملیاتی شود.

استفاده از سرویس گزارش‌گیری بدون بررسی حریم خصوصی

گزارش‌های DMARC می‌توانند شامل اطلاعات فنی درباره زیرساخت ارسال باشند.

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

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

چگونه خطاهای DMARC را عیب‌یابی کنیم؟

وقتی ایمیلی DMARC Fail دریافت می‌کند، بهتر است بررسی در چند مرحله انجام شود.

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

خطای SPF Fail

در این حالت باید بررسی شود IP سرور ارسال‌کننده از نظر سیاست SPF دامنه مربوطه مجاز است یا خیر.

همچنین باید وضعیت Forwarding و هویت Envelope From بررسی شود.

خطای DKIM Fail

شکست DKIM ممکن است به علت اشتباه بودن کلید منتشرشده، تغییر محتوای امضاشده یا مشکل در فرایند امضا رخ دهد.

برای رفع مشکل باید تنظیمات ارائه‌دهنده ایمیل و نتیجه اعتبارسنجی امضا بررسی شود.

خطای DMARC Fail با وجود SPF Pass

این وضعیت ممکن است به علت نبود هم‌راستایی SPF رخ دهد.

برای مثال، دامنه Envelope From با دامنه From متفاوت است و ارتباط لازم برای Alignment را ندارد.

در چنین شرایطی باید وضعیت DKIM نیز بررسی شود؛ زیرا DKIM معتبر و هم‌راستا می‌تواند باعث موفقیت DMARC شود.

خطای DMARC Fail با وجود DKIM Pass

اگر DKIM موفق باشد اما دامنه امضاکننده با From هم‌راستا نباشد، آن امضا برای موفقیت DMARC کافی نیست.

باید بررسی شود سرویس ارسال‌کننده امکان امضای پیام با دامنه اختصاصی را فراهم می‌کند یا خیر.

خطای DMARC Permerror

خطاهای دائمی می‌توانند به مشکلاتی مانند قالب نامعتبر رکورد یا وجود چند رکورد متعارض مربوط باشند.

برای بررسی باید رکورد منتشرشده در DNS و ساختار آن کنترل شود.

خطای DMARC Temperror

این وضعیت معمولاً به یک مشکل موقت در فرایند ارزیابی اشاره دارد.

برای مثال، اختلال موقت در پاسخ DNS می‌تواند باعث بروز مشکل شود.

در چنین شرایطی بررسی دسترس‌پذیری DNS و تکرار آزمایش پس از رفع اختلال اهمیت دارد.

چک‌لیست امنیتی راه‌اندازی DMARC

پیش از فعال‌سازی سیاست اجرایی، بهتر است موارد زیر بررسی شوند.

بررسی اولیه

• [ ] تمام سرویس‌های قانونی ارسال ایمیل شناسایی شده‌اند.
• [ ] رکورد SPF معتبر و بدون تداخل منتشر شده است.
• [ ] سرویس‌های اصلی از DKIM استفاده می‌کنند.
• [ ] دامنه From در پیام‌های خروجی بررسی شده است.
• [ ] وضعیت Alignment برای سرویس‌ها مشخص است.
• [ ] رکورد DMARC در DNS معتبر منتشر شده است.

بررسی گزارش‌گیری

• [ ] مقصد گزارش‌های Aggregate معتبر است.
• [ ] امکان دریافت و پردازش گزارش‌ها وجود دارد.
• [ ] منابع ناشناس ارسال بررسی می‌شوند.
• [ ] خطاهای سرویس‌های قانونی شناسایی شده‌اند.
• [ ] سطح دسترسی به اطلاعات گزارش‌ها کنترل شده است.

بررسی پیش از اجرای Reject

• [ ] ایمیل‌های اصلی سازمان با موفقیت DMARC را پشت سر می‌گذارند.
• [ ] ایمیل‌های وردپرس و ووکامرس آزمایش شده‌اند.
• [ ] سامانه‌های بازاریابی و پشتیبانی بررسی شده‌اند.
• [ ] تغییرات احتمالی سرویس‌های واسط تحلیل شده‌اند.
• [ ] مسئول مشخصی برای پایش وضعیت وجود دارد.
• [ ] برنامه بازگشت به سیاست قبلی در صورت بروز اختلال آماده است.

بررسی پس از استقرار

• [ ] گزارش‌ها به‌صورت دوره‌ای تحلیل می‌شوند.
• [ ] سرویس‌های جدید پیش از شروع ارسال احراز هویت می‌شوند.
• [ ] تغییرات DNS ثبت و بازبینی می‌شوند.
• [ ] هشدارهای مربوط به افزایش شکست‌های DMARC بررسی می‌شوند.
• [ ] سیاست زیردامنه‌ها متناسب با ساختار سازمان مدیریت می‌شود.

بهترین روش پیاده‌سازی DMARC در سازمان‌ها

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

تنها ایجاد رکورد DNS کافی نیست.

مرحله اول: شناخت زیرساخت

تمام سامانه‌های ارسال‌کننده شناسایی شوند و مسئول هر سرویس مشخص باشد.

در این مرحله باید دامنه‌های ارسال، سرویس‌دهندگان و تنظیمات احراز هویت مستندسازی شوند.

مرحله دوم: اصلاح احراز هویت

برای هر سرویس، SPF و DKIM مطابق امکانات ارائه‌دهنده بررسی و تنظیم شوند.

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

مرحله سوم: پایش با سیاست None

رکورد DMARC با سیاست نظارتی منتشر شود.

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

مدت این مرحله برای همه سازمان‌ها یکسان نیست.

سازمانی که ارسال‌های ماهانه یا فصلی دارد ممکن است برای مشاهده تمام جریان‌های ایمیلی به دوره طولانی‌تری نیاز داشته باشد.

مرحله چهارم: اصلاح خطاهای شناسایی‌شده

هر منبع قانونی که DMARC Fail دارد باید بررسی شود.

ممکن است اصلاح DKIM، تنظیم Return-Path اختصاصی یا تغییر پیکربندی سرویس ارسال ضروری باشد.

در این مرحله باید از ایجاد استثناهای غیرضروری و کاهش بی‌دلیل سخت‌گیری احراز هویت خودداری شود.

مرحله پنجم: اجرای سیاست سخت‌گیرانه

پس از اطمینان از عملکرد منابع قانونی، می‌توان سیاست Quarantine و سپس Reject را مطابق ریسک و نیاز عملیاتی سازمان بررسی کرد.

تغییر سیاست باید با نظارت بر گزارش‌ها و نرخ تحویل ایمیل همراه باشد.

مرحله ششم: مدیریت مستمر

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

همچنین تغییر ارائه‌دهنده ایمیل یا مهاجرت سرور باید در فرایند مدیریت تغییرات ثبت شود.

چگونه امنیت ایمیل دامنه را فراتر از DMARC افزایش دهیم؟

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

فعال‌سازی احراز هویت چندمرحله‌ای

MFA یا 2FA می‌تواند احتمال تصاحب حساب‌های ایمیل را کاهش دهد.

این موضوع اهمیت زیادی دارد، زیرا DMARC قادر نیست تمام پیام‌های ارسال‌شده از یک حساب واقعی اما تسخیرشده را شناسایی کند.

محدودسازی دسترسی حساب‌های ایمیل

حساب‌هایی که برای ارسال ایمیل سیستمی استفاده می‌شوند نباید دسترسی‌های غیرضروری داشته باشند.

در صورت پشتیبانی سرویس، بهتر است دسترسی‌ها بر اساس اصل حداقل امتیاز یا Least Privilege تعریف شوند.

استفاده از ارتباطات رمزنگاری‌شده

استفاده صحیح از TLS در انتقال ایمیل می‌تواند از محرمانگی ارتباط در مسیرهای پشتیبانی‌شده محافظت کند.

برای سیاست‌گذاری پیشرفته‌تر درباره امنیت ارتباط میان سرورهای ایمیل، فناوری‌هایی مانند MTA-STS و DANE نیز در برخی معماری‌ها قابل بررسی هستند.

این فناوری‌ها کاربرد متفاوتی با DMARC دارند.

آموزش کارکنان

کارکنان باید بدانند معتبر به نظر رسیدن آدرس فرستنده به‌تنهایی برای اعتماد به یک پیام کافی نیست.

درخواست‌های مالی، تغییر اطلاعات حساب و دریافت اطلاعات حساس بهتر است از طریق یک کانال مستقل تأیید شوند.

پایش دامنه‌های مشابه

سازمان‌ها می‌توانند دامنه‌های مشابه نام تجاری خود را شناسایی و از نظر سوءاستفاده احتمالی بررسی کنند.

این اقدام به‌خصوص برای کسب‌وکارهای مالی و فروشگاه‌های اینترنتی اهمیت دارد.

تهیه برنامه پاسخ‌گویی به رخداد

اگر گزارشی درباره جعل دامنه دریافت شد، باید فرایند مشخصی برای بررسی وجود داشته باشد.

این فرایند می‌تواند شامل تحلیل گزارش‌های DMARC، بررسی فعالیت حساب‌ها، ثبت شواهد و اطلاع‌رسانی به کاربران در صورت ضرورت باشد.

سؤالات متداول درباره DMARC

DMARC مخفف چیست؟

DMARC مخفف Domain-based Message Authentication, Reporting and Conformance است و برای احراز هویت مبتنی بر دامنه، تعیین سیاست برخورد با پیام‌های ناموفق و گزارش‌گیری استفاده می‌شود.

آیا DMARC جلوی جعل ایمیل را می‌گیرد؟

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

آیا برای استفاده از DMARC باید SPF و DKIM فعال باشند؟

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

آیا تنظیم DMARC رایگان است؟

انتشار رکورد DMARC در DNS معمولاً هزینه مستقلی ندارد، اما بعضی سرویس‌های تحلیل گزارش، داشبوردهای مدیریتی یا زیرساخت‌های تخصصی ممکن است پولی باشند.

بهترین سیاست DMARC کدام است؟

برای آغاز پیاده‌سازی، p=none گزینه مناسبی برای نظارت است. پس از اصلاح منابع قانونی، سیاست p=reject معمولاً محافظت اجرایی قوی‌تری در برابر جعل مستقیم دامنه درخواست می‌کند.

آیا DMARC باعث جلوگیری از اسپم شدن ایمیل می‌شود؟

DMARC به اعتبارسنجی دامنه کمک می‌کند، اما ورود پیام به Inbox را تضمین نمی‌کند. اعتبار IP، کیفیت محتوا، سابقه ارسال و سیاست سرویس مقصد نیز اهمیت دارند.

چگونه بفهمیم DMARC فعال است؟

می‌توان رکورد TXT مربوط به _dmarc دامنه را در DNS بررسی کرد. برای تأیید عملکرد واقعی نیز باید نتیجه احراز هویت ایمیل‌های ارسالی و گزارش‌های DMARC بررسی شود.

آیا برای وردپرس DMARC لازم است؟

برای سایت‌های وردپرسی که ایمیل‌های مهمی مانند بازیابی رمز عبور یا اعلان ثبت‌نام ارسال می‌کنند، استفاده از DMARC همراه با SPF و DKIM توصیه می‌شود.

آیا DMARC روی عملکرد سایت تأثیر دارد؟

DMARC مستقیماً برای احراز هویت ایمیل طراحی شده و معمولاً تأثیر مستقیمی بر سرعت بارگذاری صفحات وب ندارد. بااین‌حال، تنظیم نادرست آن می‌تواند بر تحویل ایمیل‌های سایت اثر بگذارد.

تفاوت DMARC و DKIM چیست؟

DKIM اعتبار امضای رمزنگاری‌شده پیام را بررسی می‌کند، درحالی‌که DMARC هم‌راستایی دامنه From با SPF یا DKIM را ارزیابی کرده و امکان انتشار سیاست و دریافت گزارش فراهم می‌کند.

آیا DMARC برای زیردامنه‌ها نیز کاربرد دارد؟

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

آیا DMARC می‌تواند ایمیل قانونی را مسدود کند؟

بله. اگر سیاست سخت‌گیرانه فعال باشد و ایمیل قانونی به دلیل تنظیمات اشتباه یا مشکلات انتقال غیرمستقیم DMARC را پشت سر نگذارد، ممکن است توسط دریافت‌کننده رد یا قرنطینه شود.

آیا وجود p=none برای امنیت ایمیل کافی است؟

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

آیا DMARC از حملات فیشینگ جلوگیری می‌کند؟

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

جمع‌بندی؛ چرا استفاده از DMARC برای امنیت دامنه ضروری است؟

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

یکی از مزایای اصلی DMARC، قابلیت تعیین سیاست برخورد با پیام‌های ناموفق است. مدیر دامنه می‌تواند ابتدا با سیاست None وضعیت ارسال را بررسی کند و پس از اصلاح تنظیمات، به سمت سیاست‌های سخت‌گیرانه‌تر مانند Quarantine و Reject حرکت کند.

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

بااین‌حال، امنیت ایمیل نباید تنها به DMARC محدود شود. استفاده از MFA، حفاظت از حساب‌های کاربری، پایش دامنه‌های مشابه، فیلترهای ضدبدافزار و آموزش کاربران همچنان ضروری است.

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

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