ابتدا بفهمید چه کسانی با این دامنه ایمیل می‌فرستند
یک شرکت فرضی را در نظر بگیرید که کارکنان مالی آن پیامی دریافت می‌کنند که یکی از مشتریان فرستاده است: کسی با نشانی‌ای روی دامنه شرکت، «تغییر حساب دریافت وجه» را اعلام کرده است. مدیر سیستم پس از ورود به DNS می‌بیند که سال‌ها پیش یک رکورد SPF تنظیم شده اما DMARC وجود ندارد، و هیچ‌کس نمی‌داند پلتفرم بازاریابی، سامانه تیکت، سامانه استخدام و شرکت‌های تابعه خارجی هر کدام چگونه ایمیل می‌فرستند. ساده‌ترین خطا در این لحظه این است که بی‌درنگ سیاست رد کردن منتشر شود. روز بعد فاکتورها و اعلان‌های تیکت به تعداد زیاد به پوشه هرزنامه مشتریان می‌روند، واحدهای کسب‌وکار خواستار برگرداندن فوری می‌شوند و کار متوقف می‌شود. گام نخست واقعی تغییر سیاست نیست، بلکه پیدا کردن همه سامانه‌هایی است که با این دامنه ایمیل بیرونی می‌فرستند.
RFC 9989 که در مه ۲۰۲۶ منتشر شد، مشخصه اصلی کنونی DMARC است. این سند جایگزین RFC 7489 از سال ۲۰۱۵ شده و نسخه رکورد همچنان v=DMARC1 نوشته می‌شود. DMARC به صاحب دامنه امکان می‌دهد اعلام کند که گیرندگان می‌توانند با ایمیلی که در بررسی هم‌ترازی SPF یا DKIM رد می‌شود هیچ اقدامی نکنند، آن را قرنطینه کنند یا رد کنند، و گزارش‌های تجمیعی را برای صاحب دامنه بفرستند. راهنمای NIST درباره ایمیل قابل‌اعتماد نیز استقرار SPF، DKIM و DMARC را توصیه می‌کند. بر پایه این سازوکارها، JOTOglobal پیشنهاد می‌کند مدیر ایمیل همراه با واحدهای خرید، بازاریابی، منابع انسانی و فناوری اطلاعات مناطق، فهرستی از منابع ارسال تهیه کند و نام سامانه، صاحب کسب‌وکار، دامنه یا زیردامنه ارسال، این‌که آیا شخص ثالثی از طرف شرکت ارسال می‌کند و این‌که امضای DKIM فعال است یا نه را ثبت کند. منابعی که هیچ‌کس مسئولیت آن‌ها را نمی‌پذیرد جداگانه علامت‌گذاری می‌شوند تا با گزارش‌ها راستی‌آزمایی شوند.
با حالت پایش، گزارش‌های تجمیعی را بخوانید
پس از آماده‌شدن نسخه نخست فهرست، مدیر یک رکورد DMARC با سیاست none منتشر می‌کند و یک صندوق اختصاصی یا پلتفرم پردازش گزارش را برای دریافت گزارش‌های تجمیعی تعیین می‌کند. این مرحله نتیجه تحویل ایمیل را تغییر نمی‌دهد و هدفش مشاهده چیزی است که گیرندگان واقعاً می‌بینند. RFC 9990 قالب گزارش تجمیعی را تعریف می‌کند که تعداد پیام‌ها را بر اساس IP فرستنده همراه با نتیجه بررسی و هم‌ترازی SPF و DKIM خلاصه می‌کند. مدیر هر هفته منابع گزارش را مورد به مورد با فهرست مقایسه می‌کند. منابعی که در هر دو وجود دارند و هم‌تراز هستند «قبول» علامت می‌خورند. منابعی که در گزارش هستند اما در فهرست نیستند به تیم امنیت سپرده می‌شوند تا تشخیص دهد سامانه کسب‌وکاری فراموش‌شده‌اند یا جاعل. منابعی که در فهرست هستند اما هرگز هم‌تراز نمی‌شوند برای اصلاح به صاحب کسب‌وکار مربوط ارجاع می‌شوند. گزارش‌ها ممکن است اطلاعاتی درباره گیرندگان و مسیرهای بازارسال داشته باشند، بنابراین دسترسی به صندوق دریافت باید به تیم‌های ایمیل و امنیت محدود شود و مدت نگهداری آن توافق شود.
اصلاح‌ها معمولاً در سه دسته مشکل جای می‌گیرند. دسته نخست، پلتفرم شخص ثالثی است که DKIM را با دامنه خودش امضا می‌کند؛ باید پلتفرم را طوری تنظیم کرد که با دامنه شرکت یا یک زیردامنه اختصاصی امضا کند. دسته دوم، رکورد SPF است که پیوسته include بیشتری به آن افزوده می‌شود تا تعداد جست‌وجوها به حد پروتکل نزدیک شود؛ باید سرویس‌های ازکارافتاده حذف شوند و در صورت نیاز ارسال‌های پرحجم مانند بازاریابی به زیردامنه جداگانه منتقل شوند. دسته سوم این است که بازارسال و فهرست‌های پستی مسیر پیام را تغییر می‌دهند و ممکن است SPF را ناموفق کنند؛ در این حالت سالم ماندن امضای DKIM اهمیت بیشتری پیدا می‌کند. هر اصلاح با تاریخ تکمیل و روش راستی‌آزمایی در فهرست ثبت می‌شود؛ برای نمونه صاحب کسب‌وکار یک ایمیل آزمایشی می‌فرستد و هم‌ترازی آن در گزارش یا در سرآیند نتیجه احراز هویت گیرنده تأیید می‌شود.
سیاست را مرحله‌به‌مرحله سخت‌تر کنید و بازگشت را برنامه‌ریزی کنید
تنها زمانی که همه منابع شناخته‌شده در گزارش‌ها به‌طور پایدار هم‌تراز باشند و چند دوره گزارش پیاپی هیچ منبع قانونی تازه‌ای نشان ندهد، سیاست از none به quarantine تغییر می‌کند. RFC 9989 دیگر pct را بخشی از سازوکار کنونی نمی‌داند، بنابراین شرکت نباید برای گذار به اعمال سیاست بر بخشی از پیام‌ها تکیه کند. رویکرد پایدارتر این است که ابتدا روی زیردامنه‌ای با اثر کمتر اعمال شود یا نخست زیردامنه جداگانه بازاریابی سخت‌گیرانه شود و سپس دامنه اصلی. پیش از هر تغییر، مدیر ایمیل می‌نویسد چه چیزی تغییر می‌کند، دوره مشاهده چقدر است، چه کسی شکایت‌های کسب‌وکاری را دریافت می‌کند و در صورت طبقه‌بندی نادرست گسترده، تحت چه شرایطی و توسط چه کسی به مرحله قبل بازگردانده می‌شود.
در مرحله قرنطینه، صاحبان کسب‌وکار بررسی می‌کنند که آیا ایمیل‌های حیاتی مانند فاکتور، قرارداد، بازنشانی گذرواژه و اطلاعیه مشتری همچنان به صندوق ورودی می‌رسند، و تیم پشتیبانی موارد غیرعادی گزارش‌شده از سوی مشتریان را ثبت می‌کند. تنها پس از اطمینان از این‌که هیچ ایمیل قانونی تحت تأثیر قرار نگرفته، تیم بررسی می‌کند که آیا به reject برود یا نه. برای زیردامنه‌هایی که هرگز ایمیل نمی‌فرستند، RFC 9989 برچسب np را برای زیردامنه‌های ناموجود فراهم کرده است و شرکت می‌تواند برای آن‌ها سیاست سخت‌گیرانه‌تری اعلام کند تا فضای سوءاستفاده کمتر شود. سوابق تغییر DNS، خلاصه گزارش‌ها و تأییدهای کسب‌وکاری هر مرحله باید در برگه تغییر نگهداری شود تا اگر بعدها کسی پرسید چرا پیامی رد شده، مبنای آن زمان قابل پیگیری باشد.
شواهد پذیرش، خطاهای رایج و محدوده کاربرد
برای پذیرش، چهار نوع شاهد را نگه دارید: نتیجه جست‌وجوی رکوردهای منتشرشده کنونی SPF، انتخابگرهای DKIM و DMARC؛ خلاصه آخرین دوره گزارش تجمیعی که نشان دهد همه منابع قانونی هم‌تراز هستند؛ ایمیل‌های آزمایشی سامانه‌های کلیدی کسب‌وکار همراه با سرآیند نتیجه احراز هویت؛ و امضای هر صاحب کسب‌وکار برای سامانه‌های خود در فهرست. خطاهای رایج عبارت‌اند از این باور که انتشار DMARC همه فیشینگ‌ها را متوقف می‌کند، در حالی که فقط به استفاده مستقیم از دامنه خود شرکت می‌پردازد و بر دامنه‌های مشابه یا جعل از طریق حساب‌های بیرونی اثر مستقیمی ندارد؛ و این باور که پس از تنظیم reject دیگر نیازی به خواندن گزارش نیست، در حالی که سامانه‌های تازه یا تغییر تأمین‌کننده می‌توانند منابع ناهم‌تراز جدیدی ایجاد کنند. به همین دلیل فهرست منابع ارسال باید جزو موارد بررسی هنگام راه‌اندازی سامانه تازه و تغییر تأمین‌کننده باشد و واحد خرید یا مسئول پروژه پیش از بهره‌برداری به مدیر ایمیل اطلاع دهد.
فرایند فهرست‌برداری، سخت‌گیری مرحله‌ای و پذیرش که در اینجا شرح داده شد، توصیه سازمانی JOTOglobal است. طول هر مرحله، شاخص‌های مورد پایش و این‌که در نهایت به رد کردن برسیم یا نه، باید توسط هر شرکت بر اساس حجم ایمیل و ریسک کسب‌وکاری خود تعیین شود. گیرندگان مختلف ممکن است سیاست DMARC را به شکل متفاوتی اعمال کنند و گزارش‌های تجمیعی ممکن است با تأخیر برسند یا ناقص باشند، بنابراین گزارش‌ها تنها یکی از مبانی تصمیم‌گیری هستند. اگر ایمیل سازمانی توسط ارائه‌دهنده برون‌سپاری اداره می‌شود، قرارداد یا برگه درخواست باید مشخص کند چه کسی مجاز به تغییر DNS است و مسئولیت بازگشت با کیست، و صنایعی که ارتباطات آن‌ها تحت نظارت است باید الزامات نگهداری و اطلاع‌رسانی خود را نیز رعایت کنند.