اصطلاح · بررسی DMARC

DMARC ایمیل‌های برنامه را چگونه بررسی کنیم؟

بررسی DMARC باید چهار مورد جداگانه را تأیید کند: یک سیاست معتبر در DNS قابل‌کشف باشد، تگ‌های الزامی آن به‌درستی parse شوند، دست‌کم یک شناسه احرازهویت‌شده SPF یا DKIM روی یک پیام واقعی با دامنه From قابل‌مشاهده هم‌راستا باشد، و پیش از اعمال سیاست، همه فرستندگان مشروع برنامه در نظر گرفته شده باشند. نام _dmarc را کوئری کنید، رکورد را بررسی کنید و سپس نتایج احراز هویت پیام‌های ارسال‌شده به‌صورت کنترل‌شده را بسنجید. موفقیت DMARC استفاده مجاز از دامنه را تأیید می‌کند؛ تحویل یا رسیدن به صندوق ورودی را ثابت نمی‌کند.

بررسی DMARC را چهار آزمون بدانید، نه یک lookup

یک بررسی مفید چهار لایه دارد. اول، سیاستی را که برای دامنه نویسنده پیام اعمال می‌شود کشف کنید. دوم، رکورد TXT را به‌عنوان یک سیاست DMARC اعتبارسنجی کنید، نه اینکه هر متنی را که DNS برمی‌گرداند بپذیرید. سوم، هم‌راستایی شناسه‌ها را روی یک پیام واقعی آزمایش کنید: دامنه MAIL FROM احرازهویت‌شده با SPF یا دامنه امضای DKIM تأییدشده باید با دامنه موجود در هدر From قابل‌مشاهده هم‌راستا باشد. چهارم، پوشش عملیاتی را با ارسال از طریق همه برنامه‌ها، ارائه‌دهندگان، regionها و انواع پیام مشروعی که از این دامنه استفاده می‌کنند تأیید کنید. یک lookup سبز در DNS فقط بخشی از دو لایه اول را پوشش می‌دهد. نمی‌تواند نشان دهد که ارائه‌دهنده با دامنه موردنظر امضا می‌کند، return path سفارشی فعال است، forwarding رفتار SPF را تغییر داده است یا اینکه سیستمی از قلم‌افتاده پس از اعمال سیاست همچنان کار خواهد کرد.

نام DNS درست را کوئری کنید و روند کشف سیاست را دنبال کنید

از دامنه دقیق در هدر From طبق RFC5322 شروع کنید که اغلب دامنه نویسنده (author domain) نامیده می‌شود. رکورد TXT را در _dmarc به‌همراه آن دامنه کوئری کنید. برای پیامی از alerts@notify.example.test، از _dmarc.notify.example.test شروع کنید، نه از میزبان وب‌سایت، میزبان MX یا دامنه return-path. RFC 9989 کشف سیاست را فراتر از یک lookup تعریف می‌کند: اگر دامنه نویسنده رکورد معتبری نداشته باشد، گیرنده می‌تواند درخت DNS را پیمایش کند تا سیاست قابل‌اعمال در سطح دامنه سازمانی یا public suffix را بیابد. رفتار زیردامنه‌ها بسته به اینکه چه چیزی وجود دارد و سیاست کجا پیدا می‌شود، می‌تواند از تگ sp، np یا p بیاید. یعنی ابزار بررسی باید هم نام کوئری‌شده و هم دامنه سیاستی را که واقعاً انتخاب کرده گزارش کند. نتیجه‌ای که فقط می‌گوید رکورد پیدا شد، ممکن است اشتباهات ارث‌بری یا یک سیاست صریح زیردامنه را که برخورد موردانتظار را تغییر می‌دهد پنهان کند.

پیش از تفسیر سیاست، ساختار رکورد را اعتبارسنجی کنید

