Defaults.Exposed › رفع اشکالها › Guides
«امضای DKIM معتبر نیست» — علتها، به ترتیبی که باید بررسی شوند (۲۰۲۶)
منتشرشده 2026-07-08
دادهها تا 2026-06-29 · روششناسی v7. دادههای سرشماری جمعی در 261 میلیون دامنه درجهبندیشده. ببینید چطور درجهبندی میکنیم.
«امضای DKIM معتبر نیست» پنج علت رایج دارد، که به ترتیب بهترین بررسی میشوند: محتوای تغییر یافته در حین انتقال، یک رکورد کلید کوتاه شده، یک کلید منتشر شده که با امضاکننده مطابقت ندارد، انتخابگر اشتباه، و canonicalization شکننده. فقط 10,092,481 از 261,086,232 دامنه درجهبندیشده (3.87٪) سهگانه کامل SPF + DKIM + DMARC-اجرایی را دارند، بر اساس سرشماری Defaults.Exposed (2026-06-29).
ترتیب رفع اهمیت دارد چون رایجترین علت اصلاً در DNS شما نیست. ابتدا بررسی کنید چه چیزی پیام را در حین انتقال تغییر داده، سپس به سمت داخل کار کنید: یکپارچگی رکورد کلید، اینکه آیا با آنچه سرور ایمیل شما واقعاً با آن امضا میکند مطابقت دارد، انتخابگر، و در نهایت تنظیمات امضا. بیشتر امضاهای نامعتبر در گام یک یا دو رفع میشوند.
«امضای DKIM معتبر نیست» واقعاً به چه معناست؟
هر پیام DKIM-امضا شده یک هدر DKIM-Signature دارد که یک دامنه (d=)، یک انتخابگر (s=)، یک hash از body پیام (bh=)، و یک امضای رمزنگاری روی hash body به علاوه هدرهای انتخاب شده (b=) نام میبرد. گیرنده کلید عمومی شما را از DNS در <selector>._domainkey.<domain> دریافت میکند، هر دو hash را دوباره محاسبه میکند، و امضا را بررسی میکند (RFC 6376). «امضا معتبر نیست» اصطلاح بررسیکننده و هدر برای این است: آن تأیید اجرا شد و شکست خورد — کلید پیدا شد، اما ریاضیات درست در نیامد.
آن جمله آخر طلای تشخیصی است. یک تأییدکننده که نمیتواند کلید شما را پیدا کند چیز متفاوتی میگوید — معمولاً یک هدر مثل dkim=fail (no key for signature) — و این یک مشکل انتخابگر است، که در DKIM «no key for signature» — رفع انتخابگر و چرخش پوشش داده شده است. و یک تأییدکننده که یک hash body متفاوت دوباره محاسبه میکند معمولاً صریحاً میگوید: body hash did not verify — Microsoft آن را به عنوان dkim=fail (body hash did not verify) گزارش میدهد، در حالی که Gmail اغلب همان تشخیص را به عنوان dkim=neutral (body hash did not verify) نشان میدهد. در هر صورت به تغییر محتوا اشاره میکند، که در «body hash did not verify» — چه چیزی پیام شما را تغییر داد پوشش داده شده است. متن دقیق را در هدر Authentication-Results قبل از لمس هر چیزی بخوانید: به شما میگوید کدام یک از پنج علت را دارید.
درست انجام دادن این نادر است: فقط 51.84٪ از دامنههای درجهبندیشده اصلاً یک کلید DKIM قابل کشف در DNS منتشر میکنند، بر اساس سرشماری Defaults.Exposed، و فقط 3.87٪ از 261 میلیون دامنه درجهبندیشده SPF، DKIM و یک سیاست DMARC اجرایی را ترکیب میکنند — پیکربندیای که قوانین فرستنده انبوه اکنون فرض میکنند. تصویر مرحله به مرحله در مدل بلوغ اتخاذ SPF است.
پنج علت، به ترتیب، چیستند؟
| # | علت | نشانه | رفع |
|---|---|---|---|
| ۱ | محتوای تغییر یافته در حین انتقال — footer های gateway، سلب مسئولیتهای قانونی، تگهای موضوع لیستهای پستی | body hash did not verify در Authentication-Results؛ ایمیل خارجی شکست میخورد، ایمیل مستقیم تأیید میشود | بعد از تغییر امضا کنید، یا دیگر تغییر ندهید — راهنمای body-hash را ببینید |
| ۲ | کلید طولانی کوتاه شده یا خراب شده | p= منتشر شده به طور مشهود از کلیدی که ایجاد کردید کوتاهتر است؛ هر گیرندهای شکست میخورد | کلید 2048-bit را به عنوان رشتههای TXT به درستی تقسیم شده دوباره منتشر کنید |
| ۳ | کلید منتشر شده با امضاکننده مطابقت ندارد | شکستها درست بعد از یک چرخش، مهاجرت یا تغییر ارائهدهنده شروع میشوند | رکورد فعلی را از کنسول مدیریت ارائهدهنده دوباره کپی کنید. ترجیحاً از CNAME delegation استفاده کنید |
| ۴ | انتخابگر اشتباه یا مفقود | no key for signature — جستجو خودش شکست میخورد | انتخابگری که امضاکننده واقعاً استفاده میکند را منتشر کنید — راهنمای انتخابگر را ببینید |
| ۵ | canonicalization شکننده یا یک تگ l= | شکستهای متناوب روی پیامهای ساده فرمت شده مجدد | c=relaxed/relaxed؛ l= را کاملاً حذف کنید |
علت ۱ بولد است چون امضاهای روی پیامهایی که کاملاً امضا شده بودند را خراب میکند. یک gateway امنیتی یک سلب مسئولیت اضافه میکند، یک footer compliance بعد از امضا مهر میخورد، یک لیست پستی [listname] به موضوع اضافه میکند — body یا هدرهای امضا شده تغییر میکنند، hash ها دیگر مطابقت ندارند، و امضا بدون هیچ نقصی از DNS شما نامعتبر است. اگر شکستها با ایمیل عبور کرده از gateway، لیست، یا hop آرشیو همبستگی دارند، از آنجا شروع کنید.
چطور «امضای DKIM معتبر نیست» را رفع کنم؟
۱. قبل از لمس DNS، اسکن رایگان در defaults.exposed را اجرا کنید. نشان میدهد آیا رکورد کلید منتشر شده موجود، خوشفرمت و کامل است — در یک گام «DNS شما شکسته است» (علتهای ۲–۴) را از «DNS شما خوب است، پیام تغییر میکند» (علت ۱) جدا میکند.
۲. هدر Authentication-Results یک پیام شکست خورده را بخوانید. body hash did not verify → علت ۱، به راهنمای body-hash بروید — مظنونان معمول footer های gateway و سلب مسئولیتها هستند، و رفع امضا بعد از تغییر است. no key for signature → علت ۴، به راهنمای انتخابگر بروید. یک شکست امضای ساده → ادامه دهید.
۳. کلید منتشر شده را برای کوتاه شدن بررسی کنید. <selector>._domainkey.<yourdomain> را به عنوان TXT جستجو کنید (dig TXT selector._domainkey.example.com). یک کلید عمومی RSA 2048-bit از محدودیت ۲۵۵ کاراکتری یک رشته TXT تجاوز میکند، پس باید به عنوان چندین رشته نقلقول شده منتشر شود که گیرندهها به هم وصل میکنند — و رابطهای وب ارائهدهندگان DNS به خاطر کوتاه کردن paste به صورت خاموش، خراب کردن تقسیم، یا تزریق فاصله و نقلقول به مقدار p= بدنام هستند. کاراکتر به کاراکتر با کلیدی که امضاکننده ایجاد کرده مقایسه کنید؛ راهنماهای تنظیم DKIM ما ایرادات خاص هر ارائهدهنده را پوشش میدهند.
۴. تأیید کنید کلید منتشر شده با امضاکننده مطابقت دارد. بعد از یک چرخش کلید، مهاجرت ارائهدهنده، یا اتصال مجدد ESP، رایج است که امضاکننده یک کلید خصوصی جدید داشته باشد در حالی که DNS همچنان کلید عمومی قدیمی را سرو میکند — هر امضایی در مقابل کلید اشتباه تأیید میشود و شکست میخورد. رکورد فعلی را از کنسول مدیریت ارائهدهنده دوباره کپی کنید. بهتر: جایی که ارائهدهنده CNAME delegation ارائه میدهد، از آن استفاده کنید — ارائهدهنده کلیدها را از طرف خودش میچرخاند و کل این کلاس از شکست ناپدید میشود. و یک انتخابگر قدیمی را تا وقتی ترافیک امضا شده با آن تخلیه نشده حذف نکنید.
۵. تنظیمات امضا را رفع کنید، نه فقط رکورد را. canonicalization را روی c=relaxed/relaxed تنظیم کنید، که تحمل میکند فاصلهگذاری مجدد و header re-folding که سرورهای میانی به صورت قانونی انجام میدهند؛ canonicalization simple روی تغییراتی که انسان حتی نمیتواند ببیند شکست میخورد. و از تگ l= body-length استفاده نکنید: قرار بود به footer ها اجازه عبور دهد، اما به هر کسی اجازه میدهد محتوا را به پیام امضا شده شما اضافه کند بدون خراب کردن امضا — یک بردار حمله واقعی — و همچنان از بیشتر تغییرات gateway جان سالم به در نمیبرد. هیچ l= نه ایمنتر و نه قابل اعتمادتر است.
۶. دوباره اسکن کنید، سپس alignment را بررسی کنید. یک امضای معتبر فقط به DMARC کمک میکند اگر دامنه d= با دامنه From شما همراستا باشد — امضایی که به عنوان d=yourcompany.gappssmtp.com validate میشود DKIM را تأیید میکند و همچنان DMARC را شکست میدهد. اگر این شما هستید، تله امضای پیشفرض را ببینید، سپس هر چیز دیگری که اسکن پرچم میزند را در صفحه رفع DKIM کار کنید.
پرسشهای متداول
«امضای DKIM معتبر نیست» مثل «body hash did not verify» است؟ پیام body-hash یک زیرحالت خاص است: body بعد از امضا تغییر کرد (footer ها، سلب مسئولیتها، بازنویسیهای لیست). «امضا معتبر نیست» حکم چتری برای هر تأیید شکست خورده است، از جمله کلیدهای بد و تغییرات هدر — به همین دلیل گام ۲ بالا خواندن هدر است، و به همین دلیل حالت body-hash راهنمای خودش را دارد.
آیا یک امضای DKIM نامعتبر به این معناست که ایمیل من ریجکت میشود؟ به تنهایی نه — گیرندهها با یک امضای شکسته مثل یک امضای مفقود رفتار میکنند. آسیب از طریق DMARC میرسد: اگر SPF هم با alignment تأیید نشود، پیام DMARC را شکست میدهد و سیاست منتشر شده شما اعمال میشود. تا سرشماری 2026-06-29، فقط 3.87٪ از 261,086,232 دامنه درجهبندیشده SPF، DKIM و یک سیاست DMARC اجرایی را با هم دارند — اما Gmail و Microsoft اکنون دقیقاً همین را از فرستندهها انتظار دارند، پس یک پای DKIM شکسته حتی قبل از ریجکت تحویلپذیری را هزینه میکند.
آیا باید از کلید DKIM 1024-bit یا 2048-bit استفاده کنم؟ 2048-bit — کلیدهای 1024-bit زیر توصیههای رمزنگاری فعلی هستند و بعضی گیرندهها آنها را پایینتر رتبهبندی میکنند. مشکل کاملاً عملیاتی است: یک کلید 2048-bit در یک رشته TXT 255 کاراکتری جا نمیشود، پس باید به درستی تقسیم شود (علت ۲ بالا). CNAME delegation به ارائهدهنده کل مشکل تقسیم را کنار میگذارد.
DKIM در یک بررسیکننده تأیید میشود اما DMARC همچنان شکست میخورد — چطور؟
تقریباً مطمئناً alignment: امضا validate میشود، اما دامنه d= آن (مثلاً yourcompany.gappssmtp.com یا yourtenant.onmicrosoft.com) با دامنه From شما مطابقت ندارد، پس DMARC نمیتواند از آن استفاده کند. امضای دامنه سفارشی ارائهدهندهتان را فعال کنید — راهنمای کامل در راهنمای تله امضای پیشفرض است.
آیا میتوانم فقط DKIM را خاموش کنم اگر همیشه شکست میخورد؟ خیر — از زمان الزامات فرستنده انبوه ۲۰۲۴، Gmail و Yahoo برای فرستندههای انبوه DKIM را الزامی میدانند، و یک سیاست DMARC اجرایی واقعبینانه به DKIM نیاز دارد چون SPF به تنهایی زیر forwarding خراب میشود. امضا را رفع کنید؛ علتهای بالا همه در یک بعدازظهر قابل رفع هستند.
گزارش را به صاحب ارسال کنید
اگر این را برای یک مشتری یا کارفرمایتان رفع میکنید، حلقه را با شواهد ببندید. اسکن رایگان را بعد از تغییراتتان دوباره اجرا کنید و گزارش درجهبندیشده را برای صاحب کسبوکار ارسال کنید: تاریخدار، با زبان ساده، DKIM سبز نشان میدهد. این همان چیزی است که برای تمدید بیمه سایبری و پرسشنامه امنیتی بعدی تأمینکننده نیاز دارند — تفاوت بین «یک چیز DNS رفع کردم» و یک قبلوبعد مستند که میگوید دامنه ایمیلش را احراز هویت میکند.
دامنهتان را بررسی کنید ← · راهنمای «Body hash did not verify» ← · رفع DKIM ← · چطور درجهبندی میکنیم ← · فقط دادههای جمعی. دادهها ذخیره و پردازش شده در اتحادیه اروپا.