DKIM 'বডি হ্যাশ যাচাই হয়নি' — আপনার বার্তা কী পরিবর্তন করেছে, এবং কীভাবে ঠিক করবেন (২০২৬)

প্রকাশিত 2026-07-08

2026-06-29 তারিখের তথ্য · পদ্ধতি v7। 261 মিলিয়ন গ্রেডকৃত ডোমেইন জুড়ে সমন্বিত জনগণনা তথ্য। দেখুন আমরা কীভাবে গ্রেড করি।

“বডি হ্যাশ যাচাই হয়নি” মানে আপনার DKIM স্বাক্ষর আপনার কাছ থেকে বার্তা যাওয়ার সময় বৈধ ছিল — এবং তারপরে কিছু বার্তার বডি পুনর্লিখন করেছে। স্বাক্ষর ভাঙেনি; বার্তাটি ট্রানজিটে পরিবর্তিত হয়েছিল। Defaults.Exposed জনগণনায় 261,086,232 ডোমেইনের (2026-06-29) মাত্র 3.87% ডোমেইন — 10,092,481 — সম্পূর্ণ SPF-DKIM-DMARC ত্রয়ী সম্পন্ন করে।

সমাধান হল একটি অনুসন্ধান, তারপর একটি সিদ্ধান্ত। সেই হপ খুঁজুন যা আপনার মেইল পরিবর্তন করে — একটি দাবিত্যাগ যোগ করা গেটওয়ে, লিঙ্ক পুনর্লিখন করা একটি যন্ত্রপাতি, একটি ফুটার যোগ করা একটি মেইলিং তালিকা। তারপর সেই হপের পরে স্বাক্ষর করুন, পরিবর্তন বন্ধ করুন, অথবা এটির প্রতি স্বাক্ষর সহনশীল করুন — সেই ক্রমে।

“বডি হ্যাশ যাচাই হয়নি” আসলে কী মানে?

একটি DKIM স্বাক্ষর (RFC 6376) দুটি হ্যাশ বহন করে: bh=, স্বাক্ষর করার সময় বার্তার বডির হ্যাশ, এবং b=, যা বডি হ্যাশ এবং হেডারগুলি স্বাক্ষর করে। যাচাইকর্তা প্রাপ্ত বার্তা থেকে বডি হ্যাশ পুনরায় গণনা করে; যদি এটি bh=-এর সাথে মেলে না, তাহলে যাচাই বন্ধ হয় — একটি রিসিভার হেডার যেমন:

Authentication-Results: …; dkim=fail (body hash did not verify)

এটি Microsoft-এর নথিভুক্ত কারণ স্ট্রিং; Gmail প্রায়ই একই ডায়াগনস্টিক dkim=neutral (body hash did not verify) হিসেবে রেন্ডার করে। যেভাবেই হোক, রায় সমস্যাটিকে ব্যাপকভাবে সংকুচিত করে। আপনার DNS কী, সিলেক্টর এবং স্বাক্ষর কনফিগারেশন সবই ঠিক আছে। ক্রিপ্টোগ্রাফি তার কাজ করেছে: স্বাক্ষর এবং যাচাইয়ের মধ্যে বডি পরিবর্তিত হয়েছে — একটি যুক্ত লাইন, একটি পুনর্লিখিত URL, একটি পুনরায়-এনকোড করা অক্ষর যথেষ্ট। (একটি ভিন্ন বার্তা — signature did not verify, no key for signature — একটি ভিন্ন ব্যর্থতা মানে; শুরু করুন “DKIM signature not valid”।) এবং এটি জরুরি কারণ একটি ব্যর্থ স্বাক্ষর DMARC-কে একটি অ্যালাইনড পাস দিতে পারে না: যদি না SPF অ্যালাইনমেন্ট সহ একই বার্তায় পাস করে, তাহলে মেইল DMARC সম্পূর্ণ ব্যর্থ করে।

আপনার বার্তা কী পরিবর্তন করেছে? সাধারণ সন্দেহভাজনরা

ডেলিভারি পথে কিছু আপনার সাইনার সিল করার পরে বডি সম্পাদনা করেছে। বাস্তবে এটি চারটির মধ্যে একটি:

