Defaults.Exposed › সমাধান › Guides

ইমেইল সরঞ্জাম পরিবর্তনের পর DKIM ব্যর্থ হচ্ছে: CNAME এবং সিলেক্টর মাইগ্রেশন গাইড (২০২৬)

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

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

একটি সরঞ্জাম পরিবর্তনের পর DKIM দুটি যান্ত্রিক কারণে ভাঙে: আপনার DNS প্যানেল নতুন সরঞ্জামের CNAME টার্গেট বিকৃত করেছে — সাধারণত আপনার নিজের জোন যোগ করে — অথবা পুরানো সরঞ্জামের সিলেক্টরগুলি তার মেইল নিষ্কাশনের আগে সরানো হয়েছে। Defaults.Exposed জনগণনায় 261,086,232 গ্রেডকৃত ডোমেইনের মাত্র 3.87% ডোমেইন — 10,092,481 — SPF+DKIM+DMARC ত্রয়ী সম্পন্ন করে।

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

সরঞ্জাম পরিবর্তন করলে DKIM কেন ভাঙল?

DKIM নিজেই কিছু পরিবর্তন হয়নি — আপনার সিলেক্টরগুলি পরিবর্তিত হয়েছে। পুরানো সরঞ্জাম তার সিলেক্টর দিয়ে স্বাক্ষর করেছিল; নতুনটি ভিন্ন সিলেক্টর দিয়ে স্বাক্ষর করে, সাধারণত অনবোর্ডিংয়ের সময় যোগ করা দুই বা তিনটি CNAME রেকর্ডের মাধ্যমে অর্পিত। চারটি গোটচা প্রায় প্রতিটি পোস্ট-মাইগ্রেশন DKIM ব্যর্থতার জন্য দায়ী:

1. আপনার DNS প্যানেল CNAME টার্গেটে আপনার জোন যোগ করেছে। অনেক প্যানেল কোনো পেস্ট করা হোস্টনামকে আপেক্ষিক হিসেবে বিবেচনা করে এবং নীরবে target.provider.com.yourdomain.com সংরক্ষণ করে target.provider.com-এর পরিবর্তে। রেকর্ড বিদ্যমান, প্যানেল একটি সবুজ টিক দেখায়, এবং এটি কিছুতেই সমাধান হয় না।
2. ট্রেইলিং-ডট বিভ্রান্তি। কিছু প্যানেলে “পরম — আমার জোন যোগ করা বন্ধ করুন” বোঝাতে একটি ট্রেইলিং ডট (target.provider.com.) প্রয়োজন; অন্যরা ডটকে অবৈধ হিসেবে প্রত্যাখ্যান করে এবং নিজেরাই পরম পরিচালনা করে। একই পেস্ট করা মান এক প্যানেলে সঠিক এবং পরেরটিতে বিকৃত।
3. পুরানো সরঞ্জামের সিলেক্টর সুইচ ডে-তে মুছে ফেলা হয়েছিল। পুরানো সরঞ্জামটি ইতিমধ্যে স্বাক্ষরিত মেইল পুনরায় চেষ্টার সারি এবং ফরওয়ার্ডিং পথে দিনের পর দিন থাকে; এর সিলেক্টর মুছে ফেলা — বা পুরানো অ্যাকাউন্ট বন্ধ করা, যা তার অর্পিত CNAME গুলি মেরে ফেলে — সেই মেইল পূর্ববর্তীভাবে ভেঙে দেয়।
4. আপনি ভুল নেমসার্ভারে যাচাই করেছেন। মাইগ্রেশনে নেমসার্ভার পরিবর্তন অন্তর্ভুক্ত থাকলে, সংশোধিত রেকর্ডগুলি এক NS সেটে থাকতে পারে যখন রিসিভাররা এখনও অন্যটি কোয়েরি করছে।

জনগণনায় 261 মিলিয়ন ডোমেইনের মাত্র 51.84% স্ক্যান সময়ে একটি আবিষ্কারযোগ্য DKIM কী উপস্থাপন করে (2026-06-29 তারিখের তথ্য)।

একই মাইগ্রেশন সাধারণত SPF ধ্বংসাবশেষও ছেড়ে যায় — 1,013,416 ডোমেইন, SPF চেষ্টা করা প্রায় প্রতি 138-তে একটি, দুটি v=spf1 রেকর্ড চালায়, ক্লাসিক চিহ্ন যে একটি প্রদানকারী পরিবর্তন একটি মিলিয়ে নেওয়ার পরিবর্তে একটি রেকর্ড যোগ করেছে। চালের সেই দিকের নিজস্ব গাইড আছে: আপনি ইমেইল প্রদানকারী পরিবর্তনের পর SPF কাজ করা বন্ধ করে দিয়েছে।

