DKIM "স্বাক্ষরের জন্য কোনো কী নেই": সিলেক্টর এবং রোটেশন সমাধান (২০২৬)

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

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

“স্বাক্ষরের জন্য কোনো কী নেই” মানে রিসিভার আপনার DKIM স্বাক্ষর যে DNS রেকর্ডে নির্দেশ করে — selector._domainkey.yourdomain — তা কোয়েরি করেছে এবং কোনো কী খুঁজে পায়নি: এটি কখনো প্রকাশিত হয়নি, বা রোটেশনের মাঝপথে মুছে ফেলা হয়েছে। আপনার সাইনার আসলে যে সিলেক্টর ব্যবহার করে তা প্রকাশ করুন। Defaults.Exposed জনগণনায় 261,086,232 গ্রেডকৃত ডোমেইনের মাত্র 10,092,481 ডোমেইন — 3.87% — SPF+DKIM+DMARC ত্রয়ী সম্পন্ন করে।

সমাধান হল একটি DNS রেকর্ড, একটি হেডারে পাওয়া। একটি বাস্তব DKIM-Signature হেডার থেকে s= এবং d= ট্যাগ পড়ুন আপনার মেইল কোন সিলেক্টর দিয়ে স্বাক্ষরিত তা জানতে, সেই সঠিক রেকর্ড প্রকাশ করুন (বা মেরামত করুন), এবং CNAME অর্পণ পছন্দ করুন যাতে আপনার প্রদানকারী আপনার জন্য কী রোটেট করে। তারপর নিচের রানবুক দ্বারা রোটেট করুন — এই ত্রুটির সাধারণত মানে কেউ অকালে একটি পুরানো সিলেক্টর মুছে ফেলেছে।

“dkim স্বাক্ষরের জন্য কোনো কী নেই” কী মানে?

প্রতিটি DKIM স্বাক্ষর রিসিভারকে বলে দুটি ট্যাগ পাবলিক কী কোথায় নিতে হবে: d= (স্বাক্ষর ডোমেইন) এবং s= (সিলেক্টর)। রিসিভার সেগুলো থেকে তৈরি একটি DNS নাম কোয়েরি করে — s._domainkey.d — কীর জন্য। “স্বাক্ষরের জন্য কোনো কী নেই” মানে সেই কোয়েরি খালি ফিরে এসেছে: স্বাক্ষর বিদ্যমান, কিন্তু এটি যে কী নাম দেয় তা নেই।

বাক্যাংশটি Authentication-Results হেডার এবং DMARC সমন্বয় রিপোর্টে দেখা যায় — সঠিক বাক্যাংশ রিসিভার অনুযায়ী পরিবর্তিত হয়, কিন্তু দুটি বৈচিত্র্য গুরুত্বপূর্ণ:

ফলাফল স্ট্রিং (টুকরো, ব্যাপকভাবে পর্যবেক্ষণ করা হিসেবে)	আসলে কী ঘটেছে	ক্ষণস্থায়ী?
`dkim=temperror (no key for signature)`	DNS কোয়েরি ব্যর্থ বা টাইম আউট হয়েছে — রিসিভার মোটেই একটি উত্তর পায়নি	হ্যাঁ — পুনরায় চেষ্টা প্রায়ই পাস করে; শুধুমাত্র ক্রমাগত হলে তদন্ত করুন
`dkim=permerror (no key for signature)`	DNS কোয়েরি সফল হয়েছে এবং উত্তর ছিল “এরকম কোনো রেকর্ড নেই” — সিলেক্টর সত্যিই অনুপস্থিত	না — আপনি প্রকাশ না করা পর্যন্ত রেকর্ড অনুপস্থিত

একটি এককালীন temperror হল DNS আবহাওয়া। একটি permerror — বা দিন এবং রিসিভার জুড়ে পুনরাবৃত্ত temperror — মানে স্বাক্ষর যে রেকর্ডে নির্দেশ করে তা আপনার জোনে নেই। এটি এই গাইড।

পরিণতি: একটি যাচাইযোগ্য স্বাক্ষর মোটেই কোনো DKIM না থাকার মতো গণনা করে, তাই DMARC শুধুমাত্র SPF-এ ফলব্যাক করে — এবং SPF ফরওয়ার্ডিংয়ের অধীনে ভাঙে। যদি স্বাক্ষর উপস্থিত থাকে কিন্তু অনুপস্থিত না হয়ে অবৈধ হয় (বডি হ্যাশ, বিকৃত কী), এটি একটি ভিন্ন ব্যর্থতা — দেখুন “DKIM signature not valid”।

আমার মেইল কোন সিলেক্টর দিয়ে স্বাক্ষরিত তা কীভাবে খুঁজব?

আপনার প্রদানকারীর ডকুমেন্টেশন থেকে অনুমান করবেন না — একটি বাস্তব বার্তা থেকে পড়ুন:

