Defaults.Exposed › رفع اشکال‌ها › DMARC (Email Spoofing Protection)

چطور DMARC (Email Spoofing Protection) را رفع کنید

Q: آیا روشن کردن DMARC ممکن است به طور تصادفی از رسیدن ایمیلهای خودم جلوگیری کند؟

میتواند — اما فقط اگر راهاندازی ایمن را نادیده بگیرید. نقطهی کل شروع با 'فقط نظارت' (p=none) با گزارشدهی روشن این است که دو هفته تماشا کنید و تأیید کنید که هر فرستندهی مشروع قبل از روشن کردن بلاک به درستی تشخیص داده شده. به این ترتیب، ایمیل واقعی شما تحت تأثیر نیست.

Q: SPF و DKIM را راهاندازی کردهام. مگر کافی نیست؟

نه — و این مهمترین نکته است. SPF و DKIM قفلها هستند؛ DMARC دستورالعملی است که میگوید 'اگر قفلها مطابقت ندارند، ایمیل را رد کن.' بدون DMARC در 'reject'، یک سرور دریافتکننده ممکن است متوجه شود ایمیل جعلی است و همچنان آن را تحویل دهد.

Q: تفاوت بین 'none'، 'quarantine' و 'reject' چیست؟ کدام را نیاز دارم؟

'none' فقط تماشا و گزارش میدهد — هیچچیزی را متوقف نمیکند، پس از شما محافظت نمیکند. 'quarantine' جعلها را به پوشهی اسپم میفرستد. 'reject' از همان ابتدا آنها را رد میکند. 'reject' هدف است و تنها تنظیمی که نمرهی کامل میگیرد.

Q: این 'rua' گزارشدهی چیست، و آیا به آن نیاز دارم؟

برچسب rua از ارائهدهندگان ایمیل میخواهد یک خلاصهی روزانه از هر سیستمی که سعی کرده ایمیل به عنوان دامنهی شما ارسال کند برای شما بفرستد — از جمله مجرمان. این چیزی است که کسبوکارها اغلب ۵ تا ۵۰ فرستندهی غیرمجاز را در روز اول کشف میکنند.

DMARC تنها تنظیمی است که واقعاً به ارائه‌دهندگان ایمیل دنیا می‌گوید ایمیل‌هایی که نام کسب‌وکار شما را جعل می‌کنند را بلاک کنند. SPF و DKIM قفل‌ها را بررسی می‌کنند؛ DMARC تصمیم می‌گیرد وقتی یک جعل از بررسی شکست می‌خورد چه اتفاقی بیفتد — آن را دور بینداز، علامت‌گذاری کن، یا اجازه بده رد شود. اگر اشتباه تنظیم شود، دامنه‌ی شما کاملاً قابل جعل است؛ اگر درست تنظیم شود، جعل هویت در صندوق ورودی متوقف می‌شود.

نتیجه نهایی برای کسب‌وکار شما: بدون اجرای DMARC، یک مجرم می‌تواند ایمیلی ارسال کند که دقیقاً مثل ایمیل از کسب‌وکار شما به نظر می‌رسد — به مشتریان، کارکنان و تأمین‌کنندگان شما — و در صندوق ورودی آن‌ها می‌نشیند، نه اسپم. مردم به نام شما کلاهبرداری می‌شوند، و شما را مقصر می‌دانند.

هزینه این برای شما

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

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

DMARC چیست، به زبان ساده

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

سه تنظیم وجود دارد که با هم این را رفع می‌کنند:

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

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

این چقدر ممکن است برای شما هزینه داشته باشد

