gl

Correo de verificación que non chega: atopar o paso roto

Diagnostica un correo de verificación que falta sen pulsar repetidamente reenviar. Esta lista de comprobación separa os erros de enderezo, atrasos do remitente, problemas de DNS, filtrado e códigos caducados.

Jul 17, 2026

Rastrexando un correo de verificación atrasado a través de cada punto de control de entrega

Cando un correo de verificación chega tarde, o botón de reenviar parece a resposta obvia. A miúdo empeora a situación: varios mensaxes chegan ao mesmo tempo, só o código máis novo segue sendo válido, e ninguén sabe que solicitude produciu que mensaxe.

Trata a entrega como unha secuencia de puntos de control. Atopa o último punto de control que definitivamente tivo éxito e, a seguir, inspecciona o seguinte.

Primeiro, conxela as evidencias

Antes de solicitar outro mensaxe, rexistra:

  • o enderezo exacto do destinatario;
  • a hora en que pulsaches enviar;
  • o nome do remitente ou servizo;
  • se a páxina informou de éxito;
  • se se trata da primeira solicitude ou de un reenvío;
  • o tempo de caducidade esperado, se se mostra.

Mantén a páxina do remitente aberta. Un erro tipográfico descubierto dous minutos despois é máis fácil de corrixir cando o formulario orixinal aínda contén o valor enviado.

Comproba o enderezo, non a túa memoria

Compara o enderezo enviado co enderezo que mostra GPTMail. Verifica a parte local, cada punto ou díxito, e o sufixo do dominio. Presta especial atención cando hai varias pestanas da caixa de correo abertas ou cando recentemente cambiaches o dominio seleccionado.

Despois confirma que o dominio está activo na páxina de dominios. Un enderezo pode ser sintácticamente válido mentres o seu dominio está desactivado ou xa non está dirixido a GPTMail.

Se o sitio web rexeita o enderezo antes de envialo, aínda non hai problema de entrega. Xera outro enderezo compatible e envía de novo.

Confirma que o remitente realmente iniciou a entrega

Unha mensaxe de éxito nun sitio web a veces só significa que se creou unha tarefa en segundo plano. O remitente pode seguir encolando, limitando a taxa ou reintentando o correo.

Espera uns minutos antes de reenviar. Se o servizo ofrece un rexistro de actividade, verifica se registra a solicitude de verificación. Para un produto que operas, inspecciona a cola da aplicación e o evento do provedor de correo en vez de mirar fixamente a caixa de entrada receptora.

Refresca unha vez, logo busca a mensaxe correcta

Utiliza a actualización manual e ordena por hora de chegada. Busca o remitente e asunto esperados, non só o nome do servizo na vista previa visible. O correo automatizado e de marketing pode vir de subdominios diferentes.

Se chegan varios códigos, usa a solicitude máis nova. Moitos sistemas invalidan os códigos anteriores tan pronto como se emite un substituto.

Separa un problema do remitente dun problema do dominio

Envía unha mensaxe de proba curta en texto plano ao mesmo enderezo dende un provedor non relacionado.

  • Se a proba chega, o dominio receptor funciona e o remitente orixinal está atrasado, filtrando o enderezo ou fallando antes da entrega.
  • Se ningunha das mensaxes chega, verifica o estado do dominio e a configuración MX.
  • Se as mensaxes dun provedor chegan pero outro consistentemente non, recolle o remitente, as marcas de tempo e calquera detalle de rebote antes de informalo.

Para un dominio personalizado, segue Configuración MX de dominio personalizado sen adiviños. Non cambies o DNS aleatoriamente durante unha proba en directo; cada cambio crea unha nova xanela de propagación.

Comprende os fallos DNS máis comúns

Unha consulta MX pode fallar temporalmente porque un resolvedor caducou, os servidores de nomes autoritativos non concordaron, a validación DNSSEC fallou ou o rexistro non se propagou. “Non se detectou rexistro” é un resultado dunha consulta específica nun momento concreto, non unha proba de que o rexistro nunca existiu.

Consulta a resposta DNS autoritativa e compara o destino real co destino mostrado por GPTMail. Se coinciden, espera e volve a intentar. Se non coinciden, corrixe o rexistro autoritativo.

Cando a mensaxe chega pero o código falla

A entrega e a verificación son sistemas separados. Un código pode fallar porque:

  • un código máis novo o substituiu;
  • o código caducou en tránsito;
  • pertence a outra sesión de navegador ou conta;
  • copiouse espazo en branco co código;
  • a páxina de destino está usando un entorno diferente;
  • o reloxo ou estado do remitente está incorrecto.

Solicita un código novo, espera esa mensaxe específica e úsao unha única vez. Se falla, informa da hora da solicitude e da hora da mensaxe xuntas.

Un informe de soporte conciso

Os informes útiles inclúen o enderezo do destinatario, o enderezo do remitente, o asunto, as marcas de tempo en UTC, se un segundo remitente chegou á caixa de entrada e o erro exacto mostrado polo remitente. Elimina os códigos de verificación e as ligazóns privadas antes de compartir os rexistros publicamente.

«Sen correo» é difícil de investigar. «Mensaxe solicitada ás 14:03 UTC; segundo provedor chegou ás 14:05; remitente esperado non produciu mensaxe ou rebote antes das 14:15» identifica o lado con fallo.

Sabe cando deixar de esperar

Se a conta é importante e o servizo ofrece outro método de verificación, úsao. Se o rexistro é de baixo risco, xera un novo enderezo compatible e comeza de novo. Non conviertas unha caixa de correo temporal na única vía de recuperación para unha conta que pretendes manter.

A guía de decisión máis ampla é Correo temporal, ben usado.

GPTMail