یک پاسخگوی خودکار ایمیل، ایمیلهای از پیش نوشته شده را به طور خودکار بر اساس یک محرک، شرایط و قانون زمانبندی ارسال میکند. مجموعههای خوشامدگویی به طور مداوم بالاترین نرخ باز شدن و... را ارائه میدهند.
نکات کلیدی
- قبل از اینکه DMARC به درستی کار کند، هم SPF و هم DKIM باید پیکربندی و با دامنه ارسال شما همسو شوند. انتشار DMARC از طریق احراز هویت خراب باعث میشود ایمیلهای معتبر فوراً علامتگذاری شوند.
- هنگام تنظیم DMARC در آفیس ۳۶۵، برای جمعآوری گزارشها با p=none شروع کنید، پس از پایدار شدن همترازی به p=quarantine بروید، سپس برای اجرای کامل به p=reject بروید.
- مایکروسافت ۳۶۵ به طور خودکار DMARC را برای دامنههای سفارشی پیکربندی نمیکند. این رکورد باید به صورت دستی در DNS دامنه شما منتشر شود.
از فوریه ۲۰۲۴، الزامات ارسال انبوه جیمیل، یک رکورد DMARC منتشر شده را برای هر دامنهای که از طریق آن ارسال انجام میشود، الزامی کرده است. ایمیل های 5,000 در روز برای کاربران جیمیل. یاهو همین قانون را تحت قوانین خود اعمال میکند بهترین شیوههای فرستنده. همانطور که از می 2025مایکروسافت شروع به رد کردن ایمیلهای ناسازگار از فرستندگان با حجم بالا به صندوقهای پستی Outlook، Hotmail و Live کرده است.
DMARC برای هر مستاجر مایکروسافت ۳۶۵ که در مقیاس بزرگ و فعلی فعالیت میکند، از اختیاری به الزامی تبدیل شده است. آمار هرزنامههای ایمیلی دلیلش را روشن کنید: ارائهدهندگان خدمات، قوانین احراز هویت را سختتر میکنند، زیرا ایمیلهای احراز هویت نشده، هم برای فرستندگان و هم برای گیرندگان خطر ایجاد میکنند.
به همین دلیل یادگیری نحوهی صحیح راهاندازی DMARC در آفیس ۳۶۵، از تأیید پیشنیازها و ایجاد رکورد گرفته تا انتشار آن در DNS، انتخاب یک سیاست شروع ایمن، تأیید عملکرد آن و حرکت به سمت اجرای کامل بدون مسدود کردن ایمیلهای قانونی، بسیار مهم است.
پیشنیازهای لازم قبل از راهاندازی DMARC در آفیس ۳۶۵
DMARC یک پروتکل مستقل نیست. این یک لایه سیاستگذاری روی ... است. SPF و DKIM که به سرورهای دریافتکننده ایمیل میگوید وقتی این بررسیها با شکست مواجه میشوند، چه کاری انجام دهند. اگر SPF یا DKIM به درستی پیکربندی نشده باشند یا همتراز نباشند، اجرای DMARC به محض عبور از p=none، بر اساس آن ناهمترازی شروع به اقدام خواهد کرد.
قبل از انتشار رکورد DMARC خود، هر چهار پیشنیاز زیر را تأیید کنید:
- رکورد SPF منتشر و ارسال شد: برای کاربران مایکروسافت ۳۶۵، رکورد SPF باید شامل موارد زیر باشد:spf.protection.outlook.com به علاوه هرگونه فرستنده شخص ثالث اضافی (SendGrid، Mailchimp، HubSpot و غیره) که از طرف دامنه شما ارسال میکنند.
- امضای DKIM برای هر دامنه سفارشی فعال شده است: مایکروسافت ۳۶۵ به طور خودکار DKIM را برای دامنههای سفارشی فعال نمیکند. پورتال مایکروسافت دیفندر را باز کنید، به صفحه DKIM در قسمت ایمیل و همکاری → سیاستها و قوانین → سیاستهای تهدید بروید و تأیید کنید که امضا برای دامنه سفارشی فعال شده است.
- دسترسی مدیر کل یا مدیر امنیت برای هرگونه مراحل تأیید در پورتال Defender، به مستأجر مایکروسافت ۳۶۵ مراجعه کنید.
- دسترسی DNS برای دامنه سفارشی برای انتشار رکورد DMARC TXT در _dmarc.yourdomain.com در پنل کنترل میزبان DNS خود.
نحوه تنظیم DMARC در آفیس ۳۶۵: گام به گام
پنج مرحله زیر ۱۰ تا ۱۵ دقیقه کار فعال به علاوه زمان انتشار DNS (از چند دقیقه تا ۴۸ ساعت، بسته به ارائه دهنده DNS و تنظیمات TTL شما) طول میکشد.
راهاندازی DMARC کاملاً در DNS اتفاق میافتد، نه در پورتال Microsoft Defender. مایکروسافت ۳۶۵ بررسیهای DMARC ورودی را به طور خودکار از طریق Exchange Online Protection انجام میدهد، اما هیچ تنظیمی در پورتال Defender برای پیکربندی DMARC خروجی در دامنه سفارشی شما وجود ندارد. این رکورد در منطقه DNS شما قرار دارد.
مرحله ۱: تأیید کنید که SPF و DKIM کار میکنند
یک ایمیل آزمایشی از دامنه سفارشی خود به یک آدرس جیمیل یا یاهو خارجی ارسال کنید. ایمیل را باز کنید و سربرگهای کامل پیام را مشاهده کنید (در جیمیل: منوی سه نقطه → «نمایش متن اصلی»).
در سربرگ Authentication-Results، موارد زیر را تأیید کنید:
- spf=pass — SPF مجاز و قابل قبول است
- dkim=pass — DKIM به درستی امضا شده و امضا تأیید شده است
اگر هر کدام از این دو حالت fail یا neutral را نشان داد، همینجا متوقف شوید و ابتدا مشکل احراز هویت را برطرف کنید. انتشار یک رکورد DMARC روی SPF یا DKIM ناموفق باعث میشود ایمیلهای قانونی به محض اینکه پالیسی را از p=none عبور دهید، قرنطینه یا رد شوند.
مرحله ۲: در مورد سیاست اولیه DMARC تصمیم بگیرید
برای هر استقرار جدید DMARC با p=none شروع کنید. این خطمشی، گزارشهای کلی DMARC را بدون تأثیر بر تحویل ایمیل جمعآوری میکند. پیامهای ناموفق همچنان تحویل داده میشوند، اما سرورهای ایمیل دریافتی، نتایج احراز هویت را به آدرس مشخص شده در برچسب rua= شما گزارش میدهند. این دادهها به شما میگویند که کدام منابع ارسال قبل از شروع اجرا، همسو هستند و کدامها نیستند.
پرش مستقیم به حالتهای p=quarantine یا p=reject، شایعترین علت از دست رفتن ایمیلهای قانونی در طول انتشار DMARC است. اگر هنوز پلتفرم ارسال شخص ثالثی با این قابلیت هماهنگ نشده باشد، یک سیاست سختگیرانه، ایمیلهای واقعی از آن منبع را فوراً قرنطینه یا برگشت میدهد. مرحله p=none به طور خاص برای جلوگیری از این امر وجود دارد.
مرحله 3: ساخت رکورد DMARC
رکورد پایه DMARC برای یک استقرار جدید به این شکل است:
v=DMARC1; p=هیچکدام rua=mailto:[ایمیل محافظت شده]درصد = ۱۰۰؛
در اینجا معنی هر تگ را مشاهده میکنید:
- v=DMARC1 — نسخه پروتکل. به عنوان اولین برچسب در هر رکورد DMARC الزامی است.
- p=هیچکدام — سیاستی که برای پیامهایی که در تنظیم DMARC شکست میخورند اعمال میشود. با هیچ شروع کنید، سپس با تثبیت تنظیم، به قرنطینه و رد کردن ادامه دهید.
- rua=آدرس پستی: — صندوق پستی که گزارشهای کلی به آن ارسال میشوند. از یک صندوق پستی اختصاصی مانند [ایمیل محافظت شده]یا اگر نمای داشبورد را ترجیح میدهید، گزارشها را به یک تحلیلگر DMARC شخص ثالث هدایت کنید.
- درصد=100 — درصد پیامهای ناموفقی که این سیاست روی آنها اعمال میشود. این مقدار را از ابتدا روی ۱۰۰ تنظیم کنید. راهاندازی تدریجی درصد در پیادهسازیهای مدرن DMARC به ندرت ضروری است و پیچیدگی غیرضروری ایجاد میکند.
برای مرجع کامل تگها، شامل تگهای اختیاری مانند ruf (گزارشهای پزشکی قانونی)، sp (سیاست زیردامنه)، adkim و aspf، به [لینک] مراجعه کنید. DMARC.orgمستندات رسمی پروتکل.
مرحله ۴: انتشار رکورد DMARC در DNS
به ارائه دهنده DNS دامنه خود وارد شوید. یک رکورد TXT جدید با مقادیر زیر ایجاد کنید:
- میزبان / نام: _dmarc (بعضی از ارائه دهندگان درخواست _dmarc.yourdomain.com را دارند؛ دقیقاً همان چیزی را که رابط کاربری DNS نیاز دارد وارد کنید)
- ارزش/محتوا: رکورد کامل DMARC ساخته شده در مرحله ۳، دقیقاً همانطور که نوشته شده است
- TTL: ۳۶۰۰ (یک ساعت) استاندارد است؛ مقادیر پایینتر در طول آزمایش سریعتر منتشر میشوند
رکورد را ذخیره کنید. انتشار DNS معمولاً ظرف چند ساعت تکمیل میشود، اما میتواند تا ۴۸ ساعت نیز طول بکشد. در طول این مدت، ممکن است رکورد به طور مداوم از همه سرویسدهندهها قابل مشاهده نباشد.
مرحله ۵: تأیید کنید که رکورد DMARC فعال است
پس از انتشار رکورد، آن را از دو طریق تأیید کنید:
- جستجوی DNS: به ابزار جستجوی DMARC در MXToolbox بروید، دامنه خود را وارد کنید و تأیید کنید که رکورد به درستی تجزیه و معتبر است. اگر جستجو ناموفق بود یا خطایی را نشان داد، قالببندی رکورد DNS خود را بررسی کنید، زیرا معمولاً علت آن یک نقطه ویرگول از دست رفته یا نام میزبان نادرست است.
- بررسی هدر احراز هویت: یک ایمیل آزمایشی دیگر از دامنه سفارشی خود به Gmail، Yahoo یا یک آدرس Outlook خارجی ارسال کنید. سربرگهای کامل را باز کنید و تأیید کنید که بخش Authentication-Results اکنون dmarc=pass را برای دامنه فرستنده نشان میدهد.
گزارشهای تجمیعی DMARC ظرف ۲۴ تا ۷۲ ساعت پس از شروع به کار رکورد، به صندوق پستی rua= میرسند. قبل از هرگونه اقدام به سمت یک سیاست سختگیرانهتر، دسته اول را با دقت بررسی کنید.
آشنایی با گزینههای سیاست DMARC: هیچکدام، قرنطینه و رد
هر استقرار موفق DMARC طی هفتهها یا ماهها از هر سه مرحله سیاستگذاری عبور میکند. نادیده گرفتن این مراحل، خطر رد کردن ایمیلهای قانونی را قبل از اینکه همه منابع ارسال به درستی هماهنگ شوند، به همراه دارد. رویکرد مرحلهای، روشی است که شما با آن از جریان ایمیل محافظت میکنید و در عین حال به سمت اجرای کامل آن پیش میروید.
حالت نظارت: p=none
v=DMARC1; p=هیچکدام rua=mailto:[ایمیل محافظت شده]درصد = ۱۰۰؛
با p=none، سرورهای ایمیل گیرنده نتایج DMARC را جمعآوری کرده و به آدرس rua= شما ارسال میکنند، اما پیامهای ناموفق همچنان به طور عادی ارسال میشوند. هیچ چیز قرنطینه یا رد نمیشود.
حداقل ۲ تا ۴ هفته در حالت p=none بمانید. از این زمان برای خواندن گزارشهای کلی و تأیید اینکه هر منبع ارسال قانونی، مانند مایکروسافت ۳۶۵، پلتفرمهای بازاریابی، فرستندگان تراکنش و CRMها، از ترازبندی DMARC عبور میکند، استفاده کنید. هر منبعی که نشان دهندهی خرابی باشد، باید قبل از تشدید سیاست، اصلاح شود.
فقط زمانی به حالت p=قرنطینه بروید که گزارشها به طور مداوم نرخ عبور بالای ۹۵٪ را برای همه فرستندگان قانونی در چندین چرخه گزارشدهی نشان دهند.
اجرای نرم: p=قرنطینه
v=DMARC1; p=قرنطینه; rua=mailto:[ایمیل محافظت شده]درصد = ۱۰۰؛
با p=quarantine، سرورهای دریافت ایمیل، پیامهای ناموفق را به پوشه هرزنامه یا هرزنامه (spam) هدایت میکنند، نه به صندوق ورودی (inbox). ایمیلهای قانونی اما بدون آدرس مشخص همچنان میرسند، فقط در مکانی که احتمال کمتری دارد گیرندگان آنها را ببینند.
این مرحله از سیاستگذاری، یک نقطه بررسی میانی مفید است. این مرحله، عواقبی را برای نامههای ناهماهنگ بدون بازگشتهای سختی که p=reject ایجاد میکند، اعمال میکند. 2 تا 4 هفته دیگر اینجا بمانید و گزارشها را از نزدیک برای هرگونه نامه قانونی که مسیرش اشتباه است، زیر نظر داشته باشید.
فقط زمانی به حالت p=reject بروید که گزارشهای DMARC، هماهنگی مداوم در تمام منابع را تأیید کنند و هیچ ایمیل معتبری قرنطینه نشود.
اجرای کامل: p=رد
v=DMARC1; p=رد rua=mailto:[ایمیل محافظت شده]درصد = ۱۰۰؛
با p=reject، سرورهای ایمیل گیرنده، پیامهایی را که در ترازبندی DMARC شکست میخورند، رد میکنند. پیامهای شکستخورده به فرستنده برمیگردند؛ آنها اصلاً به گیرنده نمیرسند.
این هدف هر پیادهسازی DMARC است. اجرای کامل p=reject، محافظت کاملی در برابر جعل دامنه ارائه میدهد و الزامات Gmail، Yahoo و Microsoft را برای فرستندگان با حجم بالا برآورده میکند. همچنین از شما محافظت میکند. اعتبار دامنه و IP با جلوگیری از ارسال ایمیل توسط فرستندگان غیرمجاز از نام دامنه شما.
به نظارت بر گزارشهای DMARC در p=reject ادامه دهید. منابع ارسال جدید، از جمله فروشندگان جدید، ابزارهای بازاریابی و یکپارچهسازیها، هنوز هم میتوانند باعث خرابی در ترازبندی شوند و قبل از راهاندازی باید با احراز هویت فعال شوند.
خطاهای رایج راهاندازی DMARC در آفیس ۳۶۵ و نحوه رفع آنها
بیشتر خطاهای DMARC در محیطهای مایکروسافت ۳۶۵، مشکلات مربوط به همترازی هستند، نه خطاهای پروتکل. این بدان معناست که رکورد از نظر فنی معتبر است، اما ایمیل ارسالی با دامنه امضای DKIM یا IP های مجاز SPF همترازی ندارد.
گزارشهای DMARC خالی هستند
تشخیص دادن: آدرس صندوق پستی rua= اشتباه است، صندوق پستی گزارشهای دریافتی را مسدود میکند، یا دامنه حجم کافی ارسال نمیکند تا ارائهدهندگان اصلی هنوز گزارشها را تولید نکرده باشند.
ثابت: تأیید کنید که صندوق پستی rua= وجود دارد، ایمیلهای خارجی را میپذیرد و توسط یک قانون اسپم تهاجمی فیلتر نشده است. چند ایمیل آزمایشی از دامنه به آدرسهای Gmail و Yahoo ارسال کنید؛ اگر DMARC به درستی پیکربندی شده باشد، این ارائه دهندگان معمولاً ظرف ۲۴ تا ۴۸ ساعت گزارشهایی را ارائه میدهند.
ایمیل قانونی قرنطینه یا رد میشود
تشخیص دادن: یک پلتفرم ارسال شخص ثالث هماهنگ نیست. شایعترین علت، یک ابزار بازاریابی، CRM یا ارائهدهنده ایمیل تراکنشی است که به SPF اضافه نشده یا برای امضا با DKIM برای دامنه سفارشی پیکربندی نشده است.
ثابت: گزارشهای تجمیعی DMARC را بررسی کنید تا مشخص شود کدام منبع دچار مشکل شده است. یا منبع را به رکورد SPF خود اضافه کنید (include:thirdparty.com)، امضای DKIM را برای آن منبع از طریق تنظیمات پلتفرم آن پیکربندی کنید، یا موقتاً به p=none برگردید تا زمانی که ترازبندی اصلاح شود. هرگز در حالی که منابع شناخته شده دچار مشکل هستند، سیاست را در حالت p=reject رها نکنید.
خطاهای همترازی DMARC پس از ارسال
تشخیص دادن: ایمیلهای فوروارد شده اغلب ترازبندی SPF را از دست میدهند زیرا IP سرور فوروارد کننده در رکورد SPF فرستنده اصلی نیست. DKIM معمولاً در فوروارد کردن سالم میماند، بنابراین این سناریو اغلب به یک مورد ترازبندی فقط DKIM تبدیل میشود.
ثابت: مطمئن شوید که DKIM برای فرستنده اصلی به درستی امضا شده است. ایمیلهای منطبق با DKIM حتی در صورت عدم موفقیت SPF به دلیل ارسال، از DMARC عبور میکنند. اگر DKIM پس از ارسال نیز از کار بیفتد، سیستم ارسال در حال تغییر محتوای پیام و شکستن امضای DKIM است. این وضعیت معمولاً برای حل شدن نیاز به پشتیبانی ARC (زنجیره دریافت شده با احراز هویت) از سرور ارسال دارد.
خطاهای فرمت رکورد DMARC
تشخیص دادن: اشتباهات تایپی در رکورد DMARC TXT میتواند کل خطمشی را نامعتبر کند. مشکلات رایج شامل فقدان پیشوند v=DMARC1، فقدان نقطهویرگول بین برچسبها یا تقسیم نادرست رکورد بین چندین ورودی DNS است.
ثابت: رکورد منتشر شده را از طریق اعتبارسنج DMARC در MXToolbox اجرا کنید و تأیید کنید که خروجی آن تجزیه شده و معتبر است. بررسی کنید که رکورد به عنوان یک ورودی TXT واحد تحت _dmarc.yourdomain.com وجود دارد، به دو رکورد تقسیم نشده است و هر برچسب با یک نقطه ویرگول از هم جدا شده است.
DMARC به درستی از دامنه شما محافظت میکند
راهاندازی DMARC زمانی آسانتر میشود که مراحل را به ترتیب دنبال کنید. SPF و DKIM را تأیید کنید، رکورد را بسازید، آن را در DNS منتشر کنید، به آرامی از هر مرحله از سیاستها عبور کنید، و زمان کافی برای خواندن گزارشها و رفع مشکلات همترازی قبل از تشدید اجرا داشته باشید.
از آنجایی که DMARC لایه نهایی احراز هویت ایمیل است، ابتدا به عملکرد صحیح SPF و DKIM بستگی دارد. اگر این رکوردها به درستی پیکربندی نشده باشند یا همتراز نباشند، اجرای DMARC ممکن است به جای محافظت از دامنه در برابر جعل، ایمیلهای قانونی را مسدود کند.
با این حال، احراز هویت همه مشکلات مربوط به قابلیت تحویل را حل نمیکند. یک دامنه احراز هویت شده که به لیستی پر از آدرسهای نامعتبر، یکبار مصرف یا غیرفعال ارسال میکند، همچنان بازگشتهای سختی ایجاد میکند و این بازگشتها بر روی ایمیل شما تأثیر میگذارند. شهرت فرستنده ایمیل صرف نظر از اینکه رکورد DMARC شما چقدر پاک است.
قبل از کمپین بعدی خود، لیست خود را در DeBounce آپلود کنید و یک اعتبارسنجی کامل از آن انجام دهید. اعتبار سنجی لیست ایمیلاحراز هویت تأیید میکند که ایمیل از طرف شما آمده است، در حالی که سلامت فهرست تأیید میکند که ایمیل به آدرس واقعی ارسال میشود. هر دو برای افزایش شانس رسیدن ایمیل به صندوق ورودی هر کمپین ضروری هستند.