نحوه خواندن خط‌مشی DMARC یک شرکت در ده ثانیه (و آنچه که آن درباره نمی‌گوید)

یک جستجوی DNS به شما می‌گوید که یک شرکت از سرورهای ایمیل دنیا می‌خواهد با ایمیل‌های جعلی ارسال‌شده به نام آن چه کار کنند. این رکورد عمومی است و دستور یک خط است: dig +short TXT _dmarc.example.com. آنچه برمی‌گردد رشته‌ای کوتاه از تنظیمات است، و در درون آن یک دستور وجود دارد — p=none، p=quarantine یا p=reject — که ترجیح مالک دامنه را هنگامی که پیامی با استفاده از آن دامنه در احراز هویت ناکام می‌شود بیان می‌کند.

مشخصه‌های فعلی RFC 9989، منتشر شده در می 2026 به عنوان سند IETF Standards Track، جایگزین RFC 7489 قدیمی‌تر شد. این سه مقدار را تقریباً مختصر تعریف می‌کند:

• p=none — «مالک دامنه هیچ ترجیحی را اعلام نمی‌کند.»
• p=quarantine — «مالک دامنه چنین ایمیلی را مشکوک می‌داند. ممکن است ایمیل معتبر باشد، اگرچه شکست در احراز هویت نگرانی قابل‌توجهی ایجاد می‌کند.»
• p=reject — «مالک دامنه تمام چنین شکست‌هایی را نشانه‌ای واضح می‌داند که استفاده از نام دامنه معتبر نیست.»

آن کلمات را دوباره بخوانید، زیرا آن‌ها ضعیف‌تر از آنچه بیشتر توضیحات DMARC اذعان می‌کنند هستند. یک خط‌مشی ترجیح است، منتشر شده توسط فرستنده برای ارزیابی توسط دریافت‌کنندگان. این دستوری نیست که دریافت‌کننده موظف است اجرا کند. RFC 9989 این را در یک جمله می‌گوید: «معالجه نهایی هر پیام همیشه موضوع خط‌مشی محلی است و به تشخیص دریافت‌کننده ایمیل واگذار می‌شود.» همان بخش هر دو طرف نتیجه را اضافه می‌کند — دریافت‌کنندگان «ممکن است» یک پیام را حتی اگر از بررسی DMARC عبور کند رد یا قرنطینه کنند، و آن‌ها «نباید» پیام‌ها را صرفاً به دلیل خط‌مشی منتشرشده «رد» رد کنند، دقیقاً برای اینکه ایمیل معتبری که به روش‌هایی ارسال می‌شود که DMARC نمی‌تواند توصیف کند و لیست‌های ارسال در این فرآیند ایجاد شکاف نیفتد.

پس p=none واقعاً چه چیزی را اعتراف می‌کند؟ کمتر از آنچه معمولاً متهم می‌شود. بر اساس شرایط خود مشخصه، این حالت نظارت است: مالک دامنه گزارش‌های کل‌شامل را جمع‌آوری می‌کند و «هیچ ترجیح معالجه‌ای برای پیام‌هایی که در احراز هویت DMARC ناکام می‌شوند بیان نمی‌کند،» در حالی که دریافت‌کنندگی که DMARC را مستقر می‌کند «می‌توانند همچنان» استفاده دامنه را تأیید کنند. آنچه که آن انجام نمی‌دهد این است که چیزی را در انتهای دریافت‌کننده خاموش نکند. فیلترینگ اسپم ارائه‌دهنده شما، نمره‌گذاری سمعه، بررسی‌های URL و تجزیه پیوست‌ها ماشین‌آلات جداگانه‌ای هستند که صرف‌نظر از آنچه فرستنده منتشر کرده است اجرا می‌شوند. ایمیلی جعلی که به دامنه p=none می‌رسد به صندوق ورودی شما توسط رکورد ارتقا داده نمی‌شود؛ به سادگی بدون ترجیح اعلام‌شده به دریافت‌کننده تحویل داده می‌شود، و دریافت‌کننده تصمیم می‌گیرد.