کلاهبرداری فاکتور جعلی. یک مجرم دقیقاً مثل یک فاکتور واقعی از تیم حسابداری شما به مشتری ایمیل می‌زند — همان نام، همان دامنه، طرح حرفه‌ای — اما با اطلاعات بانکی خودش. چون دامنه اجرایی نشده، در صندوق ورودی می‌نشیند نه اسپم. مشتری پرداخت می‌کند. هفته‌ها بعد وقتی پیگیر سفارشش می‌شود متوجه می‌شوید.
حواله‌ی CEO Fraud. یک ایمیل به نظر می‌رسد از شما، مالک، به مسئول مالی‌تان: «می‌توانی این پرداخت را فوری انجام دهی؟» کاملاً واقعی به نظر می‌رسد چون آدرس شماست — فقط جعل شده. پرداخت می‌رود.
قرارداد از دست رفته. یک مشتری جدی قبل از امضا یک بررسی امنیتی اجرا می‌کند. ابزارهایشان دامنه‌ی شما را «قابل جعل — بدون اجرای احراز هویت ایمیل» گزارش می‌کند. همین یک پرچم قرمز کافی است.
آسیب اعتباری که نمی‌توانید برطرف کنید. دامنه‌ی شما در یک کمپین فیشینگ جاروب می‌شود. ده‌ها نفر که به نام شما فریب خوردند هشدارها و نقدها پست می‌کنند.
ایمیل خودتان در اسپم می‌رود. Google و Yahoo اکنون فعالانه به دامنه‌هایی با DMARC بدون اجرا بی‌اعتماد هستند.

در واقع چیست (و «خوب» چه شکلی است)

DMARC به عنوان یک خط متن در تنظیمات دامنه‌ی شما زندگی می‌کند — یک رکورد DNS «TXT» منتشر شده در نام ویژه _dmarc.yourdomain.

۱. سیاست (p=) — دستورات نگهبان. این بخش با وزن زیاد:

p=none — فقط تماشا. نگهبان متوجه می‌شود اما هیچ‌کس را متوقف نمی‌کند. هیچ محافظتی ارائه نمی‌دهد.
p=quarantine — جعل‌ها را به اسپم بفرست. محافظت واقعی، اما نه کامل.
p=reject — جعل‌ها را از در برگردان. ایمیل جعلی هرگز تحویل داده نمی‌شود. این تنها تنظیمی است که شما را کاملاً محافظت می‌کند.

«خوب» چه شکلی است: p=reject. هر چیز کمتر یک شکاف باقی می‌گذارد.

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

سیاست زیردامنه (sp=). می‌توانید برای دامنه‌ی اصلی سیاست قوی داشته باشید اما زیردامنه‌ها را تصادفاً باز بگذارید. یک دامنه با p=reject اما sp=none به شدت نمره کم می‌گیرد — مهاجمان به سادگی یک زیردامنه را جعل می‌کنند.
درصد (pct=). در طول راه‌اندازی محتاطانه می‌توانید اجرا را فقط روی بخشی از ایمیل اعمال کنید. نمره با حرکت از ۲۵٪ به ۱۰۰٪ بالا می‌رود.

۲. آدرس گزارش‌دهی (rua=) — دوم بررسی این صفحه است. برچسب rua= از هر ارائه‌دهنده‌ی ایمیل در دنیا می‌خواهد یک خلاصه‌ی روزانه ارسال کند از کسانی که سعی کردند ایمیل به عنوان دامنه‌ی شما بفرستند.

چگونه آن را رفع کنیم (رایگان، ~۳۰ دقیقه پخش شده در دو هفته)

این بخش را به هر کسی که دامنه، وب‌سایت یا IT شما را مدیریت می‌کند بدهید — اصلاح کاملاً رایگان است.

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

مرحله ۱ — مطمئن شوید SPF و DKIM ابتدا در جا هستند. DMARC به آن‌ها تکیه دارد.

مرحله ۲ — یک رکورد نظارت با گزارش‌دهی روشن منتشر کنید. یک رکورد DNS TXT اضافه کنید:

Host / name: _dmarc.yourdomain
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain; adkim=s; aspf=s

مرحله ۳ — گزارش‌ها را ~۲ هفته بخوانید. از یک سرویس گزارش‌دهی رایگان (مثلاً dmarcian یا Postmark) استفاده کنید تا گزارش‌ها را به یک داشبورد خوانا تبدیل کند.

مرحله ۴ — به quarantine بروید. وقتی ایمیل واقعی شما تمیز است، p=none را به p=quarantine تغییر دهید.

مرحله ۵ — به reject بروید. p=quarantine را به p=reject تغییر دهید. حالا کاملاً محافظت هستید:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain; adkim=s; aspf=s

مرحله ۶ — زیردامنه‌ها را فراموش نکنید. مطمئن شوید sp=none باقی نگذاشته‌اید.