কে পরিবর্তন করেছে	তারা কী পরিবর্তন করে	সাধারণ চিহ্ন
আউটবাউন্ড গেটওয়ে / স্মার্ট হোস্ট (Exchange ট্রান্সপোর্ট নিয়ম, Mimecast, Proofpoint, Barracuda…)	মেইল সার্ভার ইতিমধ্যেই স্বাক্ষর করার পরে আইনি দাবিত্যাগ, মার্কেটিং ফুটার বা “EXTERNAL:” ব্যানার যোগ করে	সেই রুটের প্রতিটি বার্তা ব্যর্থ; গেটওয়ে বাইপাস করে সরাসরি প্রেরণ পাস করে
নিরাপত্তা যন্ত্রপাতি / লিঙ্ক সুরক্ষা	URL গুলি স্ক্যানিং রিডাইরেক্টে পুনর্লিখন করে, ট্র্যাকিং র‍্যাপার যোগ করে	শুধুমাত্র লিঙ্ক ধারণকারী বার্তা ব্যর্থ হয়
মেইলিং তালিকা (Google Groups, Mailman…)	একটি বিষয় ট্যাগ এবং তালিকা ফুটার যোগ করে, কখনো কখনো বডি রিফ্লো করে	শুধুমাত্র তালিকার মাধ্যমে পাঠানো মেইল ব্যর্থ হয়
ফরওয়ার্ডার / রিলে MIME পুনরায় এনকোড করছে	চারসেট ট্রান্সকোড করে, লাইন পুনরায় র‍্যাপ করে — একজন মানুষের কাছে অদৃশ্য, একটি হ্যাশের জন্য মারাত্মক	ব্যর্থতা একটি প্রাপক বা ফরওয়ার্ডিং ঠিকানায় ক্লাস্টার করে

প্রথমে বোল্ড সারি পরীক্ষা করুন — মেইল সার্ভার স্বাক্ষর করে, এজ ডিভাইস সম্পাদনা করে এবং প্রতিটি বার্তা ত্রিশ মিলিসেকেন্ডের জন্য সত্য ছিল এমন একটি স্বাক্ষর নিয়ে চলে যায়।

আমি কীভাবে আমার মেইল পরিবর্তন করছে সেই হপ খুঁজব?

ডিফারেনশিয়াল ডায়াগনোসিস — যে পথ কাজ করে তার সাথে ব্যর্থ হয় সেই পথ তুলনা করুন:

আপনার নিয়ন্ত্রণে একটি মেইলবক্সে (Gmail ভালো কাজ করে) একটি সরাসরি পরীক্ষা বার্তা পাঠান, আপনার আউটবাউন্ড চেইনের যতটা সম্ভব বাইপাস করে।
ব্যর্থ পথের মাধ্যমে একটি দ্বিতীয় বার্তা পাঠান — গেটওয়ের মাধ্যমে, তালিকার মাধ্যমে, প্রভাবিত প্রাপকের ডোমেইনে।
উভয় সম্পূর্ণ হেডারে Authentication-Results লাইনগুলি তুলনা করুন। সরাসরি প্রেরণ dkim=pass, ব্যর্থ পথ dkim=fail (বা dkim=neutral) সহ body hash did not verify: পরিবর্তনকারী সেই দুটি রুটের মধ্যে থাকে।
প্রাপ্ত বডি দেখুন: একটি দাবিত্যাগ, ব্যানার বা ফুটার যা আপনি টাইপ করেননি? একটি স্ক্যানিং ডোমেইনে পুনর্লিখিত লিঙ্ক? এটাই আপনার হপ, নামকৃত — এবং Received: চেইন দেখায় কোন রিলে শুধুমাত্র ব্যর্থ পথে দেখা যায়।

আপনার DMARC সমন্বয় রিপোর্টগুলি স্কেলে একই গল্প বলে: একটি উৎস ধারাবাহিকভাবে SPF পাস সহ DKIM ব্যর্থ রিপোর্ট করছে সাধারণত আপনার নিজের রুটে ট্রানজিট-পরিবর্তন, কোনো আক্রমণকারী নয়।

