আপনার মালিকানাধীন একটি ডোমেনের জন্য ব্র্যান্ডেড পোর্টেবিলিটি টুল ডোমেন এবং প্রমাণীকৃত ইমেইল প্রেরণ সেট আপ করুন, আপনার পরিষেবার জন্য MultiTEL যে হোস্টনেম ও DNS মান নিশ্চিত করে সেগুলো ব্যবহার করে। এই সেটিংস একটি ফোন নম্বর স্থানান্তর থেকে পৃথক।
এই সেটআপ কীসের জন্য
নিজের ব্র্যান্ডের একটি পোর্টেবিলিটি টুল (হোয়াইট-লেবেল) আপনাকে নিজের ব্র্যান্ডের অধীনে নম্বর-স্থানান্তর অনুরোধ উপস্থাপন করতে দেয় এবং, কনফিগার করা থাকলে, আপনার নিজের ইমেইল ডোমেনের পক্ষ থেকে অনুরোধ ইমেইল পাঠাতে দেয়। এই গাইডের DNS পরিবর্তনগুলো সেই ব্র্যান্ডেড ওয়েবসাইট ও ইমেইল পরিচয়ে প্রযোজ্য। এগুলো সাধারণ ফোন-নম্বর স্থানান্তরের জন্য আবশ্যক নয় এবং ফোন নম্বরের ভয়েস রাউটিং পরিবর্তন করে না।
যে ডোমেনের DNS আপনি পরিবর্তন করবেন, সেই ডোমেনের মালিকানা ও নিয়ন্ত্রণ আপনার থাকতে হবে। আপনার মালিকানাধীন নয় এমন তৃতীয় পক্ষের ফ্রি-মেইল ডোমেনের কোনো ঠিকানার জন্য এই রেকর্ডগুলো কনফিগার করা যাবে না।
DNS পরিবর্তনের আগে ব্র্যান্ডেড পরিষেবা নিশ্চিত করুন
নম্বর পোর্টেবিলিটি খুলুন। সেখানকার ব্র্যান্ডিং ফিল্ড ব্যবহার করে সেই স্ক্রিনে অনুরোধের জন্য ব্যবহৃত ব্র্যান্ডের নাম ও লোগো সেট করুন। নিজের ব্র্যান্ডের কাস্টম-ডোমেন সাইটের (হোয়াইট-লেবেল) জন্য, কোনো DNS রেকর্ড প্রকাশ করার আগে MultiTEL সাপোর্টকে আপনার অ্যাকাউন্টের জন্য নিশ্চিত করতে বলুন কোন ব্র্যান্ড সেটিংস প্রযোজ্য, হোস্টনেম, প্রকাশ করতে হবে এমন DNS মান, প্রেরক ডোমেন এবং HTTPS সার্টিফিকেট সেটআপ।
কেবল একটি পোর্টেবিলিটি অনুরোধকে ব্র্যান্ড করার জন্য বিদ্যমান কোনো বাস্তবে ব্যবহৃত (প্রোডাকশন) ওয়েবসাইট রিডাইরেক্ট করবেন না বা বিদ্যমান মেইল ডেলিভারি পরিবর্তন করবেন না। আগের DNS মানগুলো সংরক্ষণ করুন যাতে প্রয়োজনে সেগুলো পুনরুদ্ধার করতে পারেন। পরবর্তী কোনো পরিবর্তন বা রোলব্যাকের দ্রুত প্রপাগেশন প্রয়োজন হলে, আগে থেকে প্রভাবিত রেকর্ডগুলোর TTL কমিয়ে দিন এবং পরিবর্তন করার আগে আগের TTL শেষ হওয়া পর্যন্ত অপেক্ষা করুন। TTL কমানো বিদ্যমান ক্যাশ করা উত্তরগুলো তৎক্ষণাৎ মেয়াদোত্তীর্ণ করে না।
ওয়েবসাইট CNAME
MultiTEL আপনার পরিষেবার জন্য কাস্টম হোস্টনেম ও CNAME টার্গেট নিশ্চিত করার পর, আপনার DNS প্রদানকারীতে অনুরোধকৃত CNAME তৈরি করুন। DNS কনসোল স্বয়ংক্রিয়ভাবে জোনের নাম যোগ করে কিনা তা পরীক্ষা করুন; সেই কনসোলের নির্দেশ অনুযায়ী হোস্ট লেবেল বা পূর্ণ নাম লিখুন, ডোমেন ডুপ্লিকেট না করে। নিশ্চিতকৃত CNAME হোস্টনেমে A, AAAA, MX বা TXT রেকর্ডও থাকতে পারবে না। সেখানে ইতিমধ্যে অন্য রেকর্ড থাকলে, পরিবর্তন করার আগে কোন পরিষেবাগুলো সেগুলো ব্যবহার করে তা পরীক্ষা করুন। সেই নাম এখনও অন্য কোনো পরিষেবার জন্য ব্যবহৃত হলে MultiTEL-অনুমোদিত একটি ভিন্ন হোস্টনেম ব্যবহার করুন; বিদ্যমান রেকর্ডগুলো কেবল তখনই সরান যখন নিশ্চিত হয়েছেন যে সেগুলো আর প্রয়োজন নেই।
নিম্নলিখিতটি কেবল একটি উদাহরণ: এটি তখনই প্রযোজ্য যদি আপনি test123.com-এর মালিক হন এবং MultiTEL porting.test123.com-কে আপনার হোস্টনেম এবং porting.multitel.net-কে আপনার পরিষেবার CNAME টার্গেট হিসেবে উভয়ই নিশ্চিত করে। সাপোর্ট আপনার পরিষেবার জন্য এটি নিশ্চিত না করলে এই টার্গেট ব্যবহার করবেন না:
porting.test123.com. IN CNAME porting.multitel.net.আপনার পরিষেবার জন্য নিশ্চিতকৃত হুবহু টার্গেট ব্যবহার করুন। একা একটি CNAME কাস্টম ডোমেন সক্রিয় করে না বা বৈধ HTTPS সার্টিফিকেটের নিশ্চয়তা দেয় না। নতুন URL শেয়ার করার আগে সাইটের সার্টিফিকেট ও ব্র্যান্ডেড অনুরোধ ফ্লো নিশ্চিত করুন।
অনুরোধ ইমেইলের জন্য SPF
MultiTEL যদি নিশ্চিত করে যে অনুরোধ ইমেইল আপনার ডোমেনের পক্ষ থেকে পাঠানো হবে, SPF-এর জন্য ব্যবহৃত প্রেরণ ডোমেন এবং DKIM-এর জন্য ব্যবহৃত স্বাক্ষর ডোমেন চিহ্নিত করতে সাপোর্টকে বলুন। এগুলো ব্র্যান্ডেড ওয়েবসাইট হোস্টনেম হওয়া আবশ্যক নয়। নিশ্চিতকৃত SPF ডোমেনে SPF প্রকাশ করুন এবং নিচে বর্ণিত সিলেক্টর-নির্দিষ্ট নামে DKIM পাবলিক কী প্রকাশ করুন; ওয়েবসাইট CNAME হোস্টনেমে মেইল-প্রমাণীকরণ TXT রেকর্ড যোগ করবেন না। SPF ডোমেনের পলিসিতে নিশ্চিতকৃত প্রেরণ পরিষেবাকে অনুমোদন দিন। এখানে দেখানো MultiTEL SPF include হলো include:_spf.multitel.net। কেবল তখনই এটি যোগ করুন যখন সাপোর্ট নিশ্চিত করে যে এটি আপনার অ্যাকাউন্টের প্রেরণ পরিষেবার জন্য প্রযোজ্য।
ডোমেনে ইতিমধ্যে একটি SPF TXT রেকর্ড থাকলে, অনুমোদিত include সেই বিদ্যমান পলিসিতে মিলিয়ে নিন। অন্য বৈধ প্রেরক ও উদ্দেশ্যকৃত চূড়ান্ত পলিসি সংরক্ষণ করুন; দ্বিতীয় একটি SPF রেকর্ড প্রকাশ করবেন না। নেস্টেড include ও redirect সহ সম্পূর্ণ পলিসি SPF-এর DNS লুকআপ সীমা অনুযায়ী যাচাই করুন। SPF মূল্যায়ন সর্বাধিক 10টি DNS-লুকআপ-সৃষ্টিকারী টার্ম অনুমতি দেয়, যেমন include, a, mx, ptr, exists এবং redirect; সেই সীমা অতিক্রম করলে permerror উৎপন্ন হয়। ভাঙা SPF পলিসি বৈধ মেইলকে SPF প্রমাণীকরণ পাস করতে বাধা দিতে পারে। যদি কোনো বিদ্যমান পলিসি না থাকে এবং MultiTEL নিশ্চিত করে যে এটিই একমাত্র অনুমোদিত প্রেরক, একটি উদাহরণ হলো:
@ IN TXT "v=spf1 include:_spf.multitel.net ~all"অনুরোধ ইমেইলের জন্য DKIM
আপনার স্বাক্ষর ডোমেনের জন্য নিশ্চিতকৃত হুবহু DKIM সিলেক্টর, DNS রেকর্ড নাম এবং পাবলিক-কী TXT মান প্রকাশ করুন। DKIM DNS নাম সিলেক্টর, _domainkey এবং স্বাক্ষর ডোমেনকে একত্রিত করে। উদাহরণস্বরূপ, example.com-এর জন্য সিলেক্টর mail পূর্ণ রেকর্ড নাম mail._domainkey.example.com তৈরি করে; mail._domainkey হলো আপেক্ষিক রেকর্ড নাম, সিলেক্টর নয়। বর্তমান মানগুলো MultiTEL সাপোর্ট থেকে নিন; কোনো পুরনো আর্টিকেল, অন্য অ্যাকাউন্ট বা MultiTEL-এর নিজস্ব DNS থেকে কপি করা সিলেক্টর বা পাবলিক কী আপনার অ্যাকাউন্টের জন্য ব্যবহৃত মান বলে ধরে নেবেন না। একটি DKIM পাবলিক কী DNS-এ প্রকাশ করা হয়; একটি প্রাইভেট স্বাক্ষর কী কখনোই অনুরোধ বা প্রকাশ করা যাবে না।
আপনার DNS কনসোল স্বয়ংক্রিয়ভাবে জোনের নাম যোগ করে কিনা তা পরীক্ষা করুন এবং রেকর্ড নামে ডোমেন বা _domainkey ডুপ্লিকেট করা এড়িয়ে চলুন। DNS কনসোল একটি দীর্ঘ TXT রেকর্ডকে উদ্ধৃতিচিহ্নযুক্ত খণ্ডে ভাগ করলে সম্পূর্ণ পাবলিক-কী মান সংরক্ষণ করুন।
সম্পূর্ণ ফলাফল যাচাই করুন
প্রতিটি পরিবর্তিত রেকর্ডের জন্য অথরিটেটিভ নেমসার্ভারগুলো ও একটি বাহ্যিক রিজলভারকে কোয়েরি করুন। কনফিগার করা TTL ও DNS ক্যাশের মেয়াদ শেষ হওয়ার সময় দিন; একটি ক্যাশ করা স্থানীয় রিজলভার থেকে পাওয়া ফলাফল যথেষ্ট নয়। সব ডোমেন অংশসহ রেকর্ডের পূর্ণ নাম (FQDN), টাইপ, হুবহু টার্গেট বা মান, উদ্ধৃতিচিহ্ন এবং যেকোনো ট্রেইলিং ডট নিশ্চিতকৃত নির্দেশনা ও আপনার DNS প্রদানকারীর ইনপুট ফরম্যাটের সাথে তুলনা করুন। URL শেয়ার করার বা ব্র্যান্ডেড ইমেইলের উপর নির্ভর করার আগে পরস্পরবিরোধী রেকর্ড, ভুল নাম, অনুপস্থিত মান ও অবৈধ সার্টিফিকেট সমাধান করুন।
নিশ্চিতকৃত ব্র্যান্ডেড অনুরোধ URL খুলুন এবং পৃষ্ঠাগুলো বৈধ সার্টিফিকেট ও প্রত্যাশিত ব্র্যান্ডসহ লোড হয় কিনা তা নিশ্চিত করুন। কোনো পরীক্ষা জমা দেওয়ার আগে, MultiTEL সাপোর্টকে জিজ্ঞাসা করুন কোন পরীক্ষা ফ্লো উপলব্ধ এবং একটি জমা লাইভ নম্বর স্থানান্তর শুরু করবে কিনা। সাপোর্ট আপনার অ্যাকাউন্টের জন্য ব্র্যান্ডেড ইমেইল সক্রিয় বলে নিশ্চিত করার পর, কেবল নিশ্চিতকৃত পরীক্ষা ফ্লো-এর মাধ্যমে এবং সাপোর্ট যে নমুনা ডেটা বা পরীক্ষা পদ্ধতি দেয় তা দিয়েই এটি পরীক্ষা করুন, যাতে আপনি লাইভ নম্বর স্থানান্তর শুরু না করেন। প্রাপ্ত বার্তার প্রমাণীকরণ ফলাফলে SPF ও DKIM যাচাই করুন। উত্তর ও অনুরোধ লিঙ্ক উদ্দিষ্ট গন্তব্যে পৌঁছায় কিনা তা পরীক্ষা করুন। প্রতিস্থাপন যাচাই হওয়া পর্যন্ত আগের পরিষেবা ও রেকর্ডগুলো উপলব্ধ রাখুন এবং কেবল সেই রেকর্ডগুলো সরান যেগুলো MultiTEL নিশ্চিত করে যে প্রতিস্থাপিত হয়েছে।