یک رکورد سیاست DMARC از syntax تگ-مقدار استفاده می‌کند. طبق RFC 9989، v=DMARC1 الزامی، حساس به حروف بزرگ و کوچک و باید نخستین مورد باشد؛ یک تگ p معتبر سیاست ارزیابی درخواستی را فراهم می‌کند. مقادیر متداول سیاست none، quarantine و reject هستند. تگ‌های اختیاری مقصدهای گزارش، رفتار زیردامنه و هم‌راستایی SPF و DKIM به‌صورت strict یا relaxed را شرح می‌دهند. تگ‌های غلط‌املایی، مقدار p مفقود، رکوردهای تکراری یا متعارض، جداکننده‌های نامعتبر یا مقداری که همراه با آثار نقل‌قول‌گذاری ارائه‌دهنده DNS کپی شده است را بی‌صدا اصلاح نکنید. با خطای ارزیابی دائمی به‌عنوان نتیجه‌ای که باید اصلاح شود رفتار کنید، نه عبور یا شکست DMARC. همچنین خطای گذرای lookup DNS را از رکورد بدشکل متمایز کنید. خرابی گذرای resolver را از مسیری کنترل‌شده دوباره امتحان کنید، اما تا زمانی که DNS authoritative به‌طور قابل‌اعتماد query نشود ادعا نکنید دامنه سیاستی ندارد.

هم‌راستایی SPF و DKIM را روی یک پیام واقعی بررسی کنید

DMARC بر اساس احراز هویت پیام ارزیابی می‌شود، نه پیکربندی DNS به‌تنهایی. برای SPF، دامنه MAIL FROM احرازهویت‌شده را با دامنه From قابل‌مشاهده مقایسه کنید. برای DKIM، دامنه d= هر امضای با موفقیت تأییدشده را با دامنه From قابل‌مشاهده مقایسه کنید. هم‌راستایی relaxed دامنه‌هایی با دامنه سازمانی یکسان را می‌پذیرد؛ هم‌راستایی strict دامنه‌های کاملاً یکسان را الزامی می‌کند. پیام زمانی موفق می‌شود که دست‌کم یک شناسه احرازهویت‌شده در سازوکار اصلی خود موفق و هم‌راستا باشد. برای مثال، return path ارائه‌دهنده می‌تواند باعث موفقیت SPF برای دامنه ارائه‌دهنده شود اما با billing.example.test هم‌راستا نباشد. اگر DKIM با d=example.test در هم‌راستایی relaxed تأیید شود، پیام همچنان می‌تواند در DMARC موفق شود. هدر خام Authentication-Results را از حساب‌های گیرنده کنترل‌شده ثبت کنید، اما آن را در بافت خودش تفسیر کنید، چون نتیجه گیرنده ارزیاب را گزارش می‌کند و ممکن است شامل چند hop یا چند امضا باشد.

نتایج pass، fail، none و error را دقیق بخوانید

عبور DMARC یعنی رکورد سیاست اعمال می‌شود و یک شناسه احرازشده SPF یا DKIM با دامنه نویسنده هم‌راستا است. شکست یعنی سیاست اعمال می‌شود اما هیچ شناسه احرازشده هم‌راستایی وجود ندارد. None یعنی هیچ سیاست قابل‌اعمالی کشف نشده است. Permerror و temperror نشان‌دهنده خطا در ارزیابی DMARC هستند؛ پیامی با خطای DNS را نمی‌توان گذرانده یا شکست‌خورده DMARC دانست. این نتایج نمی‌گویند ارائه‌دهنده صندوق ایمیل، پیام را کجا قرار داده است. RFC 9989 صراحتاً عبور را به اعتبارسنجی مجازبودن استفاده مالک دامنه محدود می‌کند؛ اعلام نمی‌کند پیام امن، موردنیاز، معتبر یا شایسته صندوق ورودی است. پذیرش ارائه‌دهنده، پذیرش سرور گیرنده، نتیجه DMARC، سیگنال‌های گزارش اسپم و جای‌گذاری مشاهده‌شده را در عیب‌یابی و داشبوردها فیلدهای جداگانه نگه دارید.

پیش از اعمال سیاست، همه فرستندگان مشروع را شناسایی کنید

همه سیستم‌هایی را که دامنه را در From قرار می‌دهند فهرست کنید: برنامه‌های production، ایمیل‌های احراز هویت، اطلاعیه‌های صورتحساب، ابزارهای پشتیبانی، پلتفرم‌های بازاریابی، هشدارهای پایش، گردش‌کارهای CRM، حساب‌های منطقه‌ای و سیستم‌های اضطراری. برای هر جریان، دامنه From قابل‌مشاهده، دامنه MAIL FROM، دامنه d= و selector در DKIM، حساب ارائه‌دهنده، مالک، نوع پیام و حجم موردانتظار را ثبت کنید. پیام‌های کنترل‌شده را از مسیر عادی production ارسال کنید و هم احراز هویت و هم هم‌راستایی را بررسی کنید. گزارش‌های تجمیعی DMARC می‌توانند منابعی را که از دامنه استفاده می‌کنند آشکار کنند، اما نیاز به تفسیر دارند و ممکن است شامل ترافیک forward‌شده یا غیرمجاز باشند. تا وقتی فهرست کامل نشده، با پایش شروع کنید و سپس پیش از درخواست برخورد سخت‌گیرانه‌تر از گیرنده، جریان‌های مشروع ناهم‌راستا را اصلاح کنید. سیاست مشترک سازمان را فقط برای سبز شدن یک برنامه تغییر ندهید و بر اساس یک پیام آزمایشی به مرحله اعمال سیاست نروید.

