El formulario funciona pero no llegan los correos: guía de diagnóstico

La respuesta corta: localiza el último punto con evidencia

Envía una prueba identificable y responde en orden: ¿el navegador recibió éxito real?, ¿el servidor guardó o procesó la solicitud?, ¿intentó enviar?, ¿el proveedor aceptó el mensaje?, ¿el servidor receptor lo entregó, rechazó o filtró? Detente en el primer salto sin prueba. Cambiar el destinatario, el plugin o el texto a la vez destruye la comparación y puede ocultar una pérdida intermitente.

Este fallo puede explicar una web con tráfico pero sin oportunidades. La guía sobre cómo diagnosticar visitas sin contactos separa la cadena comercial completa; aquí profundizamos en el tramo del formulario al buzón. Si el problema aparece tras un cambio amplio, revisa también el método para rediseñar sin perder SEO ni contactos. Antes de tocar DNS o filtros, captura una línea temporal en UTC o con zona indicada.

Dibuja la cadena real del envío

1. 01

   Navegador

   Valida, envía una solicitud y muestra el resultado que devuelve el servidor.

2. 02

   Aplicación

   Acepta datos, aplica protección antispam, registra un ID y solicita el envío.

3. 03

   Proveedor saliente

   Autentica el dominio, acepta o rechaza y comunica eventos posteriores.

4. 04

   Servidor receptor

   Evalúa reputación, autenticación y políticas; entrega, pone en cuarentena o rechaza.

5. 05

   Buzón y operación

   Aplica reglas, reenvíos y permisos; una persona debe ver y atender el contacto.

Anota producto, cuenta y propietario de cada etapa. Muchos equipos conocen el formulario y el buzón, pero ignoran qué servicio envía o quién recibe los rebotes. No copies mensajes con datos personales en tickets ni analítica. Un ID aleatorio, la hora, el dominio destinatario y un resultado técnico suelen bastar para correlacionar. Usa direcciones controladas de distintos proveedores para saber si el fallo afecta a un destino o a todos.

Verifica que la interfaz no prometa un éxito inexistente

Abre las herramientas de red, envía una prueba y revisa URL, método, código HTTP y cuerpo. Un 200 genérico puede envolver un error interno; un 202 puede significar aceptado para procesar, no entregado. Reproduce también dato inválido, token antispam vencido, doble clic, desconexión y espera prolongada. La pantalla solo debería confirmar cuando el sistema haya conservado la solicitud o haya completado el compromiso definido.

En el servidor busca el mismo ID. Distingue validación, persistencia y llamada al proveedor. Registra códigos y categorías, nunca contraseñas ni el contenido completo. Si no existe registro, revisa rutas, despliegue, variables y bloqueos previos. Si aparece dos veces, comprueba reintentos e idempotencia. Si el servidor falla pero la interfaz celebra, corrige primero ese contrato: el problema deja a la persona sin forma de saber que debe reintentar.

Comprueba proveedor, remitente y autenticación del dominio

Busca el ID del proveedor y su estado. Amazon SES, por ejemplo, documenta un proceso de envío con aceptación, escaneo, entrega, rebote y queja. Aceptado significa que el proveedor asumió el mensaje; todavía puede producirse un rebote. Consulta eventos y supresiones, verifica que la dirección remitente esté permitida y evita usar como From el correo escrito por el visitante: suele romper alineación y reputación. Úsalo como Reply-To tras validarlo.

Revisa SPF, DKIM y DMARC para el dominio y proveedor efectivos. Google exige autenticación a quienes envían a cuentas Gmail y publica requisitos adicionales para grandes volúmenes en sus directrices para remitentes. No copies registros DNS de una guía sin conocer todos los emisores autorizados: un SPF duplicado o una política DMARC adelantada puede empeorar la entrega. Documenta el estado observado y coordina el cambio con quien administra el dominio.

Investiga el receptor sin limitarte a la carpeta spam

Busca por rango horario, remitente, destinatario e ID de mensaje. En Microsoft 365, la traza de mensajes de Exchange Online muestra si un mensaje fue recibido, rechazado, diferido o entregado y qué acciones se aplicaron. En otros proveedores usa la función equivalente. Revisa cuarentena, reglas de transporte, bandeja prioritaria, reenvíos, grupos, buzones compartidos y reglas personales.

Prueba un buzón del mismo dominio y otro externo. Si uno recibe y otro no, compara las respuestas del receptor. Si ninguno recibe pero el proveedor marca entrega, confirma destinatarios y reenvíos antes de culpar a reputación. Un mensaje puede entregarse a un grupo sin que el miembro esperado tenga permisos o suscripción. Guarda evidencia de la prueba, pero limita el acceso porque las trazas pueden contener direcciones y metadatos operativos.

Convierte el formulario en un canal observable y recuperable

Guarda el contacto en un sistema controlado antes de depender del aviso, crea alertas sobre fallos y prueba periódicamente con datos ficticios identificados. Define un procedimiento para recuperar solicitudes aceptadas durante una incidencia y una bandeja con responsable y sustitución. La confirmación al visitante no debe incluir información sensible ni prometer un plazo que el equipo no pueda cumplir. Si la revisión revela fallos de interfaz, backend, medición y seguimiento, el servicio de desarrollo web orientado a conversión permite tratarlos como un único recorrido verificable.