هم‌ترازی DMARC احراز هویت موفق ایمیل را به دامنه‌ای پیوند می‌دهد که مشتری در نشانی From می‌بیند. ممکن است پیام SPF یا DKIM را با دامنه‌ای دیگر بگذراند اما در آزمون هم‌ترازی مردود شود. پیش از تغییر سیاست فروشگاه، همهٔ فرستندگان مجاز را بشناسید، پیام واقعی را بررسی کنید و از گزارش‌گیری برای فهم اثر اجرای سخت‌گیرانه‌تر استفاده کنید.
احراز هویت موفق را از هم‌ترازی جدا کنید
پیام ممکن است SPF یا DKIM را برای دامنه‌ای بگذراند که با فرستندهٔ قابل مشاهده هم‌تراز نیست. هم‌ترازی همان رابطه‌ای است که DMARC بررسی می‌کند. جزئیات به حالت و دامنه‌های پیکربندی‌شده بستگی دارند؛ بنابراین به‌جای داوری از روی یک نشان سبز، خود پیام را ببینید.
از راهنمای پیکربندی و هم‌ترازی دامنهٔ Sendvio برای حساب خود استفاده کنید و مسئول DNS را هم درگیر کنید. پیش از مناسب‌دانستن سیاست سخت‌گیرانه در کل دامنه، شاید ایمیل کارکنان، پاسخ پشتیبانی و سرویس‌های مجاز دیگری نیاز به رسیدگی داشته باشند.
آزمون ساده‌ای برای هم‌ترازی انجام دهید
کمپینی را تصور کنید که نشانی From قابل مشاهده‌اش از دامنهٔ فروشگاه استفاده می‌کند. پیام DKIM را می‌گذراند، اما امضای موفق به دامنه‌ای نامرتبط تعلق دارد. این نتیجه چیزی را احراز هویت می‌کند، اما هویت هم‌تراز موردنیاز فروشگاه را ثابت نمی‌کند. در مقابل، امضای موفق از دامنه‌ای که به‌درستی هم‌تراز است می‌تواند شرط DMARC را برآورده کند، حتی اگر مسیر احراز هویت دیگر این کار را نکند.
هم‌ترازی سخت‌گیرانه تطابق دقیق دامنه می‌خواهد. هم‌ترازی آسان‌گیرانه رابطهٔ دامنهٔ سازمانیِ مربوط را می‌پذیرد، نه لزوماً نام‌های کاملاً یکسان را. تفسیر درست به دامنه‌های واقعی، سیاست منتشرشده و ارزیابی گیرنده وابسته است. از مدیر بخواهید همان مقدارها را بررسی کند؛ همهٔ زیر‌دامنه‌ها یا نام‌های ظاهراً مشابه خودکار معادل نیستند.
به همین دلیل تغییر نشانی Reply-To هم شکست DMARC را حل نمی‌کند. مسیر پاسخ و احراز هویت هدف‌های جداگانه دارند. مسیر پاسخ مشتری را مفید نگه دارید، اما هم‌ترازی را از شناسه‌های موجود در پیام تحویل‌شده عیب‌یابی کنید.
پیش از اعمال سیاست بازبینی کنید
سیاست پایش می‌تواند نشان دهد کدام سامانه‌ها از دامنهٔ شما پیام می‌فرستند. گزارش‌ها نیاز به تفسیر دارند: ترافیک ناآشنا شاید غیرمجاز باشد، اما ممکن است به سرویس مجازی تعلق داشته باشد که کسی ثبتش نکرده است.
سیاست سخت‌گیرانهٔ راهنما را کپی نکنید و ایمن‌بودنش را فرض نگیرید. سخت‌کردن اجرا پیش از آماده‌بودن فرستندگان مجاز می‌تواند پیام‌های موردانتظار را مختل کند. سابقهٔ تغییر و برنامهٔ واکنشِ توافق‌شده داشته باشید تا اگر پس از به‌روزرسانی مشکلی پیش آمد، رسیدگی روشن باشد.
سیاست و گزارش‌گیری را تصمیم عملیاتی بدانید
سیاست none برای شکست احراز هویت نحوهٔ برخورد ویژه‌ای درخواست نمی‌کند. quarantine می‌گوید با شکست‌ها مشکوکانه برخورد شود و reject ترجیح سخت‌گیرانه‌تری برای رسیدگی بیان می‌کند. سامانه‌های دریافت همچنان با اطلاعات دیگر تصمیم خود را می‌گیرند. هیچ‌یک تضمین نمی‌کنند ایمیل مطلوب وارد صندوق اصلی شود یا هر تلاش جعل هویتی ناپدید گردد.
گزارش‌های تجمیعی نشان می‌دهند چه سامانه‌هایی از دامنه استفاده می‌کنند و احراز هویت و هم‌ترازی چگونه ارزیابی شده است. این‌ها مدرک عملیاتی‌اند، نه گزارش تعامل کمپین. مسئول تفسیر تعیین کنید و فرستندهٔ ناشناس را بررسی کنید. منبع ناآشنا می‌تواند سرویس مجازِ ثبت‌نشده، اثر هدایت یا استفادهٔ غیرمجاز باشد؛ هر احتمال اقدام متفاوتی می‌خواهد.
نتیجه را مرتب بررسی کنید
پیام آزمایشی کنترل‌شده بفرستید و هم‌ترازی را ببینید، سپس گزارش را با مدیر واجد صلاحیت مرور کنید. محافظت دامنه مسئولیتی پیوسته است، به‌خصوص هنگام افزودن سرویس ارسال یا تغییر دامنهٔ برند.
انتظار واقع‌بینانه داشته باشید. DMARC از هویت فرستنده محافظت می‌کند و به شکست‌های احراز هویت رسیدگی می‌کند؛ جلوی هر حملهٔ فیشینگ را نمی‌گیرد و ورود کمپین به صندوق ورودی را تضمین نمی‌کند. آن را با نام فرستندهٔ آشنا، مجوز مناسب و الگوی پیوستهٔ پیام‌هایی که گیرندگان انتظار دارند همراه کنید.
پیش از سخت‌کردن سیاست، فهرست فرستندگان را بسازید؛ از کارکنان و پشتیبانی تا بازاریابی و سرویس‌های عملیاتی. هر مسیر مرتبط را بیازمایید و هویت هم‌تراز موردانتظارش را ثبت کنید. اگر به‌روزرسانی ترافیک مجاز را مختل کرد، این فهرست کمک می‌کند سرویس آسیب‌دیده را بدون تضعیف کورکورانهٔ کل پیکربندی دامنه پیدا کنید.
مشخصات جاری DMARC در RFC 9989 که در مه ۲۰۲۶ منتشر شد، جایگزین RFC 7489 شده است. برای تصمیم‌های تازه از نسخهٔ جاری استاندارد و دستورهای حساب خود استفاده کنید، نه راهنمایی که به نسخهٔ قدیمی تکیه دارد. هدف عملی فروشگاه روشن است: فرستندگان مجاز را بشناسد، هم‌ترازی آن‌ها را بررسی و سیاستی انتخاب کند که پیامدش را درک می‌کند. هر زمان معماری ارسال تغییر کرد، شواهد را دوباره بررسی کنید.