আমি এটি কীভাবে ঠিক করব?

কিছু স্পর্শ করার আগে defaults.exposed এ বিনামূল্যে স্ক্যান চালান। এটি নিশ্চিত করে আপনার প্রকাশিত DKIM কী এবং DMARC নীতি সঠিক, তাই আপনি একটি আসল সমস্যা ডিবাগ করছেন — পরিবর্তন — DNS-এ ভূতের পিছনে ছুটছেন না। fix DKIM পৃষ্ঠা রেকর্ড-পাশের চেকগুলি কভার করে।
পরিবর্তনকারী হপের পরে স্বাক্ষর করুন। স্থপতিগতভাবে সঠিক সমাধান: DKIM স্বাক্ষর বার্তা স্পর্শ করা সবচেয়ে বাইরের ডিভাইসে নিয়ে যান। Exchange-প্লাস-গেটওয়ে শপগুলি গেটওয়েতে স্বাক্ষর করা উচিত (Mimecast, Proofpoint এবং সমকক্ষরা সবই এটি সমর্থন করে) এবং আপস্ট্রিম স্বাক্ষর অক্ষম করা উচিত। যদি Google Workspace বা Microsoft 365 আপনার শেষ হপ হয়, সেখানে স্বাক্ষর করুন এবং পরে মেইল সম্পাদনা না করতে দিন — দেখুন Google Workspace-এ DKIM সেটআপ করুন বা Microsoft 365।
অথবা পরিবর্তন বন্ধ করুন। ট্রান্সপোর্ট পথ থেকে সম্পাদনা সরিয়ে দিন: একটি ট্রান্সপোর্ট নিয়মের পরিবর্তে ক্লায়েন্ট স্বাক্ষর বা টেমপ্লেটে দাবিত্যাগ; “EXTERNAL:” ব্যানার শুধুমাত্র ইনবাউন্ড মেইলে স্কোপ করা (আপনার নিজের আউটবাউন্ড মেইলকে বাহ্যিক হিসেবে ট্যাগ করা দুইবার ভুল কনফিগারেশন); প্রমাণিত আউটবাউন্ড মেইল লিঙ্ক-পুনর্লিখন থেকে ছাড় দেওয়া।
relaxed/relaxed ক্যানোনিকালাইজেশন (c=relaxed/relaxed) ব্যবহার করুন। simple বডি ক্যানোনিকালাইজেশন একটি একক পুনর্র‍্যাপড লাইনে ব্যর্থ হয়; relaxed হোয়াইটস্পেস এবং লাইন-এন্ডিং পরিবর্তন সহ্য করে। সীমা সম্পর্কে সৎ থাকুন: relaxed ফর্ম্যাটিং ক্ষমা করে, কখনো বিষয়বস্তু নয় — একটি যুক্ত ফুটার এখনও ব্যর্থ হবে, যেমন হওয়া উচিত।
উভয় পথ পুনরায় পরীক্ষা করুন, তারপর পুনরায় স্ক্যান করুন। উভয় রুট এখন আপনার ডোমেইন d=-এ সহ dkim=pass দেখানো উচিত, এবং স্ক্যান রিপোর্ট পরিষ্কার হওয়া উচিত।

DKIM-কে যুক্ত বিষয়বস্তু উপেক্ষা করতে l= ট্যাগ ব্যবহার করা কি উচিত?

না — এবং যে কোনো গাইড এটি পরামর্শ দেয় সে সম্পর্কে সন্দেহী হন। l= ট্যাগ শুধুমাত্র বডির প্রথম N বাইট হ্যাশ করে, তাই একটি যুক্ত ফুটার আর স্বাক্ষর ভাঙে না। এটি আপনার বার্তার শেষটি অস্বাক্ষরিত রেখে “কাজ করে”: যে কেউ একটি বৈধ স্বাক্ষরিত বার্তা ধরে যেকোনো বিষয়বস্তু যোগ করতে পারে এবং আপনার বৈধ স্বাক্ষর এখনও ফলাফলের উপর যাচাই করে। এটি একটি সমাধানের পোশাকে একটি স্পুফিং ছিদ্র — ব্যবহারিক অপব্যবহার প্রদর্শিত হয়েছে, এবং কিছু রিসিভার ঠিক এই কারণে l= শাস্তি দেয় বা উপেক্ষা করে। পরিবর্তন সমাধান করুন; আপনার মেইলের অংশ অস্বাক্ষরিত রাখবেন না।