عیب‌یابی خطاهای رایج ایمیل‌های برنامه

اگر سیاستی پیدا نشد، پیش از ویرایش مقدار، zone در DNS و نام رکورد را بررسی کنید. اگر رکورد خطای دائمی دارد، آن را به یک سیاست معتبر کاهش دهید و ترتیب و سینتکس تگ‌ها را بررسی کنید. اگر DKIM رد شد، بررسی کنید که selector موردانتظار وجود دارد، ارائه‌دهنده واقعاً پیام آزمایشی را امضا کرده است، بدنه یا هدرهای امضاشده در مسیر تغییر نکرده‌اند و دامنه d= تأییدشده هم‌راستاست. اگر SPF موفق شد اما DMARC رد شد، به‌جای کافی دانستن هر موفقیت SPF، دامنه MAIL FROM را با دامنه From قابل‌مشاهده مقایسه کنید. اگر فقط ایمیل‌های forward‌شده رد می‌شوند، به یاد داشته باشید که forwarding اغلب مسیر envelope را تغییر می‌دهد و می‌تواند SPF را از کار بیندازد، در حالی که یک امضای DKIM معتبر و هم‌راستا ممکن است سالم بماند. اگر انتشار سیاست باعث رد شدن پیام‌ها شد، هدرهای پیام ناموفق و پاسخ گیرنده را نگه دارید، افزایش بیشتر سیاست را متوقف کنید و به‌جای تضعیف کنترل‌های احراز هویت نامرتبط، جریان مسئول را اصلاح کنید.

قواعد هم‌راستایی مخصوص هر ارائه‌دهنده را آگاهانه اعمال کنید

فرستندگان شخص ثالث به پیکربندی‌ای نیاز دارند که شناسه‌های احرازهویت‌شده آن‌ها را به دامنه‌ای تحت کنترل سازمان متصل کند. Amazon SES دو مسیر را مستند کرده است: یک دامنه MAIL FROM سفارشی و هم‌راستا برای SPF و یک دامنه امضای DKIM هم‌راستا. return path پیش‌فرض آن که متعلق به ارائه‌دهنده است ممکن است با SPF احراز هویت کند بدون اینکه با دامنه From قابل‌مشاهده هم‌راستا باشد؛ بنابراین تا وقتی دامنه MAIL FROM سفارشی پیکربندی نشده، DKIM معمولاً سازوکار هم‌راستای عملی است. ارائه‌دهندگان دیگر برای return path، دامنه برگشت، احراز هویت دامنه و هویت‌های امضا از نام‌های متفاوتی استفاده می‌کنند. پیام خروجی دقیق را بررسی کنید، به‌جای اینکه فرض کنید نشان verified در داشبورد، DMARC را برقرار می‌کند. راهنمای فعلی Gmail برای فرستندگان نیز برای ترافیک مشمول، احراز هویت و هم‌راستایی را الزامی می‌داند و گزارش‌گیری DMARC را توصیه می‌کند. الزامات گیرندگان و قابلیت‌های ارائه‌دهندگان ممکن است تغییر کنند، پس مستندات رسمی آن‌ها را هنگام راه‌اندازی و در بازبینی حوادث دوباره بررسی کنید.

از شواهد ارائه‌دهنده استفاده کنید، بدون اینکه آن را حکم DMARC بدانید

SendHQ از ارسال با دامنه تأییدشده، رویدادهای تحویل، موارد توقف ارسال و یک داشبورد وب پشتیبانی می‌کند. از اطلاعات دامنه ارسال و تحویل آن برای بررسی یک stream پیام استفاده کنید، سپس DMARC را از هدر Authentication-Results گیرنده تأیید و شواهد SPF، DKIM و هم‌راستایی را جدا کنید. پذیرش ارائه‌دهنده و رویدادهای تحویل، رسیدن به صندوق ورودی را اثبات نمی‌کنند.

نتیجه بررسی DMARC را به‌صورت قابل‌ممیزی ثبت کنید

