El formulario web dice “enviado”, pero el correo no llega: dónde revisar
Siga el recorrido de una consulta desde el formulario hasta el buzón. Qué revisar en From, Reply-To, la salida de correo y la respuesta.
La página muestra una confirmación y el visitante sigue con su día. En ventas, nadie recibe la consulta. Si el único registro era el correo, puede pasar tiempo antes de que alguien advierta la pérdida.
Una confirmación en pantalla no demuestra que el mensaje llegó al buzón. Hay que seguir el recorrido desde el formulario hasta la salida de correo y el sistema receptor. Cada etapa puede aceptar una solicitud sin garantizar la siguiente.
Localice la última etapa que sí tiene evidencia
Haga una prueba con datos ficticios, un asunto identificable y hora registrada. Compruebe primero si el formulario procesó la solicitud; luego si la aplicación intentó enviar; después si su proveedor aceptó ese envío; finalmente qué ocurrió en el destino.
No guarde contraseñas, contenido sensible o tokens en registros de depuración. Si la aplicación conserva consultas, revise quién puede verlas y por cuánto tiempo. Ese almacenamiento no debe activarse sin considerar los datos que recibe.
El visitante no debería convertirse en su remitente técnico
Un error frecuente es colocar la dirección del visitante en From. El servidor del sitio termina intentando enviar como si fuera el proveedor de esa persona. Eso puede fallar la autenticación.
Utilice una identidad de envío autorizada del dominio configurado y, cuando corresponda, la dirección del visitante en Reply-To. Contact Form 7 documenta el uso de un remitente del dominio del sitio y explica por qué una identidad ajena puede parecer suplantación. La sintaxis exacta depende del formulario utilizado.
Validar los campos también importa: no permita que entradas del usuario se conviertan sin control en cabeceras. Si no conoce cómo lo hace su herramienta, encargue la revisión a quien mantiene la aplicación.
SMTP no es una garantía por instalar un complemento
Una salida autenticada puede aportar una ruta controlada, pero debe estar bien configurada. Revise servidor, puerto, cifrado, método de autenticación y permisos según la documentación del proveedor. No desactive la validación del certificado para que una prueba pase.
Guarde las credenciales en el mecanismo previsto por la aplicación, no en una página pública ni en el repositorio. Si se utiliza un servicio mediante API, proteja también su clave y limite su alcance cuando sea posible.
Cuando el proveedor acepte el mensaje, conserve el identificador de seguimiento en el sistema autorizado. Si después hay un rebote o una cuarentena, esa evidencia ayudará a relacionar el formulario con el resultado final.
Pruebe una consulta y su respuesta
No cierre el caso al ver el mensaje en una bandeja. Responda a la prueba y compruebe que la respuesta se dirige al lugar esperado. Pruebe destinos autorizados representativos, sin convertirlo en un envío masivo.
Si el correo llega a spam, continúe con el diagnóstico de autenticación y clasificación. Si hay rechazo, guarde el código completo. Si la aplicación ni siquiera intentó enviarlo, cambiar el DNS probablemente no resolverá esa etapa.
El recorrido termina cuando alguien puede atender la consulta
Asigne un responsable para revisar errores y defina cómo detectar que el formulario dejó de funcionar. Un mensaje de prueba programado y controlado puede ser útil si el equipo sabe quién lo revisa; generar pruebas sin seguimiento no aporta vigilancia real.
