Rellenas el formulario de contacto de tu web, pulsas Enviar y aparece el mensaje de confirmación.
Todo parece correcto.
Pero el correo nunca llega.
Este es uno de los fallos más incómodos de una web empresarial porque puede pasar desapercibido durante días. La página sigue funcionando, WordPress no muestra un error evidente y el visitante cree que ha contactado contigo.
Tú, mientras tanto, puedes estar perdiendo consultas, solicitudes de presupuesto o reservas sin saberlo.
La primera idea suele ser revisar el plugin del formulario o instalar SMTP. Es razonable, pero antes conviene entender algo fundamental:
que WordPress haya procesado un correo no significa que ese correo haya llegado al destinatario.
La propia documentación de WordPress lo advierte al explicar wp_mail(): que la función devuelva true solo indica que el sistema utilizado ha podido procesar la solicitud sin errores. No confirma que el mensaje haya sido recibido.
Por eso, cuando un formulario deja de enviar correos, hay que averiguar en qué punto de la cadena se está perdiendo el mensaje.
Cuando alguien completa un formulario en WordPress suelen intervenir varias capas.
Simplificando mucho:
Por eso, ver en pantalla:
Tu mensaje se ha enviado correctamente.
no demuestra necesariamente que el proceso haya terminado bien.
Puede demostrar únicamente que el formulario ha realizado correctamente su parte del trabajo.
Esta distinción evita perder horas investigando en el sitio equivocado.
Antes de cambiar configuraciones de correo, averigua si WordPress está recibiendo realmente las solicitudes.
Algunos plugins permiten almacenar los formularios enviados en la propia base de datos. Otros necesitan una extensión adicional o no guardan los mensajes.
Si el envío aparece registrado correctamente pero nunca llega por email, ya tienes una pista importante:
el formulario probablemente está recogiendo los datos y el problema se encuentra después.
Si tampoco queda registrado, la investigación debería empezar antes: configuración del formulario, validaciones, JavaScript, conflictos entre plugins, errores PHP o la propia petición utilizada para enviar los datos.
No instales cinco herramientas de correo para solucionar un formulario que en realidad ni siquiera está procesando la solicitud.
No utilices como única referencia el mensaje de un cliente que afirma que «el formulario no funciona».
Reproduce el problema.
Envía una prueba y anota:
Este pequeño registro puede ahorrar mucho tiempo después.
Por ejemplo, si los mensajes llegan a Gmail pero no a una cuenta corporativa concreta, el diagnóstico es muy distinto al de un formulario cuyos correos no salen nunca del servidor.
Aquí aparecen bastantes problemas.
Supongamos que tu web es:
empresa.es
pero el formulario intenta enviar mensajes como:
cliente@gmail.com
porque utiliza como remitente la dirección que acaba de escribir el visitante.
A primera vista parece lógico: quieres que el mensaje parezca proceder del cliente.
Sin embargo, técnicamente estás haciendo que tu servidor envíe un correo afirmando que procede de un dominio que no controla.
Es preferible que el correo salga utilizando una dirección perteneciente a tu propio dominio, por ejemplo:
web@empresa.es
y utilizar la dirección introducida por el visitante como Reply-To.
Así puedes responder al cliente sin hacer pasar al servidor de tu web por Gmail, Outlook u otro dominio ajeno.
Revisa por tanto los campos:
Un cambio en el plugin, una migración o una modificación de estas opciones puede hacer que una configuración que llevaba años aparentemente funcionando empiece a dar problemas.
Una solución habitual consiste en configurar WordPress para enviar mediante SMTP o mediante la API de un proveedor de correo.
Tiene sentido.
En lugar de depender directamente de la configuración de correo del servidor web, WordPress utiliza un sistema específicamente preparado para enviar mensajes.
Pero conviene evitar una conclusión demasiado habitual:
«Tengo SMTP configurado, así que los correos tienen que llegar».
No necesariamente.
También pueden fallar:
Incluso una configuración que funcionó correctamente durante meses puede dejar de hacerlo si cambia alguno de esos elementos.
Lo importante no es poder decir que «hay SMTP».
Lo importante es comprobar qué sucede con un mensaje concreto desde que WordPress intenta enviarlo hasta que el servidor receptor lo procesa.
Estos tres términos aparecen continuamente cuando hay problemas de correo, pero no significan lo mismo.
SPF permite especificar qué servidores están autorizados para enviar correo en nombre de un dominio.
Si utilizas diferentes sistemas —Microsoft 365, Google Workspace, una plataforma de newsletters o un servicio transaccional— la configuración debe reflejar correctamente las fuentes autorizadas.
DKIM añade una firma criptográfica al mensaje.
El servidor receptor puede utilizarla para verificar que determinadas partes del correo no han sido modificadas y comprobar qué dominio lo firmó.
DMARC utiliza SPF y DKIM, junto con la alineación de dominios, para establecer cómo deben tratarse determinados mensajes que no superen las comprobaciones.
Microsoft explica estos mecanismos como componentes relacionados de la autenticación de correo electrónico.
Por tanto, tener un registro SPF no significa automáticamente que todo esté bien configurado.
Tampoco «tener DMARC» demuestra que los mensajes generados por WordPress estén autenticándose correctamente.
Hay que comprobar el mensaje real.
Cuando el problema es intermitente, los registros son especialmente valiosos.
Dependiendo del sistema utilizado para enviar correo, puedes encontrar información como:
Si el proveedor te dice:
550 — rejected
tienes algo concreto que investigar.
Si únicamente sabes que:
«ayer un cliente dijo que no le llegó»
tienes muy poca información.
Este mismo principio sirve para otras incidencias de WordPress: diagnosticar antes de modificar. En nuestra guía sobre errores críticos en WordPress explicamos por qué un síntoma no debería confundirse con su causa.
Sí, conviene revisar la carpeta de correo no deseado.
Pero «mira en spam» no debería cerrar la investigación.
Hay mensajes que:
En esos casos no aparecerán simplemente en la carpeta Spam.
Si tienes acceso al servicio utilizado para enviar los mensajes, sus registros de entrega suelen aportar bastante más información que mirar únicamente la bandeja de entrada.
Hay otro error habitual al probar formularios.
Lo rellenas tú mismo.
Recibes el mensaje.
Concluyes:
«Funciona».
Has demostrado que ese envío concreto ha funcionado en ese momento.
Nada más.
No has demostrado necesariamente que:
Es la misma diferencia que existe entre tener una copia de seguridad y comprobar que realmente puede restaurarse. La explicamos en nuestra guía sobre cómo saber si las copias de seguridad de WordPress funcionan de verdad.
Una comprobación real debería evaluar la función que quieres proteger, no simplemente la existencia de la herramienta.
Un formulario de contacto es una de esas funciones que pueden romperse sin que la portada muestre nada extraño.
Actualizas WordPress, un plugin o PHP.
Abres la home.
Carga correctamente.
Das la actualización por terminada.
Pero eso no demuestra que sigan funcionando:
Por eso recomendamos definir las funciones críticas de una web y comprobarlas después de cambios relevantes. Lo explicamos con más detalle en cómo actualizar WordPress sin romper tu web.
Si trabajas con una instalación muy antigua, todavía es más importante realizar los cambios por fases y validar cada componente. En cómo actualizar un WordPress antiguo sin romperlo explicamos este procedimiento.
Hay una gran diferencia entre estos dos incidentes:
«La web está caída».
y:
«La web lleva ocho días funcionando perfectamente, pero ningún formulario está llegando».
El primero suele detectarse rápido.
El segundo puede durar bastante más.
Por eso, en webs que dependen de solicitudes comerciales, una revisión de mantenimiento no debería limitarse a comprobar que la página responde y que WordPress está actualizado.
Tiene sentido incluir también pruebas de las funciones que generan negocio.
Un mantenimiento de WordPress bien planteado debería prestar atención a ese tipo de funcionalidades críticas, no únicamente al número de plugins pendientes de actualizar.
Puedes utilizar este orden de diagnóstico:
Reproduce el problema y apunta la hora exacta.
Si existe el registro pero no hay email, continúa investigando la parte de correo.
Revisa los registros del plugin o del sistema de envío si están disponibles.
Verifica especialmente From y Reply-To.
Si utilizas SMTP o una API, confirma que la conexión y las credenciales siguen siendo válidas.
No basta con comprobar que existen registros DNS. Hay que verificar que sean coherentes con los sistemas que realmente envían correo para el dominio.
Si tu proveedor ofrece registros, comprueba si aparece como procesado, entregado, rebotado o rechazado.
Esto ayuda a distinguir un fallo general de un problema relacionado con un proveedor o buzón concreto.
Plugins, PHP, DNS, proveedor de correo, migraciones, contraseñas, políticas antispam o cambios del hosting pueden aportar pistas.
Si modificas SMTP, DNS, formulario y plugins simultáneamente y el problema desaparece, no sabrás cuál era la causa.
Y si vuelve, habrás perdido buena parte de la información útil para encontrarla.
Aquí está la parte que muchas webs dejan sin resolver.
Comprobar manualmente el formulario de contacto el día que publicas una web es útil.
Pero para una función crítica puede no ser suficiente.
Si una empresa depende de ese formulario, interesa detectar fallos posteriores.
Una estrategia de supervisión puede incluir:
La prueba ideal no debería limitarse a comprobar que la página devuelve un mensaje verde de «enviado».
Debería verificar, hasta donde permita la infraestructura utilizada, el recorrido real que importa al negocio.
Porque el objetivo no es demostrar que el botón funciona.
Es saber que las solicitudes de tus clientes no están desapareciendo por el camino.
