जब प्रमाणीकरण इमेल ढिलाइ हुन्छ, पुनः पठाउने बटन स्पष्ट उत्तर जस्तो लाग्छ। यसले प्रायः स्थितिलाई अझ बिग्रँछ: धेरै सन्देशहरू एकै साथ आउँछन्, केवल नयाँ कोड मान्य रहन्छ, र कसैले पनि थाहा पाउँदैन कुन अनुरोधले कुन सन्देश उत्पन्न गरेको हो।
डेलिभरीलाई चेकप्वाइन्टहरूको क्रमको रूपमा हेर्नुहोस्। अन्तिम चेकप्वाइन्ट जुन निश्चित रूपमा सफल भयो खोज्नुहोस्, त्यसपछि अर्को चेकप्वाइन्ट जाँच गर्नुहोस्।
पहिलो, प्रमाणलाई स्थिर गर्नुहोस्
अर्को सन्देश अनुरोध गर्नु अघि, रेकर्ड गर्नुहोस्:
- ठीक प्राप्तकर्ता ठेगाना;
- तपाईंले सबमिट थिचेको समय;
- प्रेषक वा सेवाको नाम;
- पृष्ठले सफलताको रिपोर्ट गरेको थियो कि छैन;
- यो पहिलो अनुरोध हो वा पुनः पठाउने हो भन्ने कुरा;
- यदि देखाइएको छ भने अपेक्षित समाप्ति समय।
प्रेषक पृष्ठ खुला राख्नुहोस्। दुई मिनेटपछि पत्ता लागेको टाइपोलाई सुधार्न सजिलो हुन्छ जब मूल फारममा अझै पनि सबमिट गरिएको मान रहन्छ।
ठेगाना जाँच गर्नुहोस्, आफ्नो स्मृति होइन
सबमिट गरिएको ठेगानालाई GPTMail द्वारा देखाइएको ठेगानासँग तुलना गर्नुहोस्। स्थानीय भाग, प्रत्येक डट वा अंक, र डोमेन सुफिक्स जाँच गर्नुहोस्। धेरै इनबक्स ट्याबहरू खुला हुँदा वा तपाईंले हालै चयन गरिएको डोमेन परिवर्तन गर्नुभएको हुँदा विशेष ध्यान दिनुहोस्।
त्यसपछि डोमेन पृष्ठमा (डोमेन पृष्ठ) डोमेन सक्रिय छ कि छैन पुष्टि गर्नुहोस्। ठेगाना वाक्यरचनात्मक रूपमा मान्य हुन सक्छ जबकि यसको डोमेन निष्क्रिय छ वा अब GPTMail मा राउट गरिएको छैन।
यदि वेबसाइटले पठाउनु अघि ठेगाना अस्वीकार गर्छ भने, अहिलेसम्म डेलिभरी समस्या छैन। अर्को समर्थित ठेगाना सिर्जना गरी पुनः सबमिट गर्नुहोस्।
प्रेषकले वास्तवमा डेलिभरी सुरु गरेको पुष्टि गर्नुहोस्
वेबसाइटमा सफलताको सन्देश कहिलेकाहीँ मात्र पृष्ठभूमि काम सिर्जना भएको जनाउँछ। प्रेषक अझै पनि इमेललाई क्यूमा राखिरहेको, दर-सीमा लागू गरिरहेको, वा पुन: प्रयास गरिरहेको हुन सक्छ।
पुनः पठाउनु अघि केही मिनेट पर्खनुहोस्। यदि सेवाले गतिविधि लग प्रदान गर्छ भने, त्यसले प्रमाणीकरण अनुरोधलाई रेकर्ड गरेको छ कि छैन जाँच गर्नुहोस्। तपाईंले सञ्चालन गर्ने उत्पादनको लागि, प्राप्त इनबक्सलाई हेर्ने भन्दा अनुप्रयोग क्यू र मेल-प्रदाता घटनालाई निरीक्षण गर्नुहोस्।
एक पटक रिफ्रेश गर्नुहोस्, त्यसपछि सही सन्देश खोज्नुहोस्
हातले रिफ्रेश गर्नुहोस् र आगमन समय अनुसार क्रमबद्ध गर्नुहोस्। देखिने प्रीभ्यूमा केवल सेवाको नाम होइन, अपेक्षित प्रेषक र विषय खोज्नुहोस्। स्वचालित र मार्केटिङ इमेल विभिन्न सबडोमेन्सबाट आउन सक्छ।
यदि धेरै कोडहरू आउँछन् भने, नयाँतम अनुरोध प्रयोग गर्नुहोस्। धेरै प्रणालीहरूले प्रतिस्थापन जारी भएसँगै पुराना कोडहरू अमान्य बनाउँछन्।
प्रेषक समस्या र डोमेन समस्या अलग गर्नुहोस्
असम्बन्धित प्रदायकबाट उही ठेगानामा छोटो साधारण पाठ परीक्षण सन्देश पठाउनुहोस्।
- यदि परीक्षण सन्देश आउँछ भने, प्राप्त गर्ने डोमेन काम गरिरहेको छ र मूल प्रेषक ढिलाइ भएको, ठेगाना फिल्टर गरिएको, वा ह्यान्डअफ अघि असफल भएको हो।
- यदि कुनै सन्देश आउँदैन भने, डोमेन स्थिति र MX कन्फिगरेसन जाँच गर्नुहोस्।
- यदि एक प्रदायकबाट सन्देशहरू आउँछन् तर अर्को लगातार आउँदैन, रिपोर्ट गर्नु अघि प्रेषक, टाइमस्ट्याम्प, र कुनै बाउन्स विवरण सङ्कलन गर्नुहोस्।
कस्टम डोमेनको लागि, अनुमान बिना कस्टम-डोमेन MX सेटअप अनुसरण गर्नुहोस्। प्रत्यक्ष परीक्षणको क्रममा DNS अनियमित रूपमा परिवर्तन नगर्नुहोस्; प्रत्येक परिवर्तनले नयाँ प्रसारण विन्डो सिर्जना गर्छ।
सामान्य DNS विफलताहरू बुझ्नुहोस्
MX लुकअप अस्थायी रूपमा असफल हुन सक्छ किनभने रिजोल्भरले टाइमआउट गर्यो, प्राधिकृत नेमसर्भरहरू असहमत भए, DNSSEC मान्यकरण असफल भयो, वा रेकर्ड प्रसारित भएको छैन। “रेकर्ड फेला परेन” विशेष समयको विशेष लुकअपको नतिजा हो, रेकर्ड कहिल्यै अस्तित्वमा नथिएँ भन्ने प्रमाण होइन।
प्राधिकृत DNS प्रतिक्रिया क्वेरी गर्नुहोस् र वास्तविक लक्ष्यलाई GPTMail द्वारा देखाइएको लक्ष्यसँग तुलना गर्नुहोस्। यदि मिल्छ भने, पर्खेर पुन: प्रयास गर्नुहोस्। यदि मिल्दैन भने, प्राधिकृत रेकर्ड सुधार्नुहोस्।
सन्देश आउँछ तर कोड असफल हुन्छ भने
डेलिभरी र प्रमाणीकरण अलग प्रणालीहरू हुन्। कोड असफल हुन सक्छ किनभने:
- नयाँ कोडले यसलाई प्रतिस्थापन गर्यो;
- कोड ट्रान्जिटमा समाप्त भयो;
- यो अर्को ब्राउजर सत्र वा खातासँग सम्बन्धित छ;
- कोडसँग खाली स्थान (whitespace) पनि कपी गरियो;
- गन्तव्य पृष्ठले फरक वातावरण प्रयोग गरिरहेको छ;
- प्रेषकको घडी वा स्थिति गलत छ।
एक नयाँ कोड अनुरोध गर्नुहोस्, त्यो विशेष सन्देशको लागि पर्खनुहोस्, र एकपटक मात्र प्रयोग गर्नुहोस्। यदि असफल हुन्छ भने, अनुरोध समय र सन्देश समय सँगै रिपोर्ट गर्नुहोस्।
संक्षिप्त समर्थन रिपोर्ट
उपयोगी रिपोर्टहरूमा प्राप्तकर्ता ठेगाना, प्रेषक ठेगाना, विषय, UTC टाइमस्ट्याम्प, दोस्रो प्रेषक इनबक्समा पुगेको कि छैन, र प्रेषकले देखाएको ठ्याक्कै त्रुटि समावेश हुन्छ। सार्वजनिक रूपमा लगहरू साझा गर्नु अघि प्रमाणीकरण कोड र निजी लिङ्कहरू हटाउनुहोस्।
“इमेल छैन” जाँच गर्न कठिन हुन्छ। “सन्देश 14:03 UTC मा अनुरोध गरियो; दोस्रो प्रदायक 14:05 मा आयो; अपेक्षित प्रेषकले 14:15 सम्म कुनै सन्देश वा बाउन्स उत्पादन गरेन” असफल पक्षलाई पहिचान गर्छ।
कहिले पर्खनु बन्द गर्ने थाहा पाउनुहोस्
यदि खाता महत्त्वपूर्ण छ र सेवा अर्को प्रमाणीकरण विधि प्रदान गर्छ भने, त्यसलाई प्रयोग गर्नुहोस्। यदि साइनअप कम जोखिमको छ भने, नयाँ समर्थित ठेगाना सिर्जना गरी पुनः सुरु गर्नुहोस्। तपाईंले राख्न चाहनुभएको खाताको लागि अस्थायी इनबक्सलाई मात्र पुनः प्राप्ति मार्ग नबनाउनुहोस्।
व्यापक निर्णय मार्गदर्शिका टेम्पररी इमेल, राम्रोसँग प्रयोग गरियो हो।