WordPress dice que el formulario se envió, pero el correo no llega
Sigue una solicitud desde el formulario hasta el destinatario. Distingue confirmación visual, procesamiento del envío, aceptación del proveedor y entrega real.
Una confirmación de envío en WordPress no demuestra que el mensaje haya llegado al buzón. Hay que seguir el recorrido de la solicitud: el formulario la acepta, la aplicación prepara una notificación, un sistema intenta enviarla y el destino decide cómo tratarla.
La referencia de wp_mail aclara que un resultado satisfactorio significa que el método pudo procesar la petición sin errores, no que el destinatario recibiera el correo. Además, algunos formularios usan colas o servicios propios: revisa cómo funciona el tuyo antes de interpretar el mensaje de pantalla.
1. Elegir una prueba que puedas seguir
Envía una solicitud ficticia con una referencia reconocible, por ejemplo «Prueba formulario 28 octubre», y anota hora, formulario y destinatario esperado. Evita datos personales y no generes decenas de solicitudes repetidas para intentar forzar la entrega.
Comprueba si el plugin conserva entradas. Si existe ese registro, permite distinguir una solicitud recibida de una notificación ausente. Su ausencia no demuestra pérdida si el formulario no estaba configurado para guardarlas. Tampoco actives almacenamiento indefinido sin definir acceso y conservación de datos.
2. Revisar el destinatario y las condiciones de notificación
Localiza la configuración de ese formulario, no la de otro que tenga un nombre parecido. Comprueba la dirección de destino y si hay reglas que cambien el receptor según una selección del visitante.
Algunos recorridos incluyen una notificación al negocio y otra al solicitante. Que una llegue no confirma que la otra tenga el destinatario o las condiciones correctas. Prueba cada recorrido previsto y comprueba alias, reenvíos o filtros del buzón receptor.
Como ejemplo hipotético, un formulario puede guardar correctamente el contacto y enviar el aviso a una dirección de pruebas que quedó tras el desarrollo. Instalar un nuevo plugin de correo no solucionaría ese destinatario equivocado.
3. Distinguir el remitente de la dirección para responder
No siempre conviene utilizar el correo introducido por el visitante como remitente técnico. En Contact Form 7, la documentación indica utilizar una dirección del dominio del sitio en From y permite configurar Reply-To mediante las cabeceras adicionales.
El transporte elegido puede exigir un remitente o dominio verificado. Comprueba sus condiciones y utiliza la dirección del visitante para responder cuando corresponda, no para aparentar un envío autorizado desde un dominio ajeno.
Para interpretar autenticación y alineación, consulta qué revisar en SPF, DKIM y DMARC. Un cambio de formulario no sustituye la configuración que necesita el proveedor de salida.
4. Identificar cómo sale realmente el mensaje
Confirma si utiliza el correo del servidor, un plugin SMTP, una API o una cola. Si existen varios componentes que modifican el envío, revisa cuál actúa sobre esa solicitud antes de añadir otro.
Si el problema comenzó después de mover la web, comprueba configuración y acceso del nuevo entorno al proveedor de salida. Un mensaje de autenticación apunta a un recorrido distinto de un timeout de conexión o una dirección rechazada. No compartas claves ni captures mensajes completos en tickets públicos.
5. Comparar el formulario con una prueba del transporte
Si el sistema permite un envío de prueba, utilízalo con una dirección autorizada y correlaciona el resultado. Que esa prueba funcione y el formulario no lo haga orienta a revisar diferencias de remitente, destinatario, adjuntos, reglas o ejecución.
Si ambas fallan, investiga primero el transporte o el proveedor. Si el envío queda en una cola, revisa cuándo se procesa y qué error conserva. Evita reintentar indefinidamente una notificación de estado incierto que podría terminar duplicándose.
6. Comprobar aceptación, rebote y buzón
Busca la referencia de prueba en los registros disponibles y distingue intento, aceptación y resultado posterior. Revisa spam, cuarentena, reglas y rebotes. Un envío aceptado por un servicio intermedio no prueba por sí solo su llegada al destino final.
Si todo el correo empresarial falla después de cambiar la zona, sigue el diagnóstico de DNS y correo. Aquí la investigación se centra en el formulario, no en modificar toda la recepción del dominio.
Cerrar el problema sin perder las solicitudes pendientes
Tras corregir la causa, repite una prueba completa y confirma quién recibe qué. Revisa las entradas pendientes si el formulario las conserva y acuerda cómo atenderlas sin enviar duplicados a los clientes.
Podemos investigar el recorrido con un diagnóstico WordPress, mantener su configuración mediante mantenimiento WordPress o corregir los registros necesarios en DNS y dominios. La solución debe dejar un envío comprobable, no solo una confirmación visual.