মেইলিং তালিকার ক্ষেত্রে কী করব — সেগুলো কি ঠিক করতে পারি?

বেশিরভাগ, না — এবং তা জানা আপনার সপ্তাহ বাঁচায়। একটি তালিকা যা একটি বিষয় ট্যাগ বা ফুটার যোগ করে ডিজাইন অনুযায়ী আপনার বডি হ্যাশ ভাঙে, এবং আপনি তালিকা নিয়ন্ত্রণ করেন না। দুটি জিনিস সাহায্য করে:

এই অবশিষ্টাংশ ঠিক কারণেই DMARC রোলআউট পর্যায়ক্রমিক। p=none থেকে pct= রamp সহ p=quarantine-এ যাওয়া, সমন্বয় রিপোর্ট পড়ার সময়, মানে তালিকা-বিকৃত বার্তাগুলি ধ্বংস হওয়ার পরিবর্তে কোয়ারেন্টাইন হয় যখন আপনি প্রভাব মূল্যায়ন করেন — p=none থেকে p=reject-এ বৈধ ইমেইল না হারিয়ে এর বিষয়।
ARC রিসিভারের মেকানিজম, আপনার নয়। Authenticated Received Chain তালিকাকে আগমনের সময় প্রমাণীকরণ কেমন দেখাচ্ছিল তা প্রত্যয়ন করতে এবং রিসিভারকে সিদ্ধান্ত নিতে দেয় বিশ্বাস করবে কিনা। আপনার, প্রেরকের, কনফিগার করার কিছু নেই। ভালোভাবে পরিচালিত তালিকাগুলি From হেডার পুনর্লিখন দ্বারা হ্রাস করে; খারাপভাবে পরিচালিতগুলি আপনার মেইল ভেঙে দেয়।

ফরওয়ার্ডিং সংলগ্ন কেস — এটি নির্ভরযোগ্যভাবে SPF ভাঙে কিন্তু শুধুমাত্র কখনো কখনো DKIM, যে কারণে অ্যালাইনড DKIM হল আপনার ফরওয়ার্ডিং-প্রমাণ পা যখন বডি বেঁচে থাকে: দেখুন ফরওয়ার্ড করা ইমেইল SPF ব্যর্থ করে — কেন আপনি এটি ঠিক করতে পারবেন না।

এত কম ডোমেইনের সম্পূর্ণ স্ট্যাক থাকলে DKIM কেন এত ঘন ঘন ভাঙে?

কারণ DKIM ত্রয়ীর ভঙ্গুর মধ্যের সন্তান: SPF একটি স্থির DNS রেকর্ড, DMARC একটি নীতি বিবৃতি, কিন্তু DKIM যাত্রা বেঁচে থাকতে হবে। Defaults.Exposed জনগণনা অনুযায়ী মাত্র 51.84% গ্রেডকৃত ডোমেইন স্ক্যান সময়ে DNS-এ একটি আবিষ্কারযোগ্য DKIM কী প্রকাশ করে, এবং 261,086,232 গ্রেডকৃতের মাত্র 10,092,481 ডোমেইন — 3.87% — একসাথে SPF, DKIM এবং একটি এনফোর্সিং DMARC নীতি ধারণ করে (SPF গ্রহণ পরিপক্কতা মডেল সিঁড়িটি ভেঙে দেয়)। এই সমাধান ঠিক করা সেই 3.87%-এ যোগ দেওয়ার সবচেয়ে কঠিন অংশ।

সচরাচর জিজ্ঞাসিত প্রশ্ন

