اصطلاح · بررسی DKIM
DKIM ایمیل اپلیکیشن را چگونه بررسی کنیم؟
یک بررسی قابل‌اتکای DKIM از یک پیام واقعی تحویلشده استفاده میکند. هدر DKIM-Signature را بخوانید، دامنه امضاکننده (`d=`) و selector (`s=`) آن را استخراج کنید، کلید DNS متناظر را در `<selector>._domainkey.<domain>` کوئری کنید و هدرهای امضاشده و بدنه را به‌صورت رمزنگاری تأیید کنید. سپس Authentication-Results یک گیرنده مورد اعتماد را بررسی کنید. در دسترس بودن رکورد، تأیید امضا، همراستایی DMARC، پذیرش توسط سرور گیرنده و رسیدن به صندوق ورودی را نتایجی جداگانه نگه دارید.
بررسی DKIM را چهار آزمون جداگانه بدانید
یک lookup در DNS به‌تنهایی بررسی کامل DKIM نیست. اول، مطمئن شوید پیام یک فیلد DKIM-Signature دارد و امضایی را که می‌خواهید آزمایش کنید مشخص کنید. دوم، رکورد کلید عمومی‌ای را که آن امضا به آن اشاره میکند دریافت و parse کنید. سوم، تأیید کنید که هدرهای امضاشده و بدنه canonicalشده هنوز با امضای رمزنگاری مطابقت دارند. چهارم، تعیین کنید که آیا دامنه امضاکنندهای که pass شده با دامنه From قابلمشاهده برای DMARC هم‌راستاست. این لایه‌ها به پرسش‌های متفاوتی پاسخ می‌دهند. یک رکورد منتشرشده ممکن است استفاده نشود، یک پیام ممکن است به selector ناموجود اشاره کند، یک امضا ممکن است پس از تغییر محتوا fail شود و یک pass رمزنگاری ممکن است با دامنه نویسنده همراستا نباشد. هر نتیجه را جداگانه ثبت کنید، نه اینکه فقط یک نشان سبز نمایش دهید. وضعیت‌های انتقال و صندوق ایمیل را هم جدا نگه دارید: پذیرش توسط ارائهدهنده، پذیرش توسط سرور گیرنده و رسیدن به صندوق ورودی، نتایج تأیید DKIM نیستند.
از امضای یک پیام واقعی شروع کنید
پیام خام را از یک گیرنده کنترلشده که از مسیر عادی اپلیکیشن به آن رسیده‌اید دریافت کنید. در هر فیلد DKIM-Signature، دامنه امضاکننده `d=`، selector `s=`، الگوریتم `a=`، حالت‌های canonicalization `c=`، فهرست هدرهای امضاشده `h=`، هش بدنه `bh=`، داده امضا `b=` و در صورت وجود، مهرهای زمانی را ثبت کنید. RFC 6376 تگهای دامنه امضاکننده و selector را تعریف میکند و از آن‌ها برای یافتن کلید عمومی استفاده میکند. selector را از روی داشبورد ارائهدهنده حدس نزنید و بدون آن `_domainkey` را کوئری نکنید. یک پیام ممکن است چند امضا از فرستنده، واسطه یا سیستم فهرست پستی داشته باشد؛ پس نتیجه هر امضا را نگه دارید. پیامهای محیط عملیاتی را در ابزارهای بررسی عمومی paste نکنید: هدرها و بدنه خام می‌توانند گیرندگان، شناسه‌های پیام، جزئیات مسیریابی، توکن‌های لغو اشتراک و محتوای اپلیکیشن را افشا کنند. وقتی به محتوای کامل نیازی نیست، از فضای ذخیره‌سازی با دسترسی محدود و یک نسخه عیبیابی ویرایش‌شده استفاده کنید.
دقیقاً همان selector و دامنه امضاکننده را کوئری کنید
نام DNS را از روی امضا به شکل `<selector>._domainkey.<signing-domain>` بسازید. اگر هدر شامل `s=app2026` و `d=notify.example.test` باشد، رکورد TXT را در `app2026._domainkey.notify.example.test` کوئری کنید. نام اصلی، resolver، پاسخ، TTL و هر زنجیره CNAME را ثبت کنید. رکورد tag-value حاصل را parse کنید، نه اینکه دنبال یک تکه متن بگردید. رکورد می‌تواند نسخه، نوع کلید، محدودیت سرویس، flagها، الگوریتم‌های هش و داده کلید عمومی را اعلام کند. مقدار خالی کلید عمومی یعنی کلید باطل شده است. بین NXDOMAIN، پاسخ خالی، محتوای نادرست، الگوریتم پشتیبانی‌نشده، کلید غیرقابل‌استفاده و خطای موقت resolver تمایز قائل شوید. پس از منقضی شدن TTL، lookup تغییرکرده را از طریق یک resolver مستقل تکرار کنید، اما فرض نکنید همه گیرندگان بلافاصله به‌روز شدهاند. موفقیت DNS فقط ثابت میکند که رکوردی در آن لحظه برگردانده شده است؛ ثابت نمی‌کند که پیام آزمایششده تأیید میشود یا ارائهدهنده ترافیک فعلی را با آن selector امضا میکند.
هدرها، هش بدنه و امضا را تأیید کنید
تأیید DKIM از قوانین canonicalization اعلام‌شده در امضا پیروی میکند. تأییدکننده بدنه را canonical میکند، هش آن را محاسبه و با `bh=` مقایسه میکند. همچنین هدرهای امضاشده‌ای را که در `h=` نام برده شدهاند canonical میکند، فیلد DKIM-Signature را طبق مشخصات در محاسبه وارد میکند و `b=` را با کلید عمومی تأیید میکند. به‌جای بازسازی این تبدیل‌ها با عملیات رشته‌ای، از یک کتابخانه تأییدکننده نگهداری‌شده یا نتیجه احراز هویت یک گیرنده مورد اعتماد استفاده کنید. عدم تطابق هش بدنه معمولاً یعنی بدنه پس از امضا تغییر کرده است، در حالی که خطای امضای هدر می‌تواند نشانه تغییر هدرهای امضاشده، کلید اشتباه، داده امضای خراب یا خطای پیاده‌سازی باشد. ثبت کنید کدام مرحله fail شده است. بررسی کنید که فیلدهای مهمی مانند From، Subject، Date و Message-ID امضا شدهاند یا نه، اما یک سیاست همگانی برای هدرهای امضاشده از خودتان نسازید. canonicalization تغییرات قالب‌بندی تعریف‌شده را تحمل میکند؛ افزودن دلبخواهی footer، بازنویسی MIME، خرابی پایان خطوط یا تغییر در مسیر انتقال را بی‌خطر نمی‌کند.
نتایج گیرنده را درون مرز اعتماد آن بخوانید
RFC 8601 هدر Authentication-Results و نتایج DKIM شامل none، pass، fail، policy، neutral، temperror و permerror را تعریف میکند. pass یعنی گیرنده امضای قابلقبولی یافته که آزمون‌های تأیید را گذرانده است. temperror می‌تواند بازتاب شرایطی باشد که احتمالاً تغییر میکند، مانند خطای موقت در lookup کلید؛ permerror بدون اصلاح، در تلاش بعدی هم احتمالاً موفق نمی‌شود. سرویس احراز هویت گزارش‌دهنده، دامنه امضاکننده، selector و الگوریتم را در صورت ارائه ثبت کنید. فقط به نتایجی اعتماد کنید که درون مرز مستند سیستم گیرنده درج شدهاند، چون فرستنده می‌تواند پیش از ارسال یک فیلد Authentication-Results جعلی اضافه کند. بالاترین نتیجه مورد اعتماد را برای محیط گیرنده نهایی بررسی کنید و hopهای میانی را هم در نظر بگیرید. اگر گیرندگان مختلف نتایج متفاوتی دارند، نسخه دقیق پیام، دید DNS، زمان ارزیابی، الگوریتم‌های پشتیبانی‌شده و سیاست محلی را مقایسه کنید. `dkim=pass` را به این ادعا تبدیل نکنید که ارائهدهنده صندوق ایمیل محتوا را تأیید کرده یا آن را در صندوق ورودی قرار داده است.
همراستایی DMARC را جدا از pass شدن DKIM بررسی کنید
pass شدن DKIM دامنه امضاکننده در `d=` را احراز هویت میکند؛ لازم نیست این دامنه با دامنه From قابلمشاهده طبق RFC 5322 برابر باشد. RFC 9989 یک شناسه احرازهویت‌شده با DKIM را فقط زمانی برای DMARC به کار می‌برد که طبق حالت همراستایی strict یا relaxed مربوط، با دامنه نویسنده همراستا باشد. برای مثال، پیامی از `billing.example.test` که با `d=provider.test` امضا شده می‌تواند DKIM را pass کند اما همراستا نباشد. امضای معتبری از `d=example.test` ممکن است در حالت relaxed، بسته به محاسبه دامنه سازمانی و سیاست، همراستا شود. سه فیلد را گزارش کنید: نتیجه DKIM، دامنه امضاکننده و تصمیم همراستایی. پیام می‌تواند وقتی DKIM fail شده یا همراستا نیست، از طریق SPF همراستا DMARC را pass کند؛ پس pass شدن DMARC ثابت نمی‌کند که آن امضای DKIM خاص pass شده است. راهنمای فعلی فرستندگان Gmail برای ترافیک مشمول، الزاماتی در احراز هویت و همراستایی دارد، اما برآورده کردن آن‌ها همچنان پذیرش توسط سرور گیرنده یا رسیدن به صندوق ورودی را تضمین نمی‌کند.
الگوریتم‌های فعلی و چرخش کلید را بررسی کنید
RFC 8301 الزامات رمزنگاری DKIM را به‌روز میکند: امضاکنندگان باید از `rsa-sha256` استفاده کنند، تأییدکنندگان باید از آن پشتیبانی کنند و `rsa-sha1` نباید استفاده شود. این RFC همچنین کلیدهای امضای RSA با دست‌کم 1024 بیت را الزامی میکند و توضیح می‌دهد که چرا در صورت امکان عملیاتی، کلیدهای بزرگ‌تر ارجح‌اند. یک ابزار بررسی باید الگوریتم را شناسایی کند و موارد منسوخ یا غیرقابل‌استفاده را علامت بزند، بدون اینکه ادعا کند طول کلید به‌تنهایی یک جریان ایمیل را قابل‌اعتماد میکند. گردش‌کار ارائه‌دهندگان متفاوت است. Amazon SES مستند کرده که Easy DKIM به‌طور پیش‌فرض از کلیدهای 2048 بیتی استفاده میکند و هشدار می‌دهد که تغییر روش امضا بدون یک مرحله میانی می‌تواند دوره‌ای ایجاد کند که پیام‌ها امضای DKIM ندارند. چرخش کلید را با دو selector معتبر یا سازوکار همپوشانی مستند ارائهدهنده برنامه‌ریزی کنید، مطمئن شوید پیامهای جدید از selector جدید استفاده میکنند، کلید عمومی قدیمی را تا زمانی که ایمیل‌های تأخیری ممکن است برسند نگه دارید و فقط پس از دوره همپوشانی آن را حذف کنید. هرگز کلید خصوصی امضا را در DNS، لاگ‌ها، تیکت‌ها یا promptها منتشر نکنید.
خطاها را از خود پیام به بیرون عیبیابی کنید
وقتی بررسی fail میشود، پیش از تغییر DNS، پیام خام و نتیجه گیرنده را نگه دارید. مطمئن شوید پیام واقعاً توسط اپلیکیشن و ارائهدهنده موردانتظار تولید شده است. اگر امضایی وجود ندارد، بررسی کنید که امضا برای آن هویت، region، tenant یا کلاس پیام فعال بوده است یا نه. اگر lookup مربوط به selector fail میشود، مقادیر دقیق `d=` و `s=`، zone در DNS، مقصد CNAME، TTL و چرخش‌های اخیر کلید را مقایسه کنید. اگر کلید parse میشود اما هش بدنه fail میشود، gatewayها، footerهای فهرست پستی، بازنویسیهای ردیابی، تبدیل‌های MIME، پایان خطوط و محصولات امنیتی‌ای را که ممکن است پس از امضا محتوا را تغییر دهند بررسی کنید. اگر امضای رمزنگاری با وجود تطابق هش بدنه fail میشود، تغییرات هدرهای امضاشده، عدم تطابق کلید و پیاده‌سازی امضا را بررسی کنید. اگر DKIM pass میشود اما DMARC fail میشود، به‌جای انتشار دوباره همان کلید، همراستایی را آزمایش کنید. پس از گذشت TTL مربوط یا انتشار پیکربندی، دوباره از طریق گیرندگان کنترلشده آزمایش کنید و برای هر کلاس پیام شواهد را ثبت کنید، نه اینکه با یک نمونه موفق کل دامنه را اصلاح‌شده اعلام کنید.
یک سابقه قابل‌ممیزی از بررسی DKIM نگه دارید
برای هر پیام کنترلشده، یک شناسه همبستگی غیرحساس، سیستم ارسال، حساب یا فضای کاری ارائهدهنده، دامنه From قابلمشاهده، سیستم گیرنده، زمان پیام و نتیجه کامل هر امضا را نگه دارید. `d=`، `s=`، `a=`، canonicalization، هدرهای امضاشده، نام کوئری DNS، زمان پاسخ DNS و TTL، وضعیت رکورد کلید، نتیجه هش بدنه، نتیجه امضا، مقدار Authentication-Results مورد اعتماد، تصمیم همراستایی DMARC و مسئول رفع مشکل را هم ثبت کنید. پیامهای خام را فقط جایی ذخیره کنید که کنترل‌های دسترسی و نگهداری مناسب وجود دارد. سناریوی آزمون را اضافه کنید: ارسال عادی اپلیکیشن، مهاجرت ارائهدهنده، چرخش کلید، مسیر gateway یا حالت forward. این کار پسرفت‌ها را قابل مقایسه میکند و مانع میشود یک اسکرین‌شات پس از تغییر selectorها یا پردازش پیام، به مدرک دائمی تبدیل شود. پس از تغییر راه‌اندازی ارائهدهنده، تغییرات DNS، تغییر روش امضا، تغییر مسیریابی یا اضافه شدن کلاس پیام جدید، دوباره بررسی کنید. یک داشبورد عملیاتی باید وضعیت‌های نامعلوم و در دسترس نبودن را صریحاً نشان دهد، نه اینکه بی‌صدا آن‌ها را pass یا fail در نظر بگیرد.
جایگاه SendHQ در این بررسی را بشناسید
SendHQ به دامنه From تأییدشده نیاز دارد و رویدادهای تحویل فراهم میکند. برای بررسی DKIM، یک پیام کنترلشده را از مسیر موردنظر اپلیکیشن ارسال کنید، امضای دریافت‌شده را بررسی کنید، مقادیر واقعی `d=` و `s=` را query کنید و همراستایی را جداگانه ثبت کنید. selector، طول کلید، الگوریتم امضا، رسیدن به صندوق ورودی یا تضمین تحویل را تنها از مستندات محصول استنباط نکنید.
پرسش‌های متداول
selector مربوط به DKIM را کجا پیدا کنم؟
پیام خام را باز کنید و فیلد DKIM-Signature را پیدا کنید. selector مقدار `s=` و دامنه امضاکننده مقدار `d=` است. با این دو، نام `<selector>._domainkey.<signing-domain>` را برای کوئری DNS بسازید.
آیا پیدا شدن رکورد DNS مربوط به DKIM یعنی DKIM pass میشود؟
خیر. رکورد فقط کلید و تگهای سیاست را فراهم میکند. تأییدکننده باید با آن بدنه canonicalشده، هدرهای امضاشده، هش بدنه، داده امضا و الگوریتم همان پیام مشخص را بررسی کند. یک پیام واقعی تحویلشده را آزمایش کنید.
آیا ممکن است DKIM پاس شود ولی DMARC رد شود؟
بله. DKIM ممکن است با دامنه امضاکنندهای تأیید شود که با دامنه From قابلمشاهده همراستا نیست. DMARC به یک شناسه SPF یا DKIM passشده و همراستا طبق حالت همراستایی مربوط نیاز دارد؛ پس تأیید و همراستایی را جداگانه گزارش کنید.
علت عدم تطابق هش بدنه در DKIM چیست؟
بدنه canonicalشدهای که تأییدکننده دریافت کرده با آنچه امضاکننده هش کرده متفاوت است. حوزههای رایج بررسی شامل gatewayها، footerها، بازنویسیهای ردیابی، تبدیل MIME، ابزارهای امنیتی و تغییر پایان خطوط پس از امضا است. پیش از عیبیابی، پیام دقیق را نگه دارید.
آیا selectorهای قدیمی DKIM باید بلافاصله پس از چرخش کلید حذف شوند؟
خیر. کلید عمومی قدیمی را در یک دوره همپوشانی کنترلشده در دسترس نگه دارید تا پیامهای تأخیری که با آن امضا شدهاند همچنان تأیید شوند. پیش از حذف رکورد DNS قدیمی، مطمئن شوید ترافیک جدید از selector جدید استفاده میکند و فرایند مستند چرخش کلید ارائهدهنده را دنبال کنید.
آیا pass شدن DKIM رسیدن به صندوق ورودی را ثابت میکند؟
خیر. فقط تأیید میکند که پیام آزمایششده نزد گیرنده ارزیابیکننده امضای قابلقبولی داشته است. گیرندگان همچنان هنگام پذیرش و دستهبندی ایمیل، سیگنالهای همراستایی احراز هویت، اعتبار، محتوا، گزارش اسپم، گیرنده و سیاست محلی را اعمال میکنند.
منابع
- RFC 6376: امضاهای DomainKeys Identified Mail (DKIM) — RFC Editor
- RFC 8301: به‌روزرسانی الگوریتم رمزنگاری و اندازه کلید برای DomainKeys Identified Mail (DKIM) — RFC Editor
- RFC 8601: فیلد هدر Authentication-Results — RFC Editor
- RFC 9989: احراز هویت، گزارش‌دهی و انطباق پیام مبتنی بر دامنه (DMARC) — RFC Editor
- راهنمای فرستندگان ایمیل Gmail — Google
- Easy DKIM در Amazon SES — Amazon Web Services
- قرارداد OpenAPI در SendHQ — SendHQ