Defaults.Exposed › رفع اشکالها › Guides
DKIM «Body Hash Did Not Verify» — چه چیزی پیام شما را تغییر داد، و چطور رفع کنید (۲۰۲۶)
منتشرشده 2026-07-08
دادهها تا 2026-06-29 · روششناسی v7. دادههای سرشماری جمعی در 261 میلیون دامنه درجهبندیشده. ببینید چطور درجهبندی میکنیم.
«Body hash did not verify» به این معناست که امضای DKIM شما وقتی پیام شما را ترک کرد معتبر بود — و چیزی بعداً body پیام را بازنویسی کرد. امضا شکسته نیست؛ پیام در حین انتقال تغییر کرده. فقط 3.87٪ از دامنهها — 10,092,481 — سهگانه کامل SPF-DKIM-DMARC را تکمیل میکنند، بر اساس سرشماری Defaults.Exposed از 261,086,232 دامنه (2026-06-29).
رفع یک شکار، سپس یک تصمیم است. hopای را پیدا کنید که ایمیل شما را تغییر میدهد — یک gateway که یک سلب مسئولیت اضافه میکند، یک دستگاه که لینکها را بازنویسی میکند، یک لیست پستی که یک footer اضافه میکند. سپس بعد از آن hop امضا کنید، تغییر را متوقف کنید، یا امضا را نسبت به آن تحملپذیر کنید — به این ترتیب.
«Body hash did not verify» واقعاً به چه معناست؟
یک امضای DKIM (RFC 6376) دو hash حمل میکند: bh=، یک hash از body پیام همانطور که امضا شده، و b=، که هدرها را به علاوه آن hash body امضا میکند. تأییدکننده hash body را از پیامی که دریافت کرده دوباره محاسبه میکند؛ اگر با bh= مطابقت نداشته باشد، تأیید با رشتهای که همه در یک جعبه جستجو میچسبانند متوقف میشود — یک هدر گیرنده مثل:
Authentication-Results: …; dkim=fail (body hash did not verify)
این رشته دلیل مستند Microsoft است؛ Gmail اغلب همان تشخیص را به عنوان dkim=neutral (body hash did not verify) نشان میدهد. در هر صورت، حکم مشکل را به شدت محدود میکند. کلید DNS، انتخابگر، و پیکربندی امضای شما همه خوب هستند. رمزنگاری کارش را کرد: body بین امضا و تأیید تغییر کرد — یک خط اضافه شده، یک URL بازنویسی شده، یک کاراکتر دوباره کدگذاری شده کافی است. (یک پیام متفاوت — signature did not verify، no key for signature — یک شکست متفاوت است؛ از «امضای DKIM معتبر نیست» شروع کنید.) و فوری است چون یک امضای شکست خورده نمیتواند به DMARC یک تأیید همراستا بدهد: مگر اینکه SPF با alignment روی همان پیام تأیید شود، ایمیل کاملاً DMARC را شکست میدهد.
چه چیزی پیام شما را تغییر داد؟ مظنونان معمول
چیزی در مسیر تحویل body را بعد از مهر و موم امضاکننده ویرایش کرده. در عمل یکی از چهار چیز است:
| چه کسی آن را تغییر داد | چه چیزی را تغییر میدهند | نشانه معمول |
|---|---|---|
| Gateway خروجی / smart host (قوانین transport Exchange، Mimecast، Proofpoint، Barracuda…) | سلب مسئولیت قانونی، footer بازاریابی، یا بنر «EXTERNAL:» را بعد از اینکه سرور ایمیل قبلاً امضا کرده اضافه میکند | هر پیام در آن مسیر شکست میخورد؛ ارسالهای مستقیم که از gateway عبور نمیکنند تأیید میشوند |
| دستگاه امنیتی / محافظت از لینک | URL ها را به redirect های اسکن بازنویسی میکند، پوششهای ردیابی اضافه میکند | فقط پیامهای حاوی لینک شکست میخورند |
| لیست پستی (Google Groups، Mailman…) | یک تگ موضوع و footer لیست اضافه میکند، گاهی body را reflow میکند | فقط ایمیل ارسال شده از طریق لیست شکست میخورد |
| Forwarder / relay که MIME را دوباره کدگذاری میکند | charset را رمزگذاری میکند، خطوط را دوباره میپیچد — برای انسان نامرئی، برای hash کشنده | شکستها در یک گیرنده یا آدرس forwarding جمع میشوند |
ابتدا ردیف بولد را بررسی کنید — سرور ایمیل امضا میکند، دستگاه لبه ویرایش میکند، و هر پیام با امضایی که برای سی میلیثانیه درست بود خارج میشود.
چطور hopای که ایمیلم را تغییر میدهد پیدا کنم؟
تشخیص تفاضلی — یک مسیری که کار میکند را با مسیری که شکست میخورد مقایسه کنید:
۱. یک پیام آزمایشی مستقیم به یک صندوق پستی که در یک گیرنده بزرگ کنترل میکنید ارسال کنید (Gmail خوب کار میکند)، تا آنجا که ممکن است از chain خروجی خود عبور کنید.
۲. یک پیام دوم در مسیر شکست خورده ارسال کنید — از طریق gateway، از طریق لیست، به دامنه گیرنده آسیب دیده.
۳. خطوط Authentication-Results را در هر دو هدر کامل مقایسه کنید. ارسال مستقیم dkim=pass، مسیر شکست خورده dkim=fail (یا dkim=neutral) با body hash did not verify: تغییردهنده بین آن دو مسیر زندگی میکند.
۴. به body دریافت شده نگاه کنید: یک سلب مسئولیت، بنر، یا footer که تایپ نکردهاید؟ لینکهای بازنویسی شده به یک دامنه اسکن؟ این hop شما است، نامگذاری شده — و زنجیر Received: نشان میدهد کدام relay فقط در مسیر شکست خورده ظاهر میشود.
گزارشهای aggregate DMARC همان داستان را در مقیاس میگویند: منبعی که به طور مداوم DKIM fail با SPF pass گزارش میدهد معمولاً تغییر-در-حین-انتقال روی مسیر خودتان است، نه یک مهاجم.
چطور رفع کنم؟
۱. قبل از لمس هر چیزی، اسکن رایگان در defaults.exposed را اجرا کنید. تأیید میکند کلیدهای DKIM منتشر شده و سیاست DMARC شما سالم هستند، پس یک مشکل واقعی را debug میکنید — تغییر — نه ارواح در DNS را دنبال میکنید. صفحه رفع DKIM بررسیهای سمت رکورد را پوشش میدهد.
۲. بعد از hop تغییردهنده امضا کنید. رفع معماری صحیح: امضای DKIM را به بیرونیترین دستگاهی که پیام را لمس میکند منتقل کنید. فروشگاههای Exchange-plus-gateway باید در gateway امضا کنند (Mimecast، Proofpoint و همتایان همه آن را پشتیبانی میکنند) و امضا را در upstream غیرفعال کنند. اگر Google Workspace یا Microsoft 365 آخرین hop شما است، آنجا امضا کنید و اجازه ندهید هیچ چیزی ایمیل را بعد از آن ویرایش کند — تنظیم DKIM روی Google Workspace یا Microsoft 365 را ببینید.
۳. یا تغییر را متوقف کنید. ویرایش را از مسیر transport بیرون کنید: سلب مسئولیت در امضای client یا template به جای یک قانون transport؛ بنر «EXTERNAL:» محدود به ایمیل ورودی (برچسب زدن ایمیل خروجی خودتان به عنوان خارجی دو بار misconfiguration است)؛ ایمیل خروجی احراز هویت شده معاف از link-rewriting.
۴. از canonicalization relaxed/relaxed (c=relaxed/relaxed) استفاده کنید. canonicalization body simple روی یک خط دوباره پیچیده شده شکست میخورد؛ relaxed تغییرات فاصله و انتهای خط را تحمل میکند. صادقانه در مورد محدودیت باشید: relaxed قالببندی را میبخشد، هرگز محتوا را — یک footer اضافه شده همچنان شکست میخورد، همانطور که باید.
۵. هر دو مسیر را دوباره آزمایش کنید، سپس دوباره اسکن کنید. هر دو مسیر باید اکنون dkim=pass با دامنه شما در d= نشان دهند، و گزارش اسکن باید تمیز باشد.
آیا باید از تگ l= استفاده کنم تا DKIM محتوای اضافه شده را نادیده بگیرد؟
خیر — و به هر راهنمایی که آن را پیشنهاد میدهد مشکوک باشید. تگ l= فقط N بایت اول body را hash میکند، پس یک footer اضافه شده دیگر امضا را نمیشکند. «کار میکند» با گذاشتن انتهای پیام شما بدون امضا: هر کسی که یک پیام امضا شده قانونی دارد میتواند محتوای دلخواه اضافه کند و امضای معتبر شما همچنان روی نتیجه verify میشود. این یک سوراخ جعل در لباس یک رفع است — سوءاستفاده عملی نشان داده شده، و بعضی گیرندهها l= را دقیقاً به همین دلیل جریمه میکنند یا نادیده میگیرند. تغییر را حل کنید؛ بخشی از ایمیل خود را امضا نکنید.
لیستهای پستی چطور — میتوانم آنها را رفع کنم؟
عمدتاً، نه — و دانستن این هفتهها را صرفهجویی میکند. یک لیست که یک تگ موضوع یا footer اضافه میکند hash body شما را طراحاً خراب میکند، و شما لیست را کنترل نمیکنید. دو چیز کمک میکند:
- این باقیمانده دقیقاً همان چیزی است که rollout DMARC مرحلهبندی شده برای آن است. حرکت از
p=noneاز طریقp=quarantineبا یک ramppct=، در حالی که گزارشهای aggregate را میخوانید، به این معناست که پیامهای خراب شده لیست قرنطینه میشوند نه نابود، در حالی که تأثیر را ارزیابی میکنید — موضوع از p=none به p=reject بدون از دست دادن ایمیل قانونی. - ARC مکانیزم گیرنده است، نه شما. Authenticated Received Chain اجازه میدهد لیست اثبات کند احراز هویت هنگام ورود چه شکلی بود و گیرنده تصمیم بگیرد آیا به آن اعتماد کند. هیچ چیزی برای شما، فرستنده، برای پیکربندی وجود ندارد. لیستهای خوب اجرا شده با بازنویسی هدر From کاهش میدهند؛ لیستهای بد اجرا شده فقط ایمیل شما را خراب میکنند.
Forwarding مورد مجاور است — به طور قابل اعتمادی SPF را خراب میکند اما فقط گاهی DKIM را، که به همین دلیل DKIM همراستا پای مقاوم در برابر forwarding شما است وقتی body جان سالم به در میبرد: ایمیل forwarded شده SPF را شکست میدهد — چرا نمیتوانید آن را رفع کنید را ببینید.
چرا DKIM این قدر زیاد خراب میشود وقتی تعداد کمی از دامنهها حتی stack کامل دارند؟
چون DKIM فرزند میانی شکننده سهگانه است: SPF یک رکورد DNS ثابت است، DMARC یک بیانیه سیاست، اما DKIM باید از سفر جان سالم به در ببرد. فقط 51.84٪ از دامنههای درجهبندیشده اصلاً یک کلید DKIM قابل کشف در DNS منتشر میکنند، بر اساس سرشماری Defaults.Exposed، و فقط 10,092,481 دامنه — 3.87٪ از 261,086,232 درجهبندیشده — SPF، DKIM و یک سیاست DMARC اجرایی را با هم دارند (مدل بلوغ اتخاذ SPF نردبان را تجزیه میکند). درست انجام دادن این رفع سختترین بخش پیوستن به آن 3.87٪ است.
پرسشهای متداول
«Body hash did not verify» نشانهای است که کسی دامنه مرا جعل میکند؟
معمولاً نه — یک جعلکننده معمولاً اصلاً نمیتواند امضای DKIM شما را تولید کند، پس ایمیل آنها هیچ امضا یا no key نشان میدهد. یک hash body شکست خورده به این معناست که پیامی که واقعاً توسط زیرساخت شما امضا شده بود بعداً ویرایش شد. gateway خودتان را قبل از فرض یک مهاجم بررسی کنید.
SPF روی این پیامها تأیید میشود — آیا هنوز خوب هستم؟ فعلاً، شاید: DMARC فقط به یک تأیید همراستا نیاز دارد. اما تأیید SPF لحظهای که کسی پیام را forward کند بخار میشود، و اگر با دامنه From شما همراستا نباشد اصلاً برای DMARC اهمیتی نداشته. با فقط 3.87٪ از دامنهها که سهگانه کامل را دارند (سرشماری 2026-06-29 از 261,086,232 دامنه)، «یک پا لنگ» حالت عادی است — و قابل رفع.
آیا تغییر به canonicalization relaxed/relaxed مشکل سلب مسئولیتم را رفع میکند؟ خیر. Relaxed فقط تغییرات فاصله و خطپیچی را تحمل میکند. یک سلب مسئولیت اضافه شده یک تغییر محتوا است، و hash باید روی آن شکست بخورد — این DKIM است که درست کار میکند. نقطه امضا را جابجا کنید یا سلب مسئولیت را جابجا کنید.
شکست فقط برای دامنه یک مشتری رخ میدهد. چرا؟ طرف آنها تقریباً مطمئناً ایمیل ورودی را تغییر میدهد — یک دستگاه امنیتی که لینکها را بازنویسی یا بنرها را مهر میکند قبل از اینکه تأییدکننده آنها اجرا شود، یا یک forward داخلی که body را دوباره کدگذاری میکند. بخش تشخیص این صفحه را برای آنها ارسال کنید؛ رفع روی gateway آنهاست، نه در DNS شما.
گزارش را به صاحب ارسال کنید
اگر این را برای یک مشتری یا کارفرمایتان رفع میکنید، حلقه را با شواهد ببندید. وقتی hop تغییردهنده رفع شد، اسکن رایگان را دوباره اجرا کنید و گزارش درجهبندیشده را برای صاحب کسبوکار ارسال کنید: تاریخدار، با زبان ساده، DKIM و DMARC در یک صفحه ایستادهاند. این همان چیزی است که برای تمدید بیمه سایبری و پرسشنامه بعدی تأمینکننده نیاز دارند — اثبات اینکه ایمیل خروجی از شرکت اکنون همان ایمیلی است که دریافت میشود.
دامنهتان را بررسی کنید ← · راهنمای «امضای DKIM معتبر نیست» ← · رفع DKIM ← · چطور درجهبندی میکنیم ← · فقط دادههای جمعی. دادهها ذخیره و پردازش شده در اتحادیه اروپا.