اس ڈومین کے لیے جس کے آپ مالک ہیں، برانڈڈ پورٹ ایبلٹی ٹول ڈومین اور تصدیق شدہ ای میل ارسال ترتیب دیں، ان میزبان ناموں اور DNS اقدار کا استعمال کرتے ہوئے جو MultiTEL آپ کی سروس کے لیے تصدیق کرتا ہے۔ یہ ترتیبات فون نمبر منتقل کرنے سے الگ ہیں۔
یہ سیٹ اپ کس لیے ہے
آپ کے اپنے برانڈ والا پورٹ ایبلٹی ٹول (وائٹ لیبل) آپ کو نمبر منتقلی کی درخواستیں اپنے برانڈ کے تحت پیش کرنے دیتا ہے اور، جب ترتیب دی گئی ہو، اپنے ای میل ڈومین کی جانب سے درخواست ای میلز بھیجنے دیتا ہے۔ اس گائیڈ میں 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 ریکارڈ شائع نہ کریں۔ پوری پالیسی کو، بشمول اندرونی includes اور redirects، 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 تصدیق کرتا ہے۔