نیمه دیگر سوء‌تفاهم به سمت دیگری اجرا می‌شود. DMARC قسمت خطرناک ایمیل فیشینگ را نمی‌خواند. مشخصه‌های آن خود فهرستی از آنچه که عمداً خارج از دامنه است، و «تجزیه محتوا» در آن فهرست، در آن کلمات است. همچنین بیان می‌کند که DMARC «نام‌های دامنه ظاهراً شبیه یا سوء‌استفاده از نام نمایشی قابل‌خواندن برای انسان RFC5322.From را مطرح نمی‌کند» — دو ترفند که بیشتر ایمیل‌های تقلب برند را حمل می‌کند. و در مورد ارزش یک عبور: «عبور DMARC به تنهایی تضمین نمی‌کند که تحویل به صندوق ورودی گیرنده ایمن یا مطلوب باشد.» ایمیلی درست احراز‌شده از دامنه یک‌بار مصرف از DMARC به‌طور تمیزی عبور می‌کند. DMARC پاسخ می‌دهد که چه کسی مجاز به استفاده از دامنه در header From: بود. چیز دیگری نه.

این جایی است که قوانین فرستنده انبوه سال 2024 به طور منظم اشتباه گزارش می‌شوند، از جمله در نسخه اول این مقاله. دستورالعمل‌های فرستنده گوگل برای فرستندگانی که 5,000 یا بیشتر پیام در روز به حساب‌های Gmail ارسال می‌کنند می‌خواهد «احراز هویت ایمیل DMARC را برای دامنه ارسال خود تنظیم کنید،» و سپس در یک نفس می‌گوید: «خط‌مشی اجرای DMARC شما می‌تواند به none تنظیم شود.» Sender Hub خود Yahoo، که باید به‌طور جداگانه خوانده شود تا فرض نشود که گوگل را کپی کند، این الزام را به عنوان «انتشار یک خط‌مشی DMARC معتبر با حداقل p=none - DMARC باید عبور کند» بیان می‌کند، و هیچ آستانه حجم عددی منتشر نمی‌کند. هر دو مجموعه الزامات از فوریه 2024 اجرایی شدند. هیچ‌کدام کسی را از p=none بیرون نمی‌کشند. آنچه هر دو در واقع اجباری می‌کنند احراز هویتی است که مطابقت داشته باشد: گوگل می‌خواهد که «دامنه در header From: فرستنده باید با دامنه SPF یا دامنه DKIM تراز شده باشد،» و Yahoo می‌گوید که تراز شل قابل‌قبول است. تراز، نه شدت، دروازه است.

این باقی‌مانده‌ی دلیل واقعی که دامنه‌ها در نظارت قرار می‌گیرند را ترک می‌کند، و این عملیاتی است تا کارانه نه. انتقال به quarantine یا reject به معنای یافتن اول هر سرویسی است که ایمیل به نام شما ارسال می‌کند — حقوق، بلیط‌گیری، بازاریابی، یک میز پشتیبانی که هیچ‌کس ثبت نکرده است — و احراز هویت هر کدام تا تراز شوند. خود مشخصه خطرات را تشخیص می‌دهد که این کار را آهسته می‌کند: فرستندگان شخص ثالث نه توسط DMARC معرفی می‌شوند و نه استثنا شده‌اند، بازفرستی و لیست‌های ایمیل می‌توانند تراز را از طریق کمبود کسی در فرستنده شکستند، و مشخصه دریافت‌کنندگان را به RFC 7960 اشاره می‌کند برای دقیقاً آن حالت‌های شکست. یک سازمان که p=none را منتشر می‌کند و گزارش‌های خود را می‌خواند کار را به ترتیبی که مشخصه توصیف می‌کند انجام می‌دهد. یکی که p=none را منتشر می‌کند و گزارش‌ها را نادیده می‌گیرد نیست. از بیرون، رکورد تنهایی نمی‌تواند به شما بگوید کدام دو را شما نگاه می‌کنید.

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

اصلاح، 20 اکتبر 2026. نسخه‌ای قبلی از این مقاله p=none را به عنوان تحویل تقلب‌ها به صندوق ورودی و p=reject را تنها تنظیمی که پیام تقلب را مسدود می‌کند توصیف می‌کرد، می‌گفت که قوانین فرستنده انبوه گوگل و Yahoo سال 2024 فرستندگان را از p=none دور می‌کنند، و رقم تقریبی یکی در سه دامنه در اجرا را ذکر می‌کرد. توصیف‌های خط‌مشی علیه RFC 9989 اصلاح شده‌اند؛ گوگل و Yahoo در واقع p=none را می‌پذیرند، بالا از مستندات خود نقل شده‌اند؛ و رقم اجرا حذف شده است زیرا گزارش زمینه‌ای نمونه یا مخرج خود را منتشر نمی‌کند. مقاله اکنون آنچه را که DMARC بررسی نمی‌کند نیز بیان می‌کند.

@@END@@