Un formulario es una cadena, no una función aislada. El navegador envía una petición, WordPress valida y guarda los datos, una regla construye la notificación, el transporte la entrega a un proveedor y el sistema destinatario la filtra hasta un buzón.
Seguir una prueba identificada por todos esos traspasos muestra quién controla el punto roto y evita cambios especulativos.
Prepara un envío controlado
Usa un nombre sintético, una referencia única en el asunto o mensaje y ningún dato personal. Anota URL, hora exacta con zona horaria, navegador, ID del formulario y destinatario previsto.
No modifiques la configuración durante el rastreo. Utiliza otra referencia y hora en cada repetición para no confundir mensajes antiguos o páginas cacheadas con la prueba actual.
Si hay leads reales en riesgo, habilita temporalmente una vía de contacto alternativa y monitorizada.
Etapa 1: inspecciona la petición del navegador
Abre las herramientas del navegador, envía una vez y localiza la petición POST, AJAX o REST. Registra URL, estado y respuesta. Un 403 orienta hacia seguridad, nonce o CAPTCHA; un 500 exige buscar el error PHP o del servidor de esa hora; un timeout puede involucrar PHP, SMTP o límites de red.
El mensaje visual de éxito debe corresponder a una respuesta realmente correcta. Un error JavaScript o un recurso bloqueado puede impedir la petición aunque el botón parezca funcionar.
Oculta valores personales y tokens antes de compartir capturas.
Etapa 2: confirma el procesamiento de WordPress
Busca la entrada sintética en el plugin. Su existencia confirma buena parte de la ruta de petición, pero no la generación del correo. Si falta, revisa validación, logs del plugin, PHP, eventos de seguridad y errores de base de datos en el mismo minuto.
Verifica que pertenece al formulario actual y al sitio de producción. Los duplicados y copias de staging suelen tener ID o notificaciones diferentes.
No actives la visualización pública de errores en una web en producción.
Etapa 3: identifica la notificación
Determina qué regla debía ejecutarse para los valores enviados. Revisa si está activa, los tokens del destinatario, las condiciones, From y Reply-To.
Utiliza una dirección autenticada del dominio como From y la del visitante en Reply-To. Registra el ID de notificación y el destinatario previsto, conservando el mínimo contenido posible.
Si no se crea ninguna notificación, el fallo sigue en la lógica del formulario o plugin, no en el buzón destinatario.
Etapa 4: rastrea el correo en WordPress
Localiza el intento de wp_mail() o el trabajo de cola correspondiente. Un resultado falso o una excepción PHP requieren el error local exacto. Un resultado correcto solo significa que WordPress entregó el mensaje al transporte configurado.
Si existe una cola, anota creación, hora prevista, intentos y estado final. Comprueba WP-Cron o el programador real del servidor en vez de borrar trabajos pendientes.
Protege los registros y elimina los datos de diagnóstico cuando dejen de ser necesarios.
Etapa 5: consulta el proveedor SMTP
Busca por destinatario, hora y referencia. Registra si el proveedor aceptó, aplazó, rebotó, bloqueó o suprimió la dirección, además del message ID y el código redactado.
Revisa credenciales, cifrado y límites de envío únicamente si la evidencia apunta a esa etapa. Repetir pruebas sin control puede empeorar una limitación.
La aceptación del proveedor todavía no demuestra que el usuario viera el mensaje.
Etapa 6: sigue el sistema destinatario
Pide al administrador autorizado que busque en el gateway por message ID, remitente, destinatario y hora. Revisa cuarentena, reglas de transporte, alias, grupos y restricciones de buzones compartidos.
En una copia entregada, comprueba la alineación SPF, DKIM y DMARC. Dos dominios destinatarios pueden aplicar la misma autenticación de forma distinta.
Consulta rebotes en el Return-Path y no cambies los registros MX para reparar correo saliente.
Construye un registro de rastreo útil
Resume etapa, hora, identificador, resultado y responsable en una tabla. Excluye contraseñas, claves API y contenido real. La primera etapa ausente o fallida define la siguiente investigación.
Después de reparar, recorre otra vez toda la cadena con una referencia nueva. Confirma un éxito del navegador, una entrada, la notificación correcta, un mensaje aceptado y el buzón final.
Solicita una reparación urgente si intervienen varios proveedores, las evidencias se contradicen o los envíos son comercialmente críticos. Una buena resolución demuestra el traspaso que falló y el resultado final.