جب توثیقی ای میل دیر سے آتی ہے تو دوبارہ بھیجنے کا بٹن واضح جواب محسوس ہوتا ہے۔ یہ اکثر صورتحال کو مزید خراب کر دیتا ہے: کئی پیغامات ایک ساتھ پہنچتے ہیں، صرف تازہ ترین کوڈ ہی درست رہتا ہے، اور کوئی نہیں جانتا کہ کون سی درخواست نے کون سا پیغام پیدا کیا۔
ڈیلیوری کو چیک پوائنٹس کے سلسلے کے طور پر سمجھیں۔ آخری اس چیک پوائنٹ کو تلاش کریں جو یقینی طور پر کامیاب ہوا، پھر اگلے کو جانچیں.
پہلے، شواہد کو منجمد کریں
دوسرا پیغام طلب کرنے سے پہلے درج ذیل ریکارڈ کریں:
- صحیح وصول کنندہ کا پتہ؛
- جس وقت آپ نے جمع (submit) کیا؛
- بھیجنے والے یا سروس کا نام؛
- کیا صفحے نے کامیابی کی اطلاع دی؛
- کیا یہ پہلی درخواست ہے یا دوبارہ بھیجنا؛
- متوقع میعاد ختم ہونے کا وقت، اگر دکھایا گیا ہو۔
بھیجنے والے کا صفحہ کھلا رکھیں۔ دو منٹ بعد دریافت ہونے والی ٹائپو کو درست کرنا آسان ہوتا ہے جب اصل فارم میں ابھی بھی جمع شدہ قدر موجود ہو۔
ایڈریس چیک کریں، اپنی یادداشت نہیں
جمع شدہ ایڈریس کا موازنہ GPTMail کی طرف سے دکھائے گئے ایڈریس سے کریں۔ مقامی حصہ، ہر ڈاٹ یا عدد، اور ڈومین سuffix کو چیک کریں۔ خاص توجہ دیں جب کئی ان باکس ٹیبز کھلے ہوں یا آپ نے حال ہی میں منتخب ڈومین تبدیل کیا ہو۔
پھر اس بات کی تصدیق کریں کہ ڈومین ڈومین صفحہ پر فعال ہے۔ ایک ایڈریس ترکیبی طور پر درست ہو سکتا ہے جبکہ اس کا ڈومین غیر فعال یا GPTMail کی طرف مزید روٹ نہ کیا گیا ہو۔
اگر ویب سائٹ ایڈریس کو بھیجنے سے پہلے مسترد کر دیتی ہے تو ابھی تک کوئی ڈیلیوری کا مسئلہ نہیں ہے۔ کوئی اور معاون ایڈریس بنائیں اور دوبارہ جمع کرائیں۔
تصدیق کریں کہ بھیجنے والے نے واقعی ڈیلیوری شروع کی ہے
ویب سائٹ پر کامیابی کا پیغام بعض اوقات صرف اس بات کا مطلب ہوتا ہے کہ پس منظر میں ایک جاب بنائی گئی ہے۔ بھیجنے والا ابھی بھی قطار میں ہو سکتا ہے، رفتار کی حد لگائی ہو، یا ای میل کو دوبارہ بھیجنے کی کوشش کر رہا ہو۔
دوبارہ بھیجنے سے پہلے چند منٹ انتظار کریں۔ اگر سروس سرگرمی لاگ فراہم کرتی ہے تو دیکھیں کہ آیا یہ توثیقی درخواست کو ریکارڈ کرتی ہے۔ کسی ایسے پروڈکٹ کے لیے جسے آپ چلاتے ہیں، وصول کنندہ ان باکس کو دیکھنے کے بجائے ایپلیکیشن کی قطار اور میل-پرووائیڈر کے ایونٹ کی جانچ کریں۔
ایک بار ریفریش کریں، پھر صحیح پیغام تلاش کریں
دستی ریفریش استعمال کریں اور آمد کے وقت کے حساب سے ترتیب دیں۔ متوقع بھیجنے والے اور موضوع کی تلاش کریں، صرف سروس کے نام کی بجائے جو قابلِ دیکھائی پیش نظارہ میں ہو۔ خودکار اور مارکیٹنگ میل مختلف سب ڈومینز سے آ سکتے ہیں۔
اگر کئی کوڈز آئیں تو تازہ ترین درخواست استعمال کریں۔ کئی نظام نئی کوڈ جاری ہوتے ہی پرانے کوڈز کو غیر معتبر کر دیتے ہیں۔
بھیجنے والے کے مسئلے کو ڈومین کے مسئلے سے الگ کریں
غیر متعلقہ فراہم کنندہ سے اسی ایڈریس پر ایک مختصر سادہ متن کا ٹیسٹ پیغام بھیجیں.
- اگر ٹیسٹ پہنچ جائے تو وصول کنندہ ڈومین کام کر رہا ہے اور اصل بھیجنے والا تاخیر، ایڈریس کی فلٹرنگ، یا ہینڈ آف سے پہلے ناکام ہو رہا ہے۔
- اگر کوئی بھی پیغام نہ پہنچے تو ڈومین کی حیثیت اور MX ترتیب کی تصدیق کریں۔
- اگر ایک فراہم کنندہ کے پیغامات پہنچیں لیکن دوسرا مسلسل نہ پہنچے تو رپورٹ کرنے سے پہلے بھیجنے والے، وقت کے نشان، اور کسی بھی باؤنس کی تفصیلات جمع کریں۔
کسٹم ڈومین کے لیے، بغیر اندازے کے کسٹم ڈومین MX سیٹ اپ پر عمل کریں۔ لائیو ٹیسٹ کے دوران DNS کو بے ترتیب طور پر تبدیل نہ کریں؛ ہر تبدیلی ایک نیا پروپیگیشن ونڈو بناتی ہے۔
عام DNS ناکامیوں کو سمجھیں
ایک MX لُک اپ عارضی طور پر ناکام ہو سکتا ہے کیونکہ ریزولوور کا ٹائم آؤٹ ہوا، اختیار یافتہ نام سرور متفق نہیں تھے، DNSSEC توثیق ناکام ہوئی، یا ریکارڈ ابھی تک پروپیگیٹ نہیں ہوا۔ “کوئی ریکارڈ نہیں ملا” ایک مخصوص وقت پر مخصوص لُک اپ کا نتیجہ ہے، اس کا مطلب یہ نہیں کہ ریکارڈ کبھی موجود نہیں تھا۔
اختیاری DNS ردعمل کی استفسار کریں اور اصل ہدف کا موازنہ GPTMail کے دکھائے گئے ہدف سے کریں۔ اگر وہ میچ کرتے ہیں تو انتظار کریں اور دوبارہ کوشش کریں۔ اگر میچ نہیں کرتے تو اختیاری ریکارڈ کو درست کریں۔
جب پیغام پہنچ جائے لیکن کوڈ ناکام ہو
ڈیلیوری اور توثیق الگ نظام ہیں۔ ایک کوڈ ناکام ہو سکتا ہے کیونکہ:
- ایک نیا کوڈ اسے بدل دیا؛
- کوڈ ٹرانزٹ میں میعاد ختم ہو گیا؛
- یہ کسی دوسرے براؤزر سیشن یا اکاؤنٹ سے تعلق رکھتا ہے؛
- کوڈ کے ساتھ سفید جگہ (whitespace) کاپی ہو گئی؛
- منزل صفحہ مختلف ماحول استعمال کر رہا ہے؛
- بھیجنے والے کا گھڑی یا حالت غلط ہے۔
ایک نیا کوڈ طلب کریں، اس مخصوص پیغام کا انتظار کریں، اور اسے صرف ایک بار استعمال کریں۔ اگر یہ ناکام ہو تو درخواست کا وقت اور پیغام کا وقت ساتھ ساتھ رپورٹ کریں۔
ایک مختصر سپورٹ رپورٹ
مفید رپورٹس میں وصول کنندہ کا پتہ، بھیجنے والے کا پتہ، موضوع، UTC وقت کے نشان، آیا دوسرا بھیجنے والا ان باکس تک پہنچا یا نہیں، اور بھیجنے والے کی دکھائی گئی درست خرابی شامل ہیں۔ عوامی طور پر لاگز شیئر کرنے سے پہلے توثیقی کوڈز اور نجی لنکس ہٹا دیں۔
“کوئی ای میل نہیں” کی تحقیق مشکل ہے۔ “پیغام کی درخواست 14:03 UTC پر کی گئی؛ دوسرا فراہم کنندہ 14:05 پر پہنچا؛ متوقع بھیجنے والے نے 14:15 تک کوئی پیغام یا باؤنس نہیں دیا” ناکام حصے کی نشاندہی کرتا ہے۔
جانیں کب انتظار بند کرنا ہے
اگر اکاؤنٹ اہم ہے اور سروس کوئی دوسرا توثیقی طریقہ پیش کرتی ہے تو اسے استعمال کریں۔ اگر سائن اپ کم خطرے کا ہے تو نیا معاون ایڈریس بنائیں اور دوبارہ شروع کریں۔ کسی عارضی ان باکس کو اس اکاؤنٹ کے لیے واحد بحالی راستہ نہ بنائیں جسے آپ رکھنا چاہتے ہیں۔
وسیع فیصلہ گائیڈ ہے عارضی ای میل، صحیح استعمال کے ساتھ.