Defaults.Exposed › رفع اشکالها › Guides
DKIM «No Key for Signature»: رفع انتخابگر و چرخش (۲۰۲۶)
منتشرشده 2026-07-08
دادهها تا 2026-06-29 · روششناسی v7. دادههای سرشماری جمعی در 261 میلیون دامنه درجهبندیشده. ببینید چطور درجهبندی میکنیم.
«No key for signature» به این معناست که گیرنده رکورد DNSای را که امضای DKIM شما به آن اشاره میکند — selector._domainkey.yourdomain — جستجو کرد و هیچ کلیدی پیدا نکرد: هرگز منتشر نشده، یا در حین چرخش حذف شده. انتخابگری را که امضاکننده شما واقعاً استفاده میکند منتشر کنید. فقط 10,092,481 دامنه — 3.87٪ — سهگانه SPF+DKIM+DMARC را تکمیل میکنند، بر اساس سرشماری Defaults.Exposed از 261,086,232 دامنه درجهبندیشده.
رفع یک رکورد DNS است که در یک هدر پیدا شده. تگهای s= و d= را از یک هدر DKIM-Signature واقعی بخوانید تا بدانید ایمیل با کدام انتخابگر امضا شده، آن رکورد دقیق را منتشر (یا تعمیر) کنید، و ترجیحاً از CNAME delegation استفاده کنید تا ارائهدهنده کلیدها را برای شما بچرخاند. سپس با runbook زیر بچرخانید — این خطا معمولاً به این معناست که کسی یک انتخابگر قدیمی را خیلی زود حذف کرده.
«dkim no key for signature» به چه معناست؟
هر امضای DKIM دو تگ دارد که به گیرنده میگوید کجا کلید عمومی را دریافت کند: d= (دامنه امضاکننده) و s= (انتخابگر). گیرنده یک نام DNS ساخته شده از آنها را جستجو میکند — s._domainkey.d — برای کلید. «No key for signature» به این معناست که آن جستجو خالی برگشت: امضا وجود دارد، اما کلیدی که نام میبرد نه.
متن در هدرهای Authentication-Results و گزارشهای aggregate DMARC ظاهر میشود — عبارت دقیق بر اساس گیرنده متفاوت است، اما دو نوع اهمیت دارند:
| رشته نتیجه (قطعه، همانطور که به طور گسترده مشاهده شده) | چه اتفاقی واقعاً افتاد | موقتی؟ |
|---|---|---|
dkim=temperror (no key for signature) | جستجوی DNS شکست خورد یا timeout شد — گیرنده اصلاً نتوانست پاسخ بگیرد | بله — retry ها اغلب تأیید میشوند؛ فقط اگر مداوم بود بررسی کنید |
dkim=permerror (no key for signature) | جستجوی DNS موفق شد و پاسخ «چنین رکوردی نیست» بود — انتخابگر واقعاً غایب است | خیر — رکورد مفقود است تا آن را منتشر کنید |
یک temperror یکباره وضع هوای DNS است. یک permerror — یا یک temperror که در طول روزها و گیرندهها تکرار میشود — به این معناست که رکوردی که امضا به آن اشاره میکند در zone شما نیست. این راهنمای آن است.
نتیجه: یک امضای غیرقابل تأیید به عنوان هیچ DKIM حساب میشود، پس DMARC به SPF تنها بازمیگردد — و SPF زیر forwarding خراب میشود. اگر امضا موجود است اما نامعتبر است نه مفقود (hash body، کلید خراب شده)، آن یک شکست متفاوت است — «امضای DKIM معتبر نیست» را ببینید.
چطور بفهمم ایمیلم با کدام انتخابگر امضا شده؟
از مستندات ارائهدهنده حدس نزنید — آن را از یک پیام واقعی بخوانید:
۱. یک پیام از سیستم آسیب دیده به یک صندوق پستی که کنترل میکنید ارسال کنید (یک آدرس Gmail خوب کار میکند).
۲. منبع خام را باز کنید («Show original» در Gmail، «View message source» در Outlook).
۳. هدر DKIM-Signature: را پیدا کنید و دو تگ را بخوانید: s= انتخابگر است، d= دامنه امضاکننده است. یک مثال: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
۴. رکوردی که گیرنده جستجو میکند s._domainkey.d است — اینجا mail2026._domainkey.yourdomain.com. خودتان بررسی کنید: dig TXT mail2026._domainkey.yourdomain.com +short. پاسخ خالی = خطا برای هر گیرندهای واقعی است.
۵. برای هر سیستم ارسالکننده تکرار کنید. یک پیام میتواند چندین امضای DKIM داشته باشد — ارائهدهنده صندوق پستی، ابزار خبرنامه، helpdesk — هر کدام با جفت s=/d= و رکورد خودشان. شکست خورده را رفع کنید، و d= آن را یادداشت کنید: فقط امضایی که d= آن با دامنه From شما مطابقت دارد به DMARC کمک میکند.
چرا رکورد انتخابگر مفقود است؟
چهار علت تقریباً همه این خطاها را تشکیل میدهند — به این ترتیب بررسی کنید:
۱. هرگز منتشر نشده. امضاکننده روشن شد (یا به طور پیشفرض روشن بود) با یک انتخابگری که هیچکس به DNS اضافه نکرد. با ابزارها و gateway های جدیدی که به طور غیرمنتظره امضا میکنند رایج است.
۲. در حین چرخش حذف شده. کسی انتخابگر قدیمی را «پاکسازی» کرد در حالی که پیامهای امضا شده با آن هنوز در حین انتقال، در صف retry، یا در انتظار forwarding بودند. آن ایمیل قبلاً با s=old امضا شده؛ حذف old._domainkey به صورت retroactive هر یک از آن پیامها را خراب میکند.
۳. رابط DNS شما یک هدف CNAME را خراب کرده. بسیاری از ارائهدهندگان از طریق CNAME delegate میکنند (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com)، و بسیاری از پانلهای DNS به صورت خاموش zone شما را به هدف اضافه میکنند — s1.domainkey.u123.esp.com.yourdomain.com را ذخیره میکند که به هیچ چیز resolve نمیشود. هدف را تأیید کنید: dig CNAME s1._domainkey.yourdomain.com +short. همین تله در طول مهاجرتهای ابزار گازمیگیرد — DKIM بعد از تغییر ابزارهای ایمیل شکست میخورد را ببینید.
۴. ارائهدهنده چرخید، zone شما نچرخید. یک کلید ارائهدهنده که به عنوان یک رکورد TXT ثابت پیست شده (به جای CNAME آنها) با چرخش برنامهریزی شده آنها یتیم میشود — امضاکننده به یک انتخابگری میرود که شما هرگز منتشر نکردید. فقط 51.84٪ از 261 میلیون دامنه در سرشماری یک کلید DKIM قابل کشف در زمان اسکن ارائه میدهند (دادهها تا 2026-06-29).
چطور «no key for signature» را رفع کنم؟
۱. قبل از لمس DNS، اسکن رایگان در defaults.exposed را اجرا کنید. رکوردهای DKIM، SPF و DMARC زنده شما را میخواند و نشان میدهد گیرندهها واقعاً چه میبینند — از جمله اینکه آیا انتخابگر resolve میشود و آیا یک هدف CNAME خراب شده.
۲. انتخابگری را که امضاکننده واقعاً استفاده میکند منتشر کنید — مقدار s= از هدر، نه آنچه در یک runbook قدیمی است. رکورد را از کنسول مدیریت ارائهدهنده دریافت کنید (تنظیم DKIM روی Google Workspace · تنظیم DKIM روی Microsoft 365) و آن را دقیقاً در s._domainkey.yourdomain.com اضافه کنید.
۳. CNAME delegation را به جای پیست کردن یک کلید TXT ترجیح دهید. اگر ارائهدهنده CNAME های DKIM ارائه میدهد، از آنها استفاده کنید: کلید در zone آنها زندگی میکند، پس آنها آن را بدون اینکه شما دوباره DNS را لمس کنید میچرخانند — علت ۴ غیرممکن میشود. پلتفرمهای خبرنامه تقریباً همه به این شکل کار میکنند؛ ایمیلهای Mailchimp/Brevo/Klaviyo که DMARC شکست میخورند را ببینید.
۴. از خارج از پانل تأیید کنید. dig TXT s._domainkey.yourdomain.com +short (یا dig CNAME … برای انتخابگرهای delegate شده) از یک ماشین خارج از شبکه. پانل که رکورد را نشان میدهد هیچ چیز را اثبات نمیکند اگر zone چیز دیگری سرو کند.
۵. دوباره اسکن کنید و پیام آزمایشی را دوباره ارسال کنید. Authentication-Results باید اکنون dkim=pass بخواند. سپس هر چیز دیگری که اسکن پرچم میزند را در صفحه رفع DKIM کار کنید — یک امضای تأیید شده که با دامنه From شما همراستا نباشد همچنان DMARC را شکست میدهد.
چطور کلیدهای DKIM را بدون ایجاد این خطا بچرخانم؟
چرخش جایی است که تنظیمات کارآمد خراب میشوند. قانون که از آن جلوگیری میکند: یک انتخابگر فقط بعد از اینکه آخرین پیام امضا شده با آن تخلیه شد حذف میشود — هرگز در cutover نه. ایمیل امضا شده بیشتر از آنچه فکر میکنید زندگی میکند: صفهای retry برای روزها اجرا میشوند، و پیامهای forwarded هر بار که جابجا میشوند دوباره تأیید میشوند.
| گام | عمل | Gate قبل از گام بعدی |
|---|---|---|
| ۱. اضافه | انتخابگر جدید را (s2._domainkey…) در کنار قدیمی منتشر کنید | dig تأیید میکند از خارج resolve میشود |
| ۲. تغییر | امضاکننده را به انتخابگر جدید هدایت کنید | پیام آزمایشی s=s2 و dkim=pass نشان میدهد |
| ۳. صبر | انتخابگر قدیمی را در حالی که ترافیک در پرواز، در صف و forwarded تخلیه میشود منتشر نگه دارید | ≥ ۷ روز؛ گزارشهای aggregate DMARC را تماشا کنید تا انتخابگر قدیمی دیگر ظاهر نشود |
| ۴. بازنشستگی | کلید قدیمی را حذف کنید — یا بهتر، آن را با یک تگ p= خالی دوباره منتشر کنید: «بازنشسته»، نه «هرگز وجود نداشته» | هرگز در cutover این را شروع نکنید — حذف زودهنگام علت #۱ «no key for signature» است |
با CNAME delegation، ارائهدهنده این دقیقاً همین runbook را داخل zone خودش اجرا میکند و شما هرگز آن را نمیبینید — قویترین استدلال برای delegation.
پرسشهای متداول
«No key for signature» یک temperror است یا یک permerror؟
هر دو رشته وجود دارند: temperror یک جستجوی DNS است که شکست خورد یا timeout شد — موقتی، اغلب در retry رفع میشود — در حالی که permerror به این معناست که DNS «چنین رکوردی نیست» پاسخ داد. یک temperror که در گیرندهها تکرار میشود معمولاً یک رکورد واقعاً مفقود نیز است. با dig بررسی کنید و به پاسخ اعتماد کنید، نه به برچسب.
آیا این خطا به این معناست که کسی دامنه مرا جعل میکند؟ خیر — یک جعلکننده با انتخابگر شما امضا نمیکرد. به این معناست که ایمیل خودتان یک امضا حمل میکند که گیرندهها نمیتوانند تأیید کنند، پس به عنوان امضا نشده حساب میشود و DMARC به SPF تنها تکیه میکند. احراز هویت کامل و همراستا نادر است: فقط 10,092,481 از 261,086,232 دامنه (3.87٪) سهگانه SPF+DKIM+DMARC را در سرشماری Defaults.Exposed تکمیل کردند (دادهها تا 2026-06-29).
آیا میتوانم فقط انتخابگر قدیمی را بعد از کار کردن جدید حذف کنم؟
نه فوری. پیامهای امضا شده با آن هنوز در صفهای retry و مسیرهای forwarding هستند؛ حذف کلید آنها را retroactively خراب میکند. رکورد قدیمی را حداقل یک هفته نگه دارید، گزارشهای DMARC را تماشا کنید تا انتخابگر قدیمی دیگر ظاهر نشود، سپس بازنشسته کنید — ترجیحاً با یک p= خالی به جای حذف.
بررسیکننده ارائهدهنده میگوید DKIM پیکربندی شده، اما گیرندهها همچنان no key گزارش میدهند. چطور؟
تقریباً همیشه تله هدف CNAME است: پانل DNS شما zone را به هدف اضافه کرده (…esp.com.yourdomain.com)، پس رکورد وجود دارد اما به هیچجا اشاره نمیکند. dig CNAME selector._domainkey.yourdomain.com +short هدف ذخیره شده را به صورت verbatim نشان میدهد — کاراکتر به کاراکتر با آنچه ارائهدهنده خواسته مقایسه کنید.
گزارش را به صاحب ارسال کنید
اگر این را برای یک مشتری یا کارفرمایتان رفع میکنید، حلقه را با شواهد ببندید. اسکن رایگان را وقتی انتخابگر resolve میشود دوباره اجرا کنید و گزارش درجهبندیشده را برای صاحب کسبوکار ارسال کنید: تاریخدار، با زبان ساده، DKIM اکنون تأیید میکند. این همان چیزی است که برای تمدید بیمه سایبری و پرسشنامه امنیتی بعدی تأمینکننده نیاز دارند — اثبات یک کنترل کارآمد، نه فقط یک تیکت بسته شده.
DKIM خود را رایگان بررسی کنید
ببینید انتخابگرهای شما resolve میشوند — و دقیقاً چه چیزی باید رفع شود — به صورت خصوصی و فقط برای صاحب.
دامنهتان را بررسی کنید ← · «امضای DKIM معتبر نیست» ← · رفع DKIM ← · تنظیم DKIM روی Google Workspace ← · فقط دادههای جمعی. دادهها ذخیره و پردازش شده در اتحادیه اروپا.