WordPress no envía correos: causas y solución con SMTP

Que WordPress no envíe correos es uno de los problemas de mantenimiento más frecuentes y, al mismo tiempo, más silenciosos: nadie nota que el formulario de contacto no avisa, o que un cliente no puede restablecer su contraseña, hasta que alguien se queja.
La causa casi nunca es un error del sitio en sí, sino de cómo WordPress envía correo por defecto.
Esta guía explica por qué pasa, cómo diagnosticarlo antes de tocar nada y cuál es la solución de fondo.

Por qué WordPress no envía correos por defecto

WordPress no incluye un servidor de correo propio.
Según la documentación oficial sobre correo, "WordPress is not involved in the process of sending emails but only in the process of formatting the message to submit it to this mailing API": WordPress arma el mensaje, pero depende de otro componente del servidor para entregarlo.

Ese envío pasa por la función wp_mail(), que la propia referencia de la función describe como una función que "sends an email, similar to PHP's mail function".
La misma documentación de correo precisa qué hace por defecto: "by default configuration, this wrapper informs the PHPMailer library to use the PHP's internal mail() function that requires the presence of a sendmail-compatible binary acting as the MTA".
En criollo: sin configuración adicional, WordPress termina apoyándose en la función mail() de PHP, y esa función necesita que el servidor tenga un programa de envío de correo (un MTA, por ejemplo sendmail) instalado y funcionando.

Ahí aparecen los dos problemas reales:

• Muchos hostings no tienen ese MTA configurado, o lo restringen.
  La documentación de WordPress lo plantea como una responsabilidad del administrador del servidor: "its the server administrator's responsibility to configure the MTA and the related mailing environment properly".
  En hostings compartidos, esa configuración suele quedar fuera del control de quien administra el sitio, y en muchos casos la función mail() de PHP directamente no está disponible o no llega a ningún lado.
• Aunque el correo salga, el destinatario puede rechazarlo.
  El manual de PHP sobre mail() lo dice de forma directa: "it is important to note that just because the mail was accepted for delivery, it does NOT mean the mail will actually reach the intended destination".
  La función mail() no incluye ninguna autenticación del dominio remitente, y los proveedores de correo grandes (Gmail, Outlook, y también los servidores de correo corporativos) usan esa autenticación para decidir si un mensaje es confiable o va a spam.

Por eso "WordPress no envía correos" en realidad suele significar una de dos cosas distintas: que el envío falla antes de salir del servidor, o que sale pero no pasa los filtros del destinatario.
Distinguir cuál de las dos es tu caso es el primer paso del diagnóstico.

Cómo diagnosticar antes de tocar nada

Antes de instalar nada, conviene aislar si el correo se envía y no llega, o si directamente no se envía.
Este orden es criterio propio, pero evita cambiar varias cosas a la vez sin saber después cuál resolvió el problema:

1. Manda un correo de prueba real.
   Usa una acción del propio sitio, por ejemplo restablecer una contraseña o completar el formulario de contacto, en vez de un plugin de prueba aislado: así confirmas el circuito completo, no solo si el servidor puede enviar un correo suelto.
2. Revisa la bandeja de entrada y la carpeta de spam del destinatario.
   Si el mensaje aparece en spam, el envío técnico funciona: el problema es de autenticación o reputación, no de configuración del servidor.
3. Si no aparece en ninguna de las dos, revisa el registro de errores.
   Un error de PHP relacionado con mail() suele quedar registrado.
   La guía de WordPress lento o roto explica cómo activar WP_DEBUG y leer ese registro sin exponerlo en un sitio en producción; no lo repetimos aquí.
4. Prueba con un destinatario externo y uno del mismo dominio.
   Si el correo llega a una cuenta de Gmail pero no a una cuenta del mismo dominio del sitio (o al revés), la pista apunta a cómo ese dominio en particular maneja el correo, no a WordPress.

Este diagnóstico no reemplaza revisar la configuración del hosting: si después de estos cuatro pasos el origen no está claro, hay que confirmar con el proveedor de hosting si la función mail() de PHP está habilitada y si permite conexiones SMTP salientes (criterio propio).

Causas específicas más frecuentes

• La función mail() de PHP está deshabilitada o mal configurada en el hosting.
  Es la causa de fondo que explica la sección anterior: sin un MTA compatible con sendmail configurado en el servidor, wp_mail() no tiene cómo entregar el mensaje.
  Algunos hostings la desactivan directamente para reducir el riesgo de que el servidor sea usado para enviar spam.
• Faltan los registros SPF y DKIM del dominio.
  Según la misma documentación de correo de WordPress, el registro SPF "lists the IP addresses or hostnames authorized to send mail for that domain", de forma que si un servidor no autorizado envía un correo en nombre de tu dominio, el proveedor de correo del destinatario puede rechazarlo.
  DKIM añade una firma que certifica que el mensaje no fue alterado; la documentación recomienda configurar ambos, junto con DMARC, para asegurar la entrega.
  En hosting administrado, muchas veces ya están configurados; en un servidor propio, suele haber que agregarlos a mano como registros TXT del DNS.
• El remitente por defecto no es una dirección válida ni reconocida.
  La misma fuente señala que, por defecto, "the WordPress wrapper fills in the From: field with wordpress@example.com and the From: name as WordPress", usando el dominio real del sitio.
  Si un plugin de formulario de contacto sobrescribe ese remitente con la dirección del visitante que llenó el formulario, en lugar de una del propio dominio, el mensaje puede fallar la verificación SPF de ese dominio ajeno y terminar rechazado o en spam (criterio propio, a partir de cómo funciona la verificación SPF que describe la documentación).
• Se superó algún límite de envío del hosting.
  Muchos planes de hosting compartido limitan la cantidad de correos por hora para evitar abusos; si un sitio con mucho tráfico en formularios llega a ese límite, los correos siguientes simplemente no salen.
  Esto hay que confirmarlo con el proveedor de hosting: no hay un límite estándar entre proveedores.

La solución de fondo: enviar por SMTP autenticado

La solución que la propia documentación de WordPress plantea no es "arreglar" la función mail(), sino dejar de depender de ella.
La misma guía oficial de correo describe el uso de plugins de SMTP como una de las alternativas recomendadas: "you can install SMTP plugins from the WP.org plugin directory.
These type of plugins override wp_mail() default settings to use PHPMailer or any other mailing library of their choice, which utilize remote third party mailing services to send mail on your behalf of your domain".

En términos generales, esto significa reemplazar el envío por defecto por una conexión SMTP autenticada, con usuario y contraseña, contra un servidor de correo real.
Hay dos caminos habituales, y ninguno es "el correcto" de forma universal:

• Usar el propio servidor de correo del hosting.
  Si el hosting ya te da una cuenta de correo del dominio (por ejemplo notificaciones@tudominio.com), puedes usar esas credenciales SMTP.
  Es gratis y mantiene el remitente dentro de tu propio dominio, lo que ayuda con SPF.
  El límite suele ser el volumen: la mayoría de los hostings compartidos ponen un tope de envíos por hora.
• Usar un proveedor externo de envío transaccional.
  Servicios especializados en enviar correos automáticos (notificaciones, restablecimientos de contraseña, confirmaciones) suelen ofrecer mejor entregabilidad a volumen y estadísticas de envío, a cambio de una configuración adicional y, superado cierto volumen gratuito, un costo mensual.

Qué plugin de SMTP usar es una decisión que depende del hosting y del volumen de cada sitio: el directorio oficial de plugins de WordPress.org es el lugar para buscar uno, igual que con cualquier otro plugin.
No hay una única opción correcta para todos los casos, y la configuración concreta (qué puerto, qué cifrado, qué credenciales) depende de cada proveedor de correo, así que ese paso a paso queda fuera de esta guía.

Un punto que conviene revisar al mismo tiempo, y que suele quedar fuera de esta configuración: qué otros plugins del sitio tienen permiso para enviar correo en nombre del dominio.
La guía de seguridad de WordPress explica cómo detectar plugins abandonados o de origen dudoso, que es también el tipo de plugin que puede quedar mal configurado y afectar el envío de correo sin que nadie lo note.

Cómo confirmar que ya se resolvió

Esto es criterio propio: la documentación no define un procedimiento de verificación, pero sin uno es fácil dar el problema por solucionado antes de tiempo.

• Repite el mismo correo de prueba real que usaste para diagnosticar, por ejemplo un restablecimiento de contraseña, y no solo el correo de prueba que trae el plugin de SMTP.
• Revisa la bandeja de entrada principal, no solo spam.
  Si sigue cayendo en spam después de configurar SMTP, el problema pasó a ser de autenticación del dominio (SPF/DKIM), no de envío.
• Prueba con más de un proveedor de correo si puedes (por ejemplo Gmail y un correo corporativo): cada uno aplica sus propios filtros, y que funcione en uno no garantiza que funcione en el otro.
• Si el sitio tiene formularios de contacto o tienda, verifica también esos envíos, no solo el de restablecer contraseña: cada uno puede usar una ruta de código distinta dentro de WordPress.
• Deja este chequeo anotado en la rutina de mantenimiento del sitio, junto con las tareas que ya cubre la guía de mantenimiento de WordPress: un cambio de hosting o de plugin de formularios puede volver a romper el envío más adelante.

Errores frecuentes

• Instalar un plugin de SMTP sin antes diagnosticar si el problema es de envío o de spam.
  Si el correo ya se enviaba y solo caía en spam, el plugin de SMTP no alcanza: falta revisar SPF y DKIM.
• Dejar el remitente por defecto (wordpress@tudominio.com) sin verificar que esa dirección exista o reciba correo.
  Algunos servidores de correo antiguos rechazan mensajes de direcciones remitentes que no pueden recibir respuesta.
• Permitir que un plugin de formulario de contacto envíe con el correo del visitante como remitente.
  Puede fallar la verificación SPF del dominio ajeno; lo habitual es que el formulario envíe desde una dirección del propio dominio y use el correo del visitante como "responder a".
• No probar con un correo real del flujo del sitio.
  Un plugin de prueba de SMTP puede confirmar que el servidor conecta, pero no que un formulario de contacto o un restablecimiento de contraseña concreto sigan funcionando.
• Superar el límite de envíos del hosting sin saberlo.
  Un pico de formularios completados puede agotar el límite horario y dejar sin enviar los correos siguientes, sin ningún aviso visible en el sitio.
• Dar el problema por resuelto solo porque llegó un correo de prueba a spam.
  Llegar a spam confirma que el envío técnico funciona, no que el problema esté resuelto.

TutorWP no envía ni diagnostica los correos de tus sitios de WordPress: eso es una configuración de cada sitio, no algo que dependa del panel.
Lo que aporta es centralizar el estado de actualizaciones y copias de seguridad de todos tus sitios en un solo lugar, para que resolver un problema puntual como este no implique perder de vista el resto.
Si administras varios sitios, conoce TutorWP o conoce al equipo detrás del proyecto.