কীভাবে একটি বিকৃত CNAME রেকর্ড সনাক্ত করব?

প্যানেল বিশ্বাস করবেন না — DNS-কে জিজ্ঞাসা করুন এটি আসলে কী সংরক্ষণ করেছে। নতুন সরঞ্জাম আপনাকে দেওয়া প্রতিটি সিলেক্টরের জন্য CNAME টার্গেট কোয়েরি করুন। একটি দৃষ্টান্তমূলক উদাহরণ, একটি SendGrid-শৈলী অর্পিত সিলেক্টর অনুকরণ করে (আপনার প্রদানকারীর টার্গেট আকার ভিন্ন হবে):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

প্রদানকারী s1.domainkey.u1234567.wl123.sendgrid.net চেয়েছিল — কিন্তু সংরক্ষিত টার্গেট .yourdomain.com দিয়ে শেষ হয়। প্যানেল জোন যোগ করেছে; সেই নামটি কিছুতেই সমাধান হয় না, তাই রিসিভাররা কোনো কী খুঁজে পায় না। সুস্থ সংস্করণ:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(dig আউটপুটে একটি একক ট্রেইলিং ডট স্বাভাবিক — এটি একটি সম্পূর্ণ-যোগ্য নাম চিহ্নিত করে।) টার্গেট সঠিক হলে, এক হপ অনুসরণ করুন: dig TXT s1._domainkey.yourdomain.com +short প্রদানকারীর কী ফেরত দেওয়া উচিত। একটি সঠিক CNAME সহ খালি উত্তর মানে সমস্যা প্রদানকারীর অর্পণের পাশে — তাদের যাচাইকরণ পদক্ষেপ সম্পন্ন করুন, অথবা সিলেক্টর-স্তরের ডায়াগনস্টিকের জন্য DKIM “no key for signature” দেখুন।

মাইগ্রেশন রানবুক: আগে, সময়ে, পরে

ব্যর্থতা সাধারণত রেকর্ড নয় — এটি ক্রম। DKIM মাইগ্রেশন কাটওভারে ভুল হয় কারণ যাচাইকরণ পরিবর্তনের পরে ঘটে, যখন বাস্তব মেইল ইতিমধ্যেই ব্যর্থ হচ্ছে।

বোল্ড সারিটি যেখানে মাইগ্রেশন বাঁচানো বা হারানো হয়: এতে প্রতিটি চেক কাটওভারের দিন আগে করা যেতে পারে, বাস্তব মেইলের কোনো ঝুঁকি ছাড়াই। সিলেক্টর-অবসর মেকানিক্স — কেন একটি খালি p=-এর সাথে পুনঃপ্রকাশ মুছে ফেলার চেয়ে ভালো তা সহ — রোটেশন রানবুক-এ কভার করা হয়েছে; এই টেবিলটি সরঞ্জাম পরিবর্তন নিজেই ক্রমানুসার সম্পর্কে।

পরিবর্তনের পরে DKIM কীভাবে ঠিক করব?