یک نتیجه ماندگار باید شامل دامنه نویسنده، زمان کوئری، resolver، نام _dmarc کوئری‌شده، دامنه سیاست انتخاب‌شده، رکورد دقیق نرمال‌شده، حالت‌های سیاست و هم‌راستایی، وضعیت DNS و اینکه parse به سینتکس قابل‌قبول، permerror یا temperror منجر شده است باشد. برای هر پیام کنترل‌شده یک ردیف اضافه کنید، شامل شناسه غیرحساس پیام، سیستم ارسال، دامنه From قابل‌مشاهده، دامنه و نتیجه SPF احرازهویت‌شده، دامنه‌ها و selectorهای DKIM تأییدشده، تصمیم‌های هم‌راستایی، نتیجه نهایی DMARC و گیرنده. هدرهای خام را در فضای ذخیره‌سازی با دسترسی محدود نگه دارید، چون ممکن است نشانی‌ها، جزئیات مسیریابی و شناسه‌های داخلی را افشا کنند. هر یافته را به یک مالک و تاریخ اصلاح پیوند دهید. پس از انقضای TTLهای DNS، تغییر پیکربندی ارائه‌دهنده، چرخش کلید، جریان‌های پیام جدید یا افزایش سیاست، دوباره بررسی کنید. این شواهد بررسی را تکرارپذیر می‌کند و مانع می‌شود یک اسکرین‌شات یا نشان یک ابزار، پس از تغییر پیکربندی زیربنایی، به اثبات دائمی تبدیل شود.

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

رکورد DMARC را کجا باید بررسی کرد؟

با رکورد TXT در _dmarc به‌همراه دامنه دقیق نشانی From قابل‌مشاهده شروع کنید. دامنه سیاستی را هم که طبق قواعد فعلی کشف DMARC انتخاب می‌شود شناسایی کنید، چون وقتی اولین نام کوئری‌شده رکورد معتبری ندارد، ممکن است سیاست سازمانی یا سیاست زیردامنه اعمال شود.

آیا پیدا شدن v=DMARC1 یعنی DMARC موفق است؟

خیر. این فقط بخشی از یک رکورد سیاست معتبر است. پیام زمانی موفق می‌شود که SPF یا DKIM با دامنه‌ای هم‌راستا با دامنه From قابل‌مشاهده احراز هویت کند. یک پیام واقعی را آزمایش کنید و نتایج احراز هویت گیرنده را بررسی کنید.

آیا DMARC وقتی SPF هم‌راستا نیست می‌تواند موفق شود؟

بله. یک امضای DKIM با موفقیت تأییدشده می‌تواند شناسه احرازهویت‌شده هم‌راستای موردنیاز DMARC را فراهم کند. عکس آن هم ممکن است: SPF هم‌راستا می‌تواند وقتی DKIM موفق نیست به موفقیت کمک کند، هرچند اتکا به فقط یک سازوکار تاب‌آوری را کاهش می‌دهد.

آیا موفقیت DMARC رسیدن به صندوق ورودی را ثابت می‌کند؟

خیر. فقط استفاده مجاز از دامنه نویسنده را برای آن پیام تأیید می‌کند. گیرنده همچنان می‌تواند هنگام پذیرش، رد، قرنطینه یا دسته‌بندی پیام، سیگنال‌های اعتبار، محتوا، گیرنده، سوءاستفاده و سیاست محلی را اعمال کند.

آیا برنامه باید مستقیماً به p=reject برود؟

معمولاً نه، بدون شواهد فهرست موجودی و پایش. هر فرستنده مجاز را نگاشت کنید، هم‌راستایی را در پیام‌های کنترل‌شده اعتبارسنجی کنید، گزارش‌های تجمیعی را بررسی کنید، خرابی‌ها را رفع کنید و پیش از درخواست رسیدگی سخت‌گیرانه‌تر، تغییرهای سیاست را با مالک دامنه هماهنگ کنید.

پس از تغییر ارائه‌دهنده ایمیل چه چیزهایی را باید دوباره بررسی کرد؟

پیش از افزایش ترافیک production، این موارد را دوباره بررسی کنید: سیاست کشف‌شده برای هر دامنه From، دامنه‌های MAIL FROM و DKIM ارائه‌دهنده، DNS مربوط به selector، نتایج SPF و DKIM، هم‌راستایی relaxed یا strict، گزارش‌های تجمیعی و همه انواع پیام‌های کنترل‌شده برنامه.

منابع