Kiam konfirma retpoŝto estas malfrua, la butono resendi ŝajnas esti la evidenta respondo. Ĝi ofte plimalbonigas la situacion: pluraj mesaĝoj alvenas samtempe, nur la plej nova kodo restas valida, kaj neniu scias kiu peto produktis kiu mesaĝo.
Traktu liveron kiel sekvencon de kontrolpunktoj. Trovu la lastan kontrolpunkton kiu certe sukcesis, kaj poste ekzamenu la sekvan.
Unue, frosti la pruvoj
Antaŭ peti alian mesaĝon, registru:
- la ekzaktan adreson de la ricevanto;
- la tempon kiam vi premis submeti;
- la nomon de la sendanto aŭ servo;
- ĉu la paĝo raportis sukceson;
- ĉu ĉi tio estas la unua peto aŭ resendo;
- la atendatan senvalidiĝtempodaŭron, se montrita.
Tenu la paĝon de la sendanto malferma. Tajperaro malkovrita du minutoj poste estas pli facile korekti kiam la originala formularo ankoraŭ enhavas la submetitan valoron.
Kontrolu la adreson, ne vian memoron
Komparu la submetitan adreson kun la adreso montrita de GPTMail. Kontrolu la lokan parton, ĉiun punkton aŭ cifron, kaj la domajnan sufikson. Atentu speciale kiam pluraj enirkestaj langetoj estas malfermitaj aŭ kiam vi lastatempe ŝanĝis la elektitan domajnon.
Poste konfirmu ke la domajno estas aktiva sur la domajna paĝo. Adreso povas esti sintakse valida dum ĝia domajno estas malŝaltita aŭ ne plu direktita al GPTMail.
Se la retejo rifuzas la adreson antaŭ sendo, ankoraŭ ne ekzistas livera problemo. Generu alian subtenatan adreson kaj submetu denove.
Konfirmu ke la sendanto vere komencis liveron
Sukcesa mesaĝo sur retejo kelkfoje signifas nur ke fona tasko estis kreita. La sendanto eble ankoraŭ metas en vico, limigas rapidecon, aŭ reprovas la retpoŝton.
Atendu kelkajn minutojn antaŭ resendi. Se la servo ofertas aktivecan protokolon, kontrolu ĉu ĝi registras la konfirman peton. Por produkto kiun vi administras, ekzamenu la aplikaĵan vicon kaj la retpoŝt-provizantan eventon anstataŭ rigardi la ricevan enirkeston.
Refreŝigu unufoje, poste serĉu la ĝustan mesaĝon
Uzu manan refreŝigon kaj ordigu laŭ alveno‑tempo. Serĉu la atendatan sendinton kaj temon, ne nur la servonomon en la videbla antaŭrigardo. Aŭtomata kaj merkatuma retpoŝto povas veni de diversaj subdomajnoj.
Se pluraj kodoj alvenas, uzu la plej novan peton. Multaj sistemoj nuligas pli fruaj kodoj tuj kiam anstataŭaĵo estas eldonita.
Disigu sendanto‑problemon de domajno‑problemo
Sendu mallongan simpltekstan testmesaĝon al la sama adreso de nespeca provizanto.
- Se la testmesaĝo alvenas, la riceva domajno funkcias kaj la originala sendanto estas prokrastita, filtranta la adreson, aŭ malsukcesanta antaŭ transdono.
- Se neniu mesaĝo alvenas, kontrolu la domajnan statuson kaj MX‑agordon.
- Se mesaĝoj de unu provizanto alvenas sed alia konstante ne, kolektu la sendinton, tempomarkojn, kaj iujn bounce‑detalejojn antaŭ raporti ĝin.
Por propra domajno, sekvu Propra‑Domajno MX Agordo Sen Divenado. Ne ŝanĝu DNS hazarde dum viva testado; ĉiu ŝanĝo kreas novan propagadan fenestron.
Komprenu oftajn DNS‑malsukciojn
MX‑serĉo povas provizore malsukcesi ĉar rezolvanto elĉerpis tempon, aŭtoritativaj nomserviloj ne konsentis, DNSSEC‑validigo malsukcesis, aŭ la registro ne estis propagita. “Neniu registro detektita” estas rezulto de specifa serĉo je specifa tempo, ne pruvo ke la registro neniam ekzistis.
Demandu la aŭtoritativan DNS‑responson kaj komparu la realan celon kun la celo montrita de GPTMail. Se ili kongruas, atendu kaj reprovu. Se ili ne kongruas, korektu la aŭtoritativan registron.
Kiam la mesaĝo alvenas sed la kodo malsukcesas
Liverado kaj konfirmado estas apartaj sistemoj. Kodo povas malsukcesi ĉar:
- pli nova kodo anstataŭigis ĝin;
- la kodo eksvalidiĝis dum transiro;
- ĝi apartenas al alia retumila seanco aŭ konto;
- spacetoj estis kopiitaj kun la kodo;
- la cela paĝo uzas alian medion;
- la horloĝo aŭ stato de la sendanto estas malĝusta.
Petu unu freŝan kodon, atendu tiun specifan mesaĝon, kaj uzu ĝin unufoje. Se ĝi malsukcesas, raportu la petotempon kaj mesaĝtempon kune.
Konciza subtenraporto
Utilaj raportoj inkluzivas la adreson de la ricevanto, la adreson de la sendanto, la temon, UTC‑tempomarkojn, ĉu dua sendanto atingis la enirkeston, kaj la ĝustan eraron montritan de la sendanto. Forigu konfirmajn kodojn kaj privatajn ligilojn antaŭ publikigi protokolojn.
“Neniu retpoŝto” estas malfacile esplorota. “Mesaĝo petita je 14:03 UTC; dua provizanto alvenis je 14:05; atendata sendinto ne produktis mesaĝon aŭ bounce ĝis 14:15” identigas la malsukcantan flankon.
Sciu kiam ĉesi atendi
Se la konto gravas kaj la servo ofertas alian konfirman metodon, uzu ĝin. Se la registriĝo estas malalta risko, generu freŝan subtenatan adreson kaj komencu denove. Ne igu provizoran enirkeston la sola resta vojo por konto kiun vi intencas teni.
La pli vasta decidgvidilo estas Provizora Retpoŝto, Bone Uzata.