محتوای آموزشی وبلاگ نت‌آرام
ایمیل‌های دامنه‌تان به مقصد می‌رسند، اما در گزارش پیام عبارت
dkim=fail یا dkim=none دیده می‌شود. برای رفع مشکل لازم نیست کلید خصوصی سرور را برای کسی بفرستید. ابتدا باید ببینیم خود پیام امضا شده است یا نه، امضا از کدام دامنه و selector استفاده می‌کند و آیا کلید عمومی مربوط از DNS پیدا می‌شود.این راهنما مکمل آشنایی با SPF، DKIM و DMARC است و روی بررسی عملی DKIM تمرکز دارد. نام‌های
example.com و selector1 فقط مثال‌اند؛ مقادیر واقعی را از ایمیل و ارائه‌دهنده سرویس خودتان بردارید.DKIM، کلید عمومی و کلید خصوصی به زبان ساده
سرویس فرستنده می‌تواند با کلید خصوصی خود بخشی از پیام را امضا کند. گیرنده با استفاده از کلید عمومی منتشرشده در DNS بررسی می‌کند آیا امضا با پیام دریافتی سازگار است یا نه. کلید خصوصی باید محرمانه بماند؛ کلید عمومی و رکورد DNS آن برای همین بررسی عمومی طراحی شده‌اند.
هر سرویس ممکن است selector مخصوص خودش را داشته باشد. selector شبیه برچسبی است که به گیرنده می‌گوید کدام کلید عمومی مربوط به این امضا را پیدا کند. اگر چند سرویس از دامنه شما ایمیل می‌فرستند، ممکن است selectorهای متفاوت داشته باشند. نتیجه یک سرویس ثابت نمی‌کند بقیه سرویس‌ها نیز درست امضا می‌کنند.
مرحله اول: یک پیام آزمایشی از سرویس موردنظر بفرستید
از همان مسیری که مشکل دارد، مثلاً صندوق شرکت یا فرم سایت، یک پیام ساده به صندوقی در سرویس دیگری که خودتان کنترل می‌کنید بفرستید. اطلاعات حساس یا پیوست واقعی مشتری لازم نیست. اگر پیام برگشت می‌خورد، متن خطای برگشتی و گزارش سرویس ارسال را نگه دارید؛ اگر رسید، مشخصات و زمان پیام را ثبت کنید.
در Gmail می‌توانید پیام دریافتی را باز کنید و از منوی سه‌نقطه کنار پاسخ، گزینه‌ای مانند Show original یا «نمایش نسخه اصلی» را انتخاب کنید. در برنامه‌های دیگر دنبال نمایش سرآیند کامل یا source پیام بگردید. نام گزینه با نسخه برنامه متفاوت است.
در بخش نتیجه احراز هویت، دنبال
dkim=pass، dkim=fail یا dkim=none بگردید:- pass: امضای مربوط در این بررسی تأیید شده است. همچنان باید دامنه امضاکننده و نتیجه DMARC را جدا ببینید؛ یک pass تضمین نمی‌کند همه ایمیل‌ها به Inbox بروند.
- none: گیرنده برای این پیام نتیجه‌ای از امضای DKIM گزارش نکرده است؛ ممکن است پیام امضا نشده یا مسیر ارسال با آنچه فکر می‌کنید متفاوت باشد.
- fail: امضایی بررسی شده ولی تأیید آن ناموفق بوده است. نبود کلید مطابق، مشکل DNS یا تغییر پیام پس از امضا از علت‌های ممکن‌اند؛ متن جزئیات همان گیرنده به تشخیص کمک می‌کند.
این نتیجه برای همان پیام و گیرنده است. سرآیندها ممکن است ایمیل، IP و شناسه‌های خصوصی داشته باشند. تصویر یا متن کامل را عمومی نکنید و هرگز کلید خصوصی یا رمز صندوق را در تیکت نفرستید.
مرحله دوم: دامنه و selector را از امضا پیدا کنید
در سرآیند پیام دنبال
کد / دستورDKIM-Signature بگردید. ممکن است چند امضا وجود داشته باشد. در هر امضا معمولاً مقادیری شبیه زیر دیده می‌شود؛ این فقط نمونه آموزشی است:DKIM-Signature: ... d=example.com; s=selector1; ...
در این مثال
کد / دستورd= دامنه امضاکننده و s= selector است. برای پیدا کردن رکورد عمومی، این دو بخش به صورت زیر کنار هم قرار می‌گیرند:selector1._domainkey.example.com
در پیام واقعی ممکن است مقدار
d یک زیردامنه و selector نامی متفاوت باشد. آن‌ها را دقیق کپی کنید؛ selector1 برای همه سرویس‌ها درست نیست. اگر چند امضا دارید، نتیجه و دامنه هر امضا را جدا بررسی کنید. برای هم‌ترازی DMARC، دامنه d= و دامنه آدرس From باید طبق سیاست و قواعد مربوط با هم سازگار باشند؛ یک DKIM pass از دامنه‌ای دیگر به‌تنهایی هم‌ترازی موردنیاز شما را ثابت نمی‌کند.اگر هیچ
DKIM-Signature در پیام آزمایشی دیده نمی‌شود، برای همان سرویس بررسی کنید امضای DKIM فعال است یا نه و پیام واقعاً از مسیر موردنظر ارسال شده است. افزودن یک رکورد تصادفی DNS باعث نمی‌شود سرویسی که امضا نمی‌کند خودبه‌خود شروع به امضا کند.مرحله سوم: رکورد عمومی DNS را پیدا کنید
در ویندوز Command Prompt را باز کنید. نام نمونه را با نام ساخته‌شده از
کد / دستورs و d واقعی جایگزین کنید:nslookup -type=TXT selector1._domainkey.example.com
این دستور از DNS تنظیم‌شده دستگاه رکورد TXT را می‌پرسد و چیزی را تغییر نمی‌دهد. در بسیاری از سرویس‌ها، پاسخ DKIM متنی با
v=DKIM1 و بخش p= است. مقدار p کلید عمومی است؛ این خروجی نباید شامل کلید خصوصی باشد. بعضی ابزارها TXT طولانی را در چند بخش گیومه‌دار نمایش می‌دهند؛ چند بخش نمایش لزوماً به معنی چند کلید مستقل نیست.برخی سرویس‌ها از شما می‌خواهند ابتدا یک CNAME برای selector بسازید تا به نامی که خودشان مدیریت می‌کنند اشاره کند. در آن حالت، علاوه بر پرس‌وجوی TXT، نام CNAME را نیز طبق راهنمای همان ارائه‌دهنده ببینید:
کد / دستورnslookup -type=CNAME selector1._domainkey.example.com
اگر مقصد CNAME همان مقدار اعلام‌شده سرویس است، گام بعد این است که پاسخ کلید مقصد و امضای یک پیام تازه را بررسی کنید. نوع رکورد مورد انتظار بین ارائه‌دهندگان فرق دارد؛ برای یک نام که قرار است CNAME باشد، رکورد دیگری را بدون توجه به قوانین DNS کنار آن نسازید. مقادیر نمونه این مقاله را در پنل DNS خود وارد نکنید.
اگر رکورد پیدا نشد یا نام آن اشتباه بود
ابتدا
d= و s= را دوباره از همان پیام تطبیق دهید. خطای تایپی در _domainkey یا استفاده از selector سرویس دیگر می‌تواند جست‌وجو را بی‌نتیجه کند. سپس در پنل ارائه‌دهنده فرستنده، نام، نوع و مقدار رکورد پیشنهادی را برای دامنه خودتان ببینید. در cPanel، بخش Email Deliverability ممکن است اطلاعات مرتبط را نشان دهد؛ در سرویس‌های دیگر مسیر و نوع رکورد متفاوت است.رکورد باید در Zone DNS فعال ثبت شود. اگر نیم‌سرورهای دامنه به سرویس دیگری اشاره می‌کنند، تغییر رکورد فقط در DNS قدیمی اثر مورد انتظار نخواهد داشت. قبل از تغییر، از رکوردهای فعلی و نام Zone نسخه یا تصویر داشته باشید و محل DNS مسئول را با مدیر دامنه تأیید کنید.
در پنل DNS ممکن است نام رکورد به‌صورت کوتاه مانند
selector1._domainkey وارد شود و پنل نام دامنه را خودش اضافه کند. اگر نام کامل را وارد کنید و پنل دوباره دامنه را اضافه کند، نام نهایی اشتباه می‌شود. پیش از ذخیره، پیش‌نمایش یا نام نهایی را بخوانید و با نام ساخته‌شده از امضای واقعی مقایسه کنید. سپس مقدار عمومی ارائه‌شده توسط همان سرویس را دقیق وارد کنید. کلید خصوصی را در DNS قرار ندهید.پس از ذخیره، پرس‌وجو را تکرار کنید. به‌روزرسانی پاسخ همه resolverها هم‌زمان نیست؛ پاسخ قبلی یا نبودن رکورد می‌تواند برای مدتی کش شده باشد. اگر در پنل درست ثبت شده ولی یک شبکه هنوز پاسخ قدیمی دارد، زمان، پاسخ و TTL را ثبت کنید و وضعیت DNS معتبر را با ارائه‌دهنده بررسی کنید.
اگر رکورد وجود دارد ولی DKIM هنوز fail است
کلید با امضاکننده هماهنگ نیست: ممکن است فرستنده با کلید خصوصی دیگری امضا کند یا DNS به کلید قدیمی اشاره کند. selector، دامنه و مقدار اعلام‌شده در پنل همان سرویس را با DNS مقایسه کنید. برای تغییر یا بازتولید کلید طبق راهنمای همان سرویس و با برنامه انجام دهید؛ عوض‌کردن ناگهانی selector یا پاک‌کردن کلید قدیمی می‌تواند پیام‌های در مسیر یا سرویس‌های دیگر را تحت تأثیر قرار دهد.
متن پیام بعد از امضا تغییر کرده است: برخی واسطه‌ها، فهرست‌های پستی یا قوانین تغییر محتوا می‌توانند امضا را نامعتبر کنند. یک پیام ساده را مستقیم به صندوق آزمایشی بفرستید و مسیر آن را با پیام ناموفق مقایسه کنید. اگر مشکل فقط پس از یک واسطه رخ می‌دهد، مسئول همان سرویس باید ترتیب تغییر پیام و امضا را بررسی کند؛ تغییر بی‌دلیل رکورد DNS همیشه راه‌حل نیست.
DNS گاهی پاسخ نمی‌دهد: نتیجه را در زمان‌های مختلف و از resolverهای مجاز بررسی کنید. خطای موقت DNS، رکورد اشتباه و پاسخ کش‌شده را از هم جدا کنید. گزارش و زمان را برای مسئول DNS بفرستید. یک
timeout به‌تنهایی ثابت نمی‌کند کلید اشتباه است.پیام امضای چند سرویس دارد: نتیجه هر امضا و دامنه
d آن را جدا بخوانید. ممکن است یک امضا درست و دیگری ناموفق باشد. برای سیاست DMARC، هم‌ترازی دامنه From با یک مسیر احراز هویت معتبر نیز مهم است؛ نتیجه یک خط را بدون دیدن بقیه به تمام پیام تعمیم ندهید.کلید خصوصی را کجا نباید ارسال کنیم؟
کلید خصوصی معمولاً در تنظیمات امن سرویس فرستنده یا سرور نگهداری می‌شود. آن را در رکورد TXT عمومی، پیام عمومی، تصویر صفحه یا تیکت عادی قرار ندهید. اگر برای بررسی از شما کلید خواسته شد، اول بپرسید آیا کلید عمومی DNS یا فقط selector و نام دامنه کافی است. در بیشتر مراحل این راهنما، همان اطلاعات عمومی و نتیجه یک پیام آزمایشی کافی‌اند.
اگر احتمال می‌دهید کلید خصوصی افشا شده، موضوع را با مدیر سرویس فوراً پیگیری کنید تا طبق راهنمای ارائه‌دهنده برنامه تغییر کلید و selector را اجرا کند. حذف ناگهانی همه رکوردهای ایمیل بدون هماهنگی می‌تواند ارسال سالم را هم مختل کند.
آزمایش نهایی برای هر مسیر ارسال
پس از اصلاح، از هر مسیر مهم، مانند صندوق کارمندان، سایت و سرویس خبرنامه، یک پیام آزمایشی جداگانه به صندوق تحت کنترل خودتان بفرستید. برای هر پیام نتیجه DKIM، دامنه امضا و selector را بخوانید و با تنظیم مربوط مقایسه کنید. اگر نتیجه مناسب شد، دریافت پیام و نتیجه DMARC را نیز جدا بررسی کنید. DKIM سالم به‌تنهایی تضمین Inbox، محتوای مناسب یا اعتبار فرستنده نیست.
زمان و نتیجه را ثبت کنید تا هنگام تغییر بعدی سرویس ایمیل بدانید کدام selector به کدام فرستنده تعلق دارد. برای شناخت شرایط ثبت دامنه نت‌آرام می‌توانید صفحه سرویس را ببینید؛ مدیریت DNS و سرویس فرستنده ممکن است جدا از محل ثبت دامنه باشند.
منابع فنی
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام