El formulario muestra «Mensaje enviado», pero en tu bandeja no hay nada. Repites la prueba, miras el móvil y vuelves a actualizar el correo. La web parece funcionar. La conversación con el cliente, bastante menos.
Que no lleguen los correos de una web es un problema recurrente. A veces falla el envío de WordPress; otras, la configuración del formulario, la autenticación del dominio o la recepción. Y desde fuera todos esos fallos tienen exactamente el mismo aspecto. Ningún correo.
Para arreglarlo conviene seguir el mensaje desde que alguien pulsa enviar hasta que aparece en el buzón. SMTP suele formar parte del arreglo, pero primero necesitamos saber dónde se está cortando el recorrido.
Por qué no llegan los correos de WordPress
Un aviso de tu web pasa por varias manos. El formulario o el plugin prepara el mensaje, WordPress lo entrega al sistema de envío y el proveedor del destinatario decide si lo acepta y dónde lo coloca. También puede ocurrir que el aviso ni siquiera se haya generado.
WordPress utiliza normalmente la función wp_mail(), apoyada en PHPMailer, y por defecto recurre al envío del servidor mediante PHP. Ese servidor puede estar bien configurado, tener restricciones o carecer de un servicio de correo adecuado. No todos los envíos mediante PHP están condenados al spam ni PHPMailer es un sistema que haya que eliminar. Lo que importa es cómo sale y se autentica el mensaje.
Además, «enviado» puede significar simplemente que una parte del sistema ha aceptado la petición. La propia documentación de WordPress advierte de que un resultado correcto no demuestra que el usuario haya recibido el correo.
Antes de tocar ajustes, busca el aviso en spam, otras carpetas y, si usas correo de empresa, en la cuarentena. Comprueba también que el buzón puede recibir un mensaje enviado desde otra cuenta. Si tampoco recibe ese, la investigación empieza en el correo de destino, no en WordPress.
| Lo que observas | Qué conviene comprobar primero |
|---|---|
| El formulario muestra un error al enviarlo | Validación, antispam y configuración del propio formulario |
| Llega el correo de prueba, pero no el del formulario | Notificación, destinatario y remitente de ese formulario |
| No llega ningún tipo de aviso de la web | Conexión de salida, credenciales, límites y registros de envío |
| Llega a unas cuentas y a otras no | Rechazos, autenticación, filtros y situación del buzón receptor |
| El mensaje aparece en spam | Autenticación, reputación y contenido; el envío sí se ha producido |
Son puntos de partida, no diagnósticos automáticos. Anota qué aviso falta, a qué dirección iba y a qué hora has hecho la prueba. Esa información sirve bastante más que «el correo va raro», aunque entendamos perfectamente la expresión.
Revisa el formulario y el remitente del correo
El primer sitio que revisar es la notificación del formulario que está fallando. La dirección de administrador de WordPress y el correo que recibe las solicitudes no tienen por qué coincidir. Cambiar uno no corrige necesariamente el otro.
Abre ese formulario y comprueba que el aviso esté activado, que el destinatario sea correcto y que no haya una condición que impida enviarlo. Si el plugin guarda las solicitudes, mira si la prueba aparece registrada. En Contact Form 7, los ajustes del mensaje están en la pestaña Correo del formulario; otros plugins los llaman notificaciones o acciones después del envío.
Después revisa tres campos que se confunden con facilidad. Para es quien recibe el aviso. De es la identidad desde la que sale. Responder a, o Reply-To, es la dirección que se utilizará cuando pulses responder.
Una configuración que solemos corregir es poner como remitente el correo que ha escrito el visitante. Parece lógico porque quieres contestarle, pero la web está intentando enviar en nombre de un dominio que no controla. Que alguien deje su Gmail en el formulario no autoriza a tu servidor a hacerse pasar por Gmail.
Para un aviso al equipo, una configuración como esta separa bien las funciones. Las direcciones son ficticias; sustitúyelas por las de tu negocio.
| Campo | Ejemplo | Para qué sirve |
|---|---|---|
| Para | contacto@negocio.example | Buzón donde atiendes las solicitudes |
| De | Web del negocio <web@negocio.example> | Remitente que tu proveedor autoriza a utilizar |
| Responder a | Campo de email validado del visitante | Poder responder a quien ha rellenado el formulario |
Utiliza como De una dirección de tu dominio autorizada en el servicio de envío. El correo del visitante se queda en Responder a, usando el campo de email validado y el formato que documente tu plugin. Contact Form 7 explica estos campos en su documentación.
Si tienes una confirmación para el visitante, revísala por separado. Tiene otro destinatario, aunque salga del mismo formulario. Y no cambies el correo de administrador solo para hacer pruebas si no necesitas cambiar quién recibe los avisos del sistema.
Cómo configurar SMTP en WordPress
SMTP permite que la web entregue sus mensajes a un servidor de correo configurado para enviarlos. También puedes usar una integración por API con un proveedor. En ambos casos, necesitas conectar WordPress al servicio y autorizar el remitente o dominio según sus instrucciones.
El plugin hace de conexión. Instalar WP Mail SMTP o FluentSMTP no crea por sí solo un servicio de correo ni garantiza que el mensaje llegue. Algunas conexiones y registros dependen de la versión del plugin; el proveedor puede tener su propio coste y sus límites. Que el conector sea gratuito no convierte todo lo demás en ilimitado.
Elige desde dónde saldrán los avisos
Para una web con pocos mensajes puede bastar el servicio de envío de tu correo corporativo o del alojamiento, si permite ese uso y ofrece límites adecuados. Confirma que puedes utilizarlo desde la web y qué ocurre si se supera la cuota.
Si los avisos son críticos, hay una tienda o necesitas saber qué mensajes se rechazan, un servicio de correo transaccional puede aportar registros, gestión de rebotes y un envío separado de las cuentas personales. Compara esas funciones, el soporte y el volumen real. Un pedido no necesita una campaña de marketing para llegar a su destinatario.
Con Gmail o Google Workspace, utiliza una integración compatible con el método de acceso de tu cuenta, preferiblemente OAuth cuando esté disponible. Las contraseñas de aplicación de Google requieren verificación en dos pasos y no están disponibles en todos los casos. No uses tu contraseña normal ni desactives la seguridad para seguir un tutorial antiguo. En Microsoft 365 y otros proveedores, consulta igualmente su método de autenticación vigente.
Conecta el proveedor y configura el remitente
Si ya tienes un plugin gestionando el envío, revisa su configuración antes de instalar otro. Dos conectores intentando decidir cómo sale el mismo correo complican el diagnóstico. Prepara los datos del proveedor y conserva la configuración anterior antes de sustituir una conexión que esté en uso.
Con WP Mail SMTP, el recorrido habitual es el siguiente. Los nombres pueden variar según el idioma y la versión.
- Instala y activa el plugin desde Plugins → Añadir nuevo, si no tienes ya un conector adecuado.
- En WP Mail SMTP → Ajustes, indica el nombre y el correo remitente autorizados.
- Elige la integración de tu proveedor. Completa su autorización o introduce la clave de envío correspondiente.
- Si utilizas Otro SMTP, rellena servidor, puerto, cifrado, autenticación y credenciales con los datos oficiales de tu proveedor.
- Comprueba en el proveedor que la identidad o el dominio están verificados. Si solicita registros DNS, completa también ese paso.
- Guarda y abre Herramientas → Prueba de correo electrónico para enviar un mensaje a un buzón que controles.
En una conexión SMTP tradicional, el servidor de salida puede ser distinto del dominio de tu web. El usuario suele ser la dirección completa de la cuenta, aunque algunos servicios asignan otro. La contraseña o credencial es la que corresponde a ese servicio, no la de acceso a WordPress. No la incluyas en capturas, correos de soporte ni ejemplos públicos.
Para el puerto y el cifrado, utiliza la pareja indicada por el proveedor. Es habitual encontrar 587 con STARTTLS o 465 con TLS implícito, que algunos plugins etiquetan como SSL. Ambos pueden utilizar TLS; elegir «SSL» a ciegas porque parece más seguro no corrige una combinación equivocada. Tampoco conviene desactivar el cifrado o la comprobación del certificado para que desaparezca un error.
Si la web debe salir siempre con la misma identidad, la opción de forzar el correo remitente ayuda a que otros plugins no lo cambien. Antes de activarla, comprueba si hay distintas identidades legítimas, por ejemplo avisos de tienda y formularios. La documentación de Otro SMTP explica esos ajustes. Después de guardar, comprueba en el correo recibido cuál ha sido el remitente real.
SPF, DKIM y DMARC si los correos van a spam
Una conexión SMTP correcta resuelve cómo entregas el mensaje al proveedor. La autenticación del dominio ayuda al servidor receptor a comprobar quién está enviando. Son partes relacionadas, pero distintas.
SPF publica qué servidores pueden enviar para el dominio utilizado en la comprobación SPF. DKIM permite verificar una firma asociada a un dominio y detectar cambios en las partes firmadas. DMARC comprueba que el dominio del remitente visible concuerde con el de una autenticación válida mediante SPF o DKIM y publica una política para los mensajes que no la superan.
No necesitas memorizar las siglas para localizar el problema. Entra en tu servicio de envío y revisa el estado de verificación del dominio. Si pide añadir registros, copia los valores de ese servicio en el proveedor que gestiona realmente el DNS. Estar modificando la zona del antiguo hosting es una forma muy eficaz de no cambiar absolutamente nada.
Antes de añadir SPF, comprueba si ya existe y qué servicios deben seguir autorizados. No crees otro registro SPF para el mismo nombre ni sustituyas el existente dejando fuera el correo corporativo. Tampoco copies una política DMARC restrictiva sin revisar los emisores legítimos. Si necesitas situar estas piezas, nuestra explicación de qué es un servidor DNS te ayudará a localizar dónde se administran.
Las directrices de Gmail distinguen los requisitos generales de los aplicables a grandes remitentes. Configurar SPF, DKIM y DMARC es recomendable, pero ni esos registros ni un plugin compran un pase directo a la bandeja de entrada. También cuentan la reputación, los rechazos anteriores y el contenido del mensaje.
Qué hacer si SMTP sigue sin enviar correos
Si la prueba falla, busca el error concreto del conector o del proveedor antes de cambiar otro ajuste. En las revisiones preferimos empezar con un solo mensaje, una hora anotada y una modificación cada vez. Con seis cambios a la vez puedes acabar con el correo funcionando y con ninguna pista de por qué. Hasta la siguiente incidencia.
| Error o situación | Qué revisar |
|---|---|
| No conecta o agota el tiempo de espera | Servidor, puerto, DNS y restricciones de conexión del hosting |
| Falla la autenticación | Usuario, credencial, autorización y método de acceso permitido |
| Rechaza el remitente | Dirección o dominio autorizado y coherencia del campo De |
| Indica límite, bloqueo o cuenta suspendida | Cuota y estado de la cuenta en el proveedor |
| El proveedor acepta el mensaje, pero no aparece | Entrega posterior, rebote, cuarentena, spam y reglas del destinatario |
Lee el texto completo del error y su documentación. Un rechazo de política no se interpreta igual que una contraseña incorrecta. Si pides ayuda al soporte, facilita la hora, el identificador del mensaje si existe y el error, ocultando credenciales y datos personales que no necesiten.
Si falla después de cambiar de hosting o de DNS
Cuando el correo deja de llegar tras una migración, comprueba qué ha cambiado además de la web. El servidor SMTP puede seguir apuntando al alojamiento anterior, pueden faltar registros de autenticación o el servidor nuevo puede intentar entregar localmente un mensaje que debería ir al correo externo de la empresa.
Si solo falla el envío hacia cuentas de tu propio dominio, pide al hosting que revise ese enrutamiento y comprueba los MX de recepción. Los MX indican dónde se recibe el correo de un dominio; no son el servidor SMTP que tienes que copiar en el plugin.
Si utilizas Cloudflare, el nombre usado para conectar al correo debe resolverse como indique su proveedor y no pasar por el proxy HTTP habitual. Cloudflare documenta esta comprobación y los registros de correo. En nuestra guía de Cloudflare para WordPress explicamos el contexto del cambio de DNS. No hace falta desactivar la protección de toda la web para revisar un nombre de correo.
Cómo comprobar que los correos de tu web llegan
La incidencia se comprueba desde la web hasta el buzón. Empieza por un correo de prueba del conector y confirma que lo has recibido, no solo que aparece un aviso verde en WordPress. Después prueba el proceso que estaba fallando.
Envía el formulario real con datos ficticios y un asunto reconocible. Comprueba el aviso al equipo, la confirmación al visitante si existe y que el botón de responder apunta a quien debe. Si había problemas con Gmail u Outlook, repite con una cuenta de ese proveedor que controles, además del buzón habitual. No uses cuentas de clientes para experimentar.
Si faltan correos de recuperación de contraseña, pruébalos con una cuenta de prueba controlada. Si el problema afecta a WooCommerce, revisa también que el aviso esté activado y que el pedido llegue al estado que lo dispara. Un correo de prueba genérico no demuestra que el pago esté cambiando correctamente el estado del pedido. La guía de incidencias de correo de WooCommerce separa esas comprobaciones.
Cuando el proveedor marque un mensaje como entregado, consulta qué significa ese estado en su sistema. Puede confirmar que el servidor receptor lo ha aceptado, sin demostrar en qué carpeta ha acabado ni que una persona lo haya leído.
En el estudio damos por cerrada la incidencia cuando comprobamos el recorrido que usa la persona de verdad. El envío de prueba es una buena señal. El formulario funcionando y el aviso recibido son la comprobación que nos interesa.
Evita perder solicitudes cuando falle el correo
El correo no debería ser la única copia de una solicitud importante. Si tu formulario permite guardar entradas, configura una conservación acorde a lo que necesitas y limita quién puede consultarlas. Si no lo hace, valora un sistema de registro adecuado. Antes de dar por perdido un contacto, revisa esas entradas, los pedidos o el sistema donde se haya guardado la operación.
Los registros de envío también ayudan, pero no hace falta conservar indefinidamente el cuerpo de los mensajes ni sus adjuntos. Empieza por fecha, destinatario, identificador, estado y error, con acceso restringido y un plazo de conservación. Guarda más detalle solo si hace falta para investigar. Y si una alerta de fallo depende del mismo correo que acaba de romperse, conviene tener otra vía para enterarse.
Después de corregir la configuración, revisa si hay avisos pendientes antes de reenviarlos. Cambiar SMTP no recupera automáticamente los mensajes que nunca se guardaron, ni conviene reenviar confirmaciones o enlaces de contraseña antiguos sin comprobar su vigencia.
Conserva un registro de qué servicio envía, qué remitente usa y quién mantiene la conexión. Repite la prueba del formulario cuando cambies el correo, el hosting o piezas que puedan afectar al envío. La portada puede estar preciosa y el botón perfectamente alineado; si las consultas se pierden por el camino, queda trabajo por hacer.
Si necesitas que revisemos el formulario, la salida y la recepción como un conjunto, podemos ayudarte desde el servicio de mantenimiento web. Lo primero será localizar en qué punto se pierde el mensaje.
Escrito en Nereida Studio, estudio de diseño web y posicionamiento en Valencia. Así trabajamos.