نکات پلتفرم:

Google Workspace / Microsoft 365: هر دو کاملاً DMARC را پشتیبانی می‌کنند. رکورد DMARC خودش در ارائه‌دهنده‌ی DNS شما می‌رود، نه در کنسول ادمین Google یا Microsoft.
Cloudflare: DNS > Records > Add record > TXT، نام _dmarc، مقدار را جای‌گذاری کنید.

اشتباهات رایج

توقف در p=none. رایج‌ترین خطا. نظارت شروع است نه پایان — یک دامنه گیر کرده در none همچنان کاملاً قابل جعل است.
پریدن مستقیم به reject بدون نظارت. بدون مرحله‌ی گزارش‌دهی ممکن است یک فرستنده‌ی مشروع تأیید نشده را متوجه نشوید.
فراموش کردن سیاست زیردامنه. یک p=reject قوی با sp=none یک در جانبی باز می‌گذارد.
آدرس گزارش‌دهی شکسته. یک rua= با اشتباه تایپی به معنی رفتن گزارش‌ها به هیچ‌جاست.
«ایمیل نمی‌فرستیم پس رد می‌کنیم.» یک دامنه‌ی بدون ارسال بهترین هدف است چون کسی آن را تماشا نمی‌کند.

نکته‌ای درباره‌ی نمره‌دهی

بررسی سیاست (p=) یکی از سنگین‌ترین‌ موارد در کل ارزیابی است — چون مهم‌ترین عامل در اینکه آیا کسب‌وکار شما می‌تواند جعل هویت شود یا نه. reject نمره‌ی کامل می‌گیرد؛ quarantine تقریباً نیمی؛ none و رکورد گمشده به عنوان شکست نمره می‌گیرند.

آن را در هاست خود راه‌اندازی کنید

گام‌به‌گام برای ارائه‌دهندگان محبوب:

پرسش‌های متداول

من اصلاً تکنیکی نیستم — آیا واقعاً می‌توانم این را حل کنم؟

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

آیا روشن کردن DMARC ممکن است به طور تصادفی از رسیدن ایمیل‌های خودم جلوگیری کند؟

می‌تواند — اما فقط اگر راه‌اندازی ایمن را نادیده بگیرید. نقطه‌ی کل شروع با 'فقط نظارت' (p=none) با گزارش‌دهی روشن این است که دو هفته تماشا کنید و تأیید کنید که هر فرستنده‌ی مشروع قبل از روشن کردن بلاک به درستی تشخیص داده شده. به این ترتیب، ایمیل واقعی شما تحت تأثیر نیست.

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

نه — و این مهم‌ترین نکته است. SPF و DKIM قفل‌ها هستند؛ DMARC دستورالعملی است که می‌گوید 'اگر قفل‌ها مطابقت ندارند، ایمیل را رد کن.' بدون DMARC در 'reject'، یک سرور دریافت‌کننده ممکن است متوجه شود ایمیل جعلی است و همچنان آن را تحویل دهد.

تفاوت بین 'none'، 'quarantine' و 'reject' چیست؟ کدام را نیاز دارم؟

'none' فقط تماشا و گزارش می‌دهد — هیچ‌چیزی را متوقف نمی‌کند، پس از شما محافظت نمی‌کند. 'quarantine' جعل‌ها را به پوشه‌ی اسپم می‌فرستد. 'reject' از همان ابتدا آن‌ها را رد می‌کند. 'reject' هدف است و تنها تنظیمی که نمره‌ی کامل می‌گیرد.

این 'rua' گزارش‌دهی چیست، و آیا به آن نیاز دارم؟

برچسب rua از ارائه‌دهندگان ایمیل می‌خواهد یک خلاصه‌ی روزانه از هر سیستمی که سعی کرده ایمیل به عنوان دامنه‌ی شما ارسال کند برای شما بفرستد — از جمله مجرمان. این چیزی است که کسب‌وکارها اغلب ۵ تا ۵۰ فرستنده‌ی غیرمجاز را در روز اول کشف می‌کنند.

ما کم ایمیل می‌فرستیم، یا اصلاً از این دامنه ارسال نداریم. آیا همچنان به DMARC نیاز داریم؟

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