“বডি হ্যাশ যাচাই হয়নি” কি কেউ আমার ডোমেইন স্পুফ করছে তার লক্ষণ? সাধারণত না — একটি স্পুফার সাধারণত আপনার DKIM স্বাক্ষর তৈরি করতে পারে না, তাই তাদের মেইলে কোনো স্বাক্ষর নেই বা no key দেখায়। একটি ব্যর্থ বডি হ্যাশ মানে আপনার অবকাঠামোর দ্বারা সত্যিকারের স্বাক্ষরিত একটি বার্তা পরে সম্পাদিত হয়েছিল। কোনো আক্রমণকারীর অনুমান করার আগে আপনার নিজের গেটওয়ে পরীক্ষা করুন।

এই বার্তাগুলিতে SPF পাস হয় — আমি কি এখনও ঠিক আছি? এখনকে জন্য, সম্ভবত: DMARC শুধুমাত্র একটি অ্যালাইনড পাস প্রয়োজন। কিন্তু কেউ বার্তা ফরওয়ার্ড করলেই SPF-এর পাস বাষ্প হয়ে যায়, এবং যদি এটি আপনার From ডোমেইনে অ্যালাইনড না হয় তাহলে এটি DMARC-এর জন্য গণনা করেনি। সম্পূর্ণ ত্রয়ী ধারণকারী মাত্র 3.87% ডোমেইন সহ (2026-06-29 261,086,232 ডোমেইনের জনগণনা), “এক পা খুঁড়িয়ে চলছে” স্বাভাবিক অবস্থা — এবং ঠিক করার মতো।

relaxed/relaxed ক্যানোনিকালাইজেশনে স্যুইচ করা কি আমার দাবিত্যাগ সমস্যা ঠিক করবে? না। Relaxed শুধুমাত্র হোয়াইটস্পেস এবং লাইন-র‍্যাপিং পরিবর্তন সহ্য করে। একটি যুক্ত দাবিত্যাগ একটি বিষয়বস্তু পরিবর্তন, এবং হ্যাশ অবশ্যই এতে ব্যর্থ হবে — এটি সঠিকভাবে কাজ করছে DKIM। স্বাক্ষর বিন্দু সরান বা দাবিত্যাগ সরান।

ব্যর্থতা শুধুমাত্র একজন গ্রাহকের ডোমেইনে ঘটে। কেন? তাদের পক্ষ প্রায় নিশ্চিতভাবে ইনবাউন্ড মেইল পরিবর্তন করে — তাদের যাচাইকর্তা চালানোর আগে লিঙ্ক পুনর্লিখন করা বা ব্যানার স্ট্যাম্প করা একটি নিরাপত্তা যন্ত্রপাতি, বা বডি পুনরায় এনকোড করা একটি অভ্যন্তরীণ ফরওয়ার্ড। তাদের এই পৃষ্ঠার ডায়াগনস্টিক বিভাগ পাঠান; সমাধান তাদের গেটওয়েতে, আপনার DNS-এ নয়।

মালিককে রিপোর্ট পাঠান

আপনি যদি কোনো ক্লায়েন্ট বা নিয়োগকর্তার জন্য এটি ঠিক করছেন, প্রমাণ দিয়ে বন্ধ করুন। পরিবর্তনকারী হপ ঠিক হলে, বিনামূল্যে স্ক্যান পুনরায় চালান এবং গ্রেডকৃত রিপোর্টটি ব্যবসার মালিকের কাছে ফরওয়ার্ড করুন: তারিখযুক্ত, সরল-ভাষায়, DKIM এবং DMARC এক পৃষ্ঠায়। এটি সাইবার-বীমা নবায়ন এবং পরবর্তী সরবরাহকারী প্রশ্নাবলীর জন্য তাদের প্রয়োজনীয় নিদর্শন — প্রমাণ যে কোম্পানি ছেড়ে যাওয়া মেইল এখন যে মেইল পৌঁছায়।

আপনার ডোমেইন পরীক্ষা করুন → · “DKIM signature not valid” গাইড → · DKIM ঠিক করুন → · আমরা কীভাবে গ্রেড করি → · শুধুমাত্র সমন্বিত তথ্য। EU-তে তথ্য সংরক্ষিত এবং প্রক্রিয়া করা হয়।