El mensaje de éxito solo demuestra que el navegador recibió una respuesta positiva de la aplicación. No prueba que WordPress generara la notificación, que SMTP la aceptara ni que el buzón destinatario la entregara.
Conserva una prueba y sigue cada entrega sin cambiar a la vez formulario y DNS.
Crea una prueba controlada
Usa un nombre claramente marcado, asunto o referencia única y texto no sensible. Anota hora con zona, URL, destinatario y navegador.
No envíes repetidamente una consulta real: puede duplicar entradas y confundir al equipo comercial. Prueba como visitante sin sesión en una ventana privada y comprueba si se guarda una entrada.
Confirma que WordPress recibió el formulario
Revisa Entries o Submissions del plugin. Si no existe entrada, el éxito puede mostrarse antes de guardar o venir de caché o JavaScript.
Si aparecen todos los campos, el recorrido navegador-WordPress funcionó. Pasa a la generación de la notificación. Consulta logs por la hora exacta sin almacenar el contenido personal completo.
Revisa las reglas de notificación
Confirma que la notificación está habilitada, que el destinatario es correcto y que la lógica condicional se ejecuta para esas respuestas.
Comprueba etiquetas dinámicas en To, From, Reply-To y asunto. Un token mal escrito puede crear una cabecera vacía aunque la entrada se guarde.
No uses el email arbitrario del visitante como From. Envía desde una dirección del dominio y coloca al visitante en Reply-To.
Captura el evento de correo
Usa temporalmente un registro fiable de correo para guardar hora, destinatario, asunto, cabeceras y resultado. Redacta cuerpo y adjuntos al compartir.
wp_mail() puede indicar éxito cuando el transporte local acepta el mensaje, sin garantizar la entrega. Si no aparece evento, inspecciona el hook del formulario; si aparece, sigue la evidencia SMTP.
Comprueba la aceptación SMTP
Consulta el plugin o proveedor buscando autenticación, conexión, message ID y código. Distingue si:
WordPress no llamó al correo
falló conexión o autenticación
el proveedor aceptó
rechazó remitente, destinatario o límite
aceptó y luego generó un reboteNo publiques usuarios SMTP, tokens ni cabeceras completas.
Sigue el lado del destinatario
Si el proveedor aceptó, busca en spam, cuarentena, reglas y alias. El administrador de correo empresarial debe rastrear por message ID, remitente y hora.
Probar solo Gmail personal no demuestra la entrega al dominio corporativo. Revisa también los rebotes en el Return-Path autenticado.
Verifica la autenticación del remitente
En un mensaje entregado, revisa SPF, DKIM y DMARC para el proveedor real y el dominio From.
No crees un segundo SPF. Integra los remitentes autorizados en una única política válida siguiendo al proveedor. Los MX controlan recepción; no autorizan automáticamente el envío web.
Repara únicamente el salto fallido
Corrige la notificación, credencial SMTP, alineación, límite o regla del buzón identificados. Guarda rollback de plugin y DNS.
Después envía una sola prueba marcada y demuestra entrada, log, aceptación y buzón final. Comprueba Reply-To y cualquier automatización comercial.
Protege los leads durante el diagnóstico
Si se guardan entradas, revísalas o expórtalas de forma segura para no olvidar consultas. Restringe acceso porque contienen datos personales. No las pegues en tickets públicos.
Si no se guardan, publica temporalmente un email o teléfono monitorizado. Explica la limitación en vez de mostrar un éxito que no es fiable. Elimina luego los datos de prueba según la retención.
Cuándo pedir una reparación urgente
Solicita ayuda si se pierden leads, los registros discrepan o la entrega varía por destinatario. Facilita URL, hora, plugin y error no sensible, nunca contraseñas.
Una reparación fiable demuestra que el mensaje llegó al buzón previsto, no que apareció un aviso verde.