1. DNS স্পর্শ করার আগে defaults.exposed এ বিনামূল্যে স্ক্যান চালান। এটি আপনার লাইভ রেকর্ড পড়ে এবং রিসিভাররা আসলে কী দেখে তা দেখায় — জোন-যুক্ত CNAME টার্গেট এবং সমাধান না হওয়া সিলেক্টর সহ।
2. নতুন সরঞ্জাম প্রত্যাশিত DKIM রেকর্ড তালিকা করুন। এর অ্যাডমিন কনসোল থেকে — মেইলবক্স প্রদানকারীদের জন্য, Google Workspace এবং Microsoft 365 সেটআপ গাইড কোথায় দেখায়; নিউজলেটার এবং CRM সরঞ্জামগুলি ডোমেইন প্রমাণীকরণের অধীনে তাদের CNAME তালিকা করে (দেখুন Mailchimp/Brevo/Klaviyo ইমেইল DMARC ব্যর্থ করছে)।
3. dig CNAME <name> +short দিয়ে প্রতিটি রেকর্ডের সংরক্ষিত মান পরীক্ষা করুন এবং অক্ষর-অক্ষর সরঞ্জাম যা চেয়েছিল তার সাথে তুলনা করুন। আপনার নিজের ডোমেইনে শেষ হওয়া একটি টার্গেট = জোন-যুক্ত; এটি পুনরায় প্রবেশ করুন, এবং প্যানেল যদি যোগ করতে থাকে, ট্রেইলিং ডট যোগ করুন (বা যদি প্যানেল ডট প্রত্যাখ্যান করে তা সরিয়ে দিন)।
4. কর্তৃত্বপূর্ণ নেমসার্ভারে যাচাই করুন। dig +short NS yourdomain.com, তারপর সেই নেমসার্ভার @<that nameserver>-এ CNAME চেক পুনরাবৃত্তি করুন। মাইগ্রেশন নেমসার্ভার পরিবর্তন করলে, উভয় সেট পরীক্ষা করুন — রিসিভাররা এখনও পুরানোটি কোয়েরি করতে পারে যতক্ষণ না অর্পণ প্রসারিত হয়।
5. সরঞ্জামের যাচাইকরণ পুনরায় চালান এবং একটি পরীক্ষা বার্তা পাঠান। Authentication-Results হেডার dkim=pass দেখানো উচিত আপনার ডোমেইনের সমান d= সহ — সরঞ্জামের ডিফল্ট ডোমেইনে একটি পাস DMARC-এর জন্য অ্যালাইন করে না।
6. পুরানো সরঞ্জামের সিলেক্টরগুলি তার মেইল নিষ্কাশন না হওয়া পর্যন্ত প্রকাশিত রাখুন, তারপর ইচ্ছাকৃতভাবে অবসর দিন। তারপর পুনরায় স্ক্যান করুন এবং fix DKIM পৃষ্ঠায় ফ্ল্যাগ করা যেকোনো কিছু কাজ করুন।

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

আমার DKIM CNAME-এ ট্রেইলিং ডট দরকার কিনা? এটি সম্পূর্ণরূপে প্যানেলের উপর নির্ভর করে। ডটের অর্থ “পরম নাম — আমার জোন যোগ করবেন না”; কিছু প্যানেল এটি প্রয়োজন, কিছু আপনার জন্য যোগ করে, কিছু প্রত্যাখ্যান করে। সংরক্ষণের পরে dig CNAME <selector>._domainkey.yourdomain.com +short-এর আউটপুটই একমাত্র পরীক্ষা যা গুরুত্বপূর্ণ: যদি টার্গেট আপনার নিজের ডোমেইনে শেষ হয়, প্যানেল জোন যোগ করেছে এবং আপনার ডট প্রয়োজন (বা ভিন্ন ইনপুট ফরম্যাট)।

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

আমার DNS প্যানেল এবং নতুন সরঞ্জাম উভয়ই “যাচাইকৃত” বলে, কিন্তু রিসিভাররা এখনও DKIM ব্যর্থ করে। কীভাবে? দুটি সাধারণ ক্ষেত্র: সরঞ্জামটি একটি ক্যাশড চেকের বিপরীতে যাচাই করেছিল যখন কর্তৃত্বপূর্ণ নেমসার্ভার অন্য কিছু পরিবেশন করে (সরাসরি dig @<ns>-এর সাথে তাদের কোয়েরি করুন), অথবা DKIM পাস করে কিন্তু সরঞ্জামের ডিফল্ট স্বাক্ষর ডোমেইনে, আপনারটিতে নয়, তাই DMARC এখনও অ্যালাইনমেন্ট ব্যর্থ করে। স্ক্যান দুটির মধ্যে পার্থক্য করে।

মাইগ্রেশনের সময় উভয় সরঞ্জামের DKIM রেকর্ড একসাথে থাকতে পারে? হ্যাঁ — এবং তাদের উচিত। DKIM-এর কোনো একক-রেকর্ড নিয়ম নেই: প্রতিটি সিলেক্টর তার নিজস্ব DNS নাম, তাই উভয় সরঞ্জামের রেকর্ড কোনো দ্বন্দ্ব ছাড়াই পাশাপাশি থাকে, যা নিষ্কাশন-মাধ্যমে-পুরানো-সিলেক্টর-রাখার নিয়ম অনুসরণ করা বিনামূল্যে করে। (SPF বিপরীত — দুটি v=spf1 রেকর্ড এটি বাতিল করে, কারণেই SPF মাইগ্রেশন গাইড মার্জ করার বিষয়ে।)

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

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

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

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

আপনার ডোমেইন পরীক্ষা করুন → · প্রদানকারী পরিবর্তনের পর SPF ভেঙেছে → · DKIM ঠিক করুন → · Google Workspace-এ DKIM সেটআপ করুন → · শুধুমাত্র সমন্বিত তথ্য। EU-তে তথ্য সংরক্ষিত এবং প্রক্রিয়া করা হয়।