Apabila e-mel pengesahan lewat, butang hantar semula terasa seperti jawapan yang jelas. Ia sering memperburuk keadaan: beberapa mesej tiba serentak, hanya kod terbaru yang sah, dan tiada siapa yang tahu permintaan mana yang menghasilkan mesej mana.
Anggap penghantaran sebagai satu urutan titik pemeriksaan. Cari titik pemeriksaan terakhir yang pasti berjaya, kemudian periksa yang berikutnya.
Pertama, bekukan bukti
Sebelum meminta mesej lain, catat:
- alamat penerima yang tepat;
- masa anda menekan hantar;
- nama penghantar atau perkhidmatan;
- sama ada halaman melaporkan kejayaan;
- sama ada ini permintaan pertama atau hantar semula;
- masa luput yang dijangka, jika ditunjukkan.
Biarkan halaman penghantar terbuka. Kesilapan taip yang ditemui dua minit kemudian lebih mudah diperbetulkan apabila borang asal masih mengandungi nilai yang dihantar.
Periksa alamat, bukan ingatan anda
Bandingkan alamat yang dihantar dengan alamat yang dipaparkan oleh GPTMail. Periksa bahagian tempatan, setiap titik atau digit, dan akhiran domain. Beri perhatian khusus apabila beberapa tab peti masuk dibuka atau apabila anda baru-baru ini menukar domain yang dipilih.
Kemudian sahkan bahawa domain tersebut aktif pada halaman domain. Sesebuah alamat boleh sah secara sintaks tetapi domainnya dinyahaktifkan atau tidak lagi diarahkan ke GPTMail.
Jika laman web menolak alamat sebelum dihantar, belum ada masalah penghantaran. Jana alamat lain yang disokong dan hantar semula.
Sahkan penghantar benar-benar memulakan penghantaran
Mesej kejayaan pada laman web kadang-kadang hanya bermakna satu kerja latar belakang telah dicipta. Penghantar mungkin masih berada dalam barisan, menghadapi had kadar, atau mencuba semula e-mel.
Tunggu beberapa minit sebelum menghantar semula. Jika perkhidmatan menawarkan log aktiviti, periksa sama ada ia merekod permintaan pengesahan. Untuk produk yang anda uruskan, semak barisan aplikasi dan peristiwa pembekal e-mel daripada hanya menatap peti masuk penerima.
Segarkan sekali, kemudian cari mesej yang betul
Gunakan segaran manual dan susun mengikut masa ketibaan. Cari penghantar dan subjek yang dijangka, bukan hanya nama perkhidmatan dalam pratonton yang kelihatan. E-mel automatik dan pemasaran boleh datang dari subdomain yang berbeza.
Jika beberapa kod tiba, gunakan permintaan yang paling baru. Banyak sistem membatalkan kod terdahulu sebaik sahaja pengganti dikeluarkan.
Pisahkan masalah penghantar daripada masalah domain
Hantar mesej ujian teks ringkas ke alamat yang sama daripada pembekal yang tidak berkaitan.
- Jika ujian tiba, domain penerima berfungsi dan penghantar asal mengalami kelewatan, menapis alamat, atau gagal sebelum penyerahan.
- Jika tiada mesej yang tiba, sahkan status domain dan konfigurasi MX.
- Jika mesej daripada satu pembekal tiba tetapi yang lain konsisten tidak, kumpulkan maklumat penghantar, cap masa, dan sebarang butiran pantulan sebelum melaporkannya.
Untuk domain tersuai, ikuti Penyiapan MX Domain Tersuai Tanpa Teka-Teki. Jangan ubah DNS secara rawak semasa ujian langsung; setiap perubahan mencipta tetingkap penyebaran baru.
Fahami kegagalan DNS biasa
Carian MX mungkin gagal sementara kerana penyelesai melebihi masa, pelayan nama autoritatif tidak bersetuju, pengesahan DNSSEC gagal, atau rekod belum tersebar. “Tiada rekod dikesan” adalah hasil daripada carian khusus pada masa tertentu, bukan bukti bahawa rekod tidak pernah wujud.
Tanya respons DNS autoritatif dan bandingkan sasaran sebenar dengan sasaran yang dipaparkan oleh GPTMail. Jika serasi, tunggu dan cuba lagi. Jika tidak serasi, betulkan rekod autoritatif.
Apabila mesej tiba tetapi kod gagal
Penghantaran dan pengesahan adalah sistem berasingan. Kod boleh gagal kerana:
- kod yang lebih baru menggantikannya;
- kod telah luput semasa penghantaran;
- kod itu milik sesi pelayar atau akaun lain;
- ruang putih disalin bersama kod;
- halaman destinasi menggunakan persekitaran yang berbeza;
- jam atau keadaan penghantar tidak betul.
Minta satu kod baru, tunggu mesej khusus itu, dan gunakan sekali sahaja. Jika gagal, laporkan masa permintaan dan masa mesej bersama-sama.
Laporan sokongan ringkas
Laporan yang berguna termasuk alamat penerima, alamat penghantar, subjek, cap masa UTC, sama ada penghantar kedua sampai ke peti masuk, dan ralat tepat yang ditunjukkan oleh penghantar. Buang kod pengesahan dan pautan peribadi sebelum berkongsi log secara terbuka.
“Tiada e-mel” sukar disiasat. “Mesej diminta pada 14:03 UTC; pembekal kedua tiba pada 14:05; penghantar dijangka tidak menghasilkan mesej atau pantulan menjelang 14:15” mengenal pasti bahagian yang gagal.
Ketahui bila harus berhenti menunggu
Jika akaun penting dan perkhidmatan menawarkan kaedah pengesahan lain, gunakannya. Jika pendaftaran berisiko rendah, jana alamat sokongan baru dan mulakan semula. Jangan jadikan peti masuk sementara satu-satunya laluan pemulihan untuk akaun yang anda ingin simpan.
Panduan keputusan yang lebih luas ialah E-mel Sementara, Digunakan dengan Baik.