প্রভাবিত সিস্টেম থেকে আপনার নিয়ন্ত্রণে একটি মেইলবক্সে (Gmail ভালো কাজ করে) একটি বার্তা পাঠান।
কাঁচা উৎস খুলুন (Gmail-এ “Show original”, Outlook-এ “View message source”)।
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 স্বাক্ষর থাকতে পারে — মেইলবক্স প্রদানকারী, নিউজলেটার সরঞ্জাম, হেল্পডেস্ক — প্রতিটি তার নিজস্ব s=/d= জোড়া এবং রেকর্ড সহ। ব্যর্থটি ঠিক করুন, এবং এর d= নোট করুন: শুধুমাত্র d= আপনার From ডোমেইনের সাথে মেলে এমন স্বাক্ষর DMARC-এ সাহায্য করে।

সিলেক্টর রেকর্ড কেন অনুপস্থিত?

চারটি কারণ প্রায় সব এই ত্রুটির জন্য দায়ী — এই ক্রমে পরীক্ষা করুন:

এটি কখনো প্রকাশিত হয়নি। সাইনার (ডিফল্টরূপে বা ইচ্ছাকৃতভাবে) একটি সিলেক্টর দিয়ে চালু হয়েছিল যা কেউ DNS-এ যোগ করেনি। নতুন সরঞ্জাম এবং গেটওয়েগুলির সাথে সাধারণ যা অপ্রত্যাশিতভাবে স্বাক্ষর করে।
রোটেশনের মাঝপথে মুছে ফেলা হয়েছিল। কেউ পুরানো সিলেক্টর “পরিষ্কার করেছে” যখন এটি দিয়ে স্বাক্ষরিত বার্তাগুলি এখনও ট্রানজিটে, পুনরায় চেষ্টার জন্য সারিবদ্ধ বা ফরওয়ার্ডিংয়ের অপেক্ষায় ছিল। সেই মেইল ইতিমধ্যে s=old দিয়ে স্বাক্ষরিত; old._domainkey মুছলে সেই প্রতিটি বার্তা পূর্ববর্তীভাবে ভাঙে।
আপনার DNS UI একটি CNAME টার্গেট বিকৃত করেছে। অনেক প্রদানকারী CNAME এর মাধ্যমে অর্পণ করে (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), এবং অনেক DNS প্যানেল নীরবে টার্গেটে আপনার জোন যোগ করে — s1.domainkey.u123.esp.com.yourdomain.com সংরক্ষণ করে, যা কিছুতেই সমাধান হয় না। টার্গেট যাচাই করুন: dig CNAME s1._domainkey.yourdomain.com +short। একই ফাঁদ সরঞ্জাম মাইগ্রেশনের সময় কামড়ায় — দেখুন ইমেইল সরঞ্জাম পরিবর্তনের পর DKIM ব্যর্থ হচ্ছে।
প্রদানকারী রোটেট করেছে, আপনার জোন করেনি। একটি স্ট্যাটিক TXT রেকর্ড হিসেবে পেস্ট করা একটি প্রদানকারী কী (তাদের CNAME-এর পরিবর্তে) তাদের নির্ধারিত রোটেশনের দ্বারা এতিম হয় — সাইনার একটি সিলেক্টরে চলে যায় যা আপনি কখনো প্রকাশ করেননি। জনগণনায় 261 মিলিয়ন ডোমেইনের মাত্র 51.84% স্ক্যান সময়ে একটি আবিষ্কারযোগ্য DKIM কী উপস্থাপন করে (2026-06-29 তারিখের তথ্য)।

“স্বাক্ষরের জন্য কোনো কী নেই” কীভাবে ঠিক করব?

DNS স্পর্শ করার আগে defaults.exposed এ বিনামূল্যে স্ক্যান চালান। এটি আপনার লাইভ DKIM, SPF এবং DMARC রেকর্ড পড়ে এবং রিসিভাররা আসলে কী দেখে তা দেখায় — সিলেক্টর সমাধান হয় কিনা এবং CNAME টার্গেট বিকৃত হয়েছে কিনা সহ।
সাইনার আসলে যে সিলেক্টর ব্যবহার করে তা প্রকাশ করুন — হেডার থেকে s= মান, পুরানো রানবুকে নয়। আপনার প্রদানকারীর অ্যাডমিন কনসোল থেকে রেকর্ড নিন (Google Workspace DKIM সেটআপ · Microsoft 365 DKIM সেটআপ) এবং ঠিক s._domainkey.yourdomain.com-এ যোগ করুন।
TXT কী পেস্ট করার চেয়ে CNAME অর্পণ পছন্দ করুন। যদি আপনার প্রদানকারী DKIM CNAME অফার করে, তা ব্যবহার করুন: কী তাদের জোনে থাকে, তাই তারা আপনাকে আবার DNS স্পর্শ না করে রোটেট করে — কারণ 4 অসম্ভব হয়ে যায়। নিউজলেটার প্ল্যাটফর্মগুলি প্রায় সবই এইভাবে কাজ করে; দেখুন Mailchimp/Brevo/Klaviyo ইমেইল DMARC ব্যর্থ করছে।
আপনার প্যানেলের বাইরে থেকে যাচাই করুন। dig TXT s._domainkey.yourdomain.com +short (বা অর্পিত সিলেক্টরের জন্য dig CNAME …) আপনার নেটওয়ার্কের বাইরে একটি মেশিন থেকে। প্যানেল রেকর্ড দেখাচ্ছে প্রমাণ করে না যদি জোন অন্য কিছু পরিবেশন করে।
পুনরায় স্ক্যান করুন এবং পরীক্ষা বার্তা পুনরায় পাঠান। Authentication-Results এখন dkim=pass পড়া উচিত। তারপর fix DKIM পৃষ্ঠায় স্ক্যান যা ফ্ল্যাগ করে তা কাজ করুন — একটি পাসিং স্বাক্ষর যা আপনার From ডোমেইনের সাথে অ্যালাইন করে না তা এখনও DMARC ব্যর্থ করে।

আমি এই ত্রুটি না ঘটিয়ে DKIM কী কীভাবে রোটেট করব?

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

পদক্ষেপ	ক্রিয়া	পরবর্তী পদক্ষেপের আগে গেট
১. যোগ করুন	নতুন সিলেক্টর প্রকাশ করুন (`s2._domainkey…`) পুরানোর পাশাপাশি	`dig` নিশ্চিত করে এটি বাইরে থেকে সমাধান হয়
২. পরিবর্তন করুন	সাইনারকে নতুন সিলেক্টরে নির্দেশ করুন	পরীক্ষা বার্তা `s=s2` এবং `dkim=pass` দেখায়
৩. অপেক্ষা করুন	পুরানো সিলেক্টর প্রকাশিত রাখুন যখন ইন-ফ্লাইট, সারিবদ্ধ এবং ফরওয়ার্ড করা ট্র্যাফিক নিষ্কাশিত হয়	≥ ৭ দিন; DMARC সমন্বয় রিপোর্ট দেখুন পুরানো সিলেক্টর উপস্থিত না হওয়া পর্যন্ত
৪. অবসর দিন	পুরানো কী সরিয়ে দিন — বা আরও ভালো, একটি খালি `p=` ট্যাগ দিয়ে পুনঃপ্রকাশ করুন: “অবসরপ্রাপ্ত”, “কখনো ছিল না” নয়	কাটওভারে এটি শুরু করবেন না — অকাল মুছে ফেলা “স্বাক্ষরের জন্য কোনো কী নেই”-এর #1 কারণ

CNAME অর্পণ সহ, আপনার প্রদানকারী তাদের নিজস্ব জোনে এই সঠিক রানবুক চালায় এবং আপনি কখনো এটি দেখেন না — অর্পণের পক্ষে সবচেয়ে শক্তিশালী যুক্তি।

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

“স্বাক্ষরের জন্য কোনো কী নেই” কি temperror নাকি permerror? উভয় স্ট্রিং বিদ্যমান: temperror হল একটি DNS লুকআপ যা ব্যর্থ বা টাইম আউট হয়েছে — ক্ষণস্থায়ী, প্রায়ই পুনরায় চেষ্টায় চলে যায় — যখন permerror মানে DNS “এরকম কোনো রেকর্ড নেই” উত্তর দিয়েছে। রিসিভার জুড়ে পুনরাবৃত্ত একটি temperror সাধারণত একটি সত্যিকারের অনুপস্থিত রেকর্ডও হয়। dig দিয়ে পরীক্ষা করুন এবং উত্তর বিশ্বাস করুন, লেবেল নয়।

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

নতুন কাজ করলে সাথে সাথে পুরানো সিলেক্টর মুছে ফেলতে পারি? অবিলম্বে নয়। এটি দিয়ে স্বাক্ষরিত বার্তাগুলি এখনও পুনরায় চেষ্টার সারি এবং ফরওয়ার্ডিং পথে আছে; কী মুছলে তাদের পূর্ববর্তীভাবে ভাঙে। অন্তত এক সপ্তাহ পুরানো রেকর্ড রাখুন, পুরানো সিলেক্টর উপস্থিত না হওয়া পর্যন্ত DMARC রিপোর্ট দেখুন, তারপর অবসর দিন — আদর্শভাবে মুছে ফেলার চেয়ে একটি খালি p= সহ।

আমার প্রদানকারীর পরীক্ষক বলছে DKIM কনফিগার করা হয়েছে, কিন্তু রিসিভাররা এখনও কোনো কী নেই রিপোর্ট করছে। কীভাবে? প্রায় সবসময় CNAME-টার্গেট ফাঁদ: আপনার DNS প্যানেল টার্গেটে আপনার জোন যোগ করেছে (…esp.com.yourdomain.com), তাই রেকর্ড বিদ্যমান কিন্তু কোথাও নির্দেশ করে না। dig CNAME selector._domainkey.yourdomain.com +short সংরক্ষিত টার্গেট আক্ষরিকভাবে দেখায় — প্রদানকারী যা চেয়েছিল তার সাথে অক্ষর-অক্ষর তুলনা করুন।

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

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

বিনামূল্যে আপনার DKIM পরীক্ষা করুন

আপনার সিলেক্টরগুলি সমাধান হয় কিনা দেখুন — এবং ঠিক কী ঠিক করতে হবে — ব্যক্তিগতভাবে এবং মালিক-শুধুমাত্র।

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