WordPress no envía correos: ¿qué hacer?

Contexto del problema: por qué WordPress deja de enviar correos

En WordPress, la mayoría de correos salen a través de wp_mail(), que a su vez utiliza una librería de envío (habitualmente PHPMailer) y el método de transporte configurado en el servidor. Si el servidor no permite enviar por PHP, si el dominio no está autenticado correctamente o si el destinatario rechaza el mensaje por políticas antispam, usted verá el mismo síntoma: el correo no llega.

Además, no todos los correos son iguales. No es lo mismo un aviso interno del formulario de contacto que un correo transaccional de WooCommerce, ni un restablecimiento de contraseña que un correo a múltiples destinatarios. Cada caso puede fallar en un punto distinto, por lo que conviene separar el problema en capas y validar una a una.

• WordPress genera el mensaje, pero el servidor no lo entrega (bloqueo o limitación del hosting).
• El mensaje se envía, pero se pierde en spam o se rechaza por falta de autenticación (SPF, DKIM, DMARC).
• Un plugin de formularios o WooCommerce no dispara el evento de envío por error o configuración.
• El correo “From” no coincide con el dominio o usa direcciones no válidas, lo que aumenta el rechazo.
• Hay un problema de reputación, abuso o seguridad que provoca bloqueos o filtrado agresivo.

Diagnóstico inicial: señales concretas y comprobaciones prudentes

Antes de cambiar configuraciones, identifique qué correos fallan, desde cuándo y en qué condiciones. Un fallo total suele apuntar a transporte o servidor. Un fallo parcial suele apuntar a un plugin, a un tipo de evento (por ejemplo, pedidos) o a entregabilidad (llega a unos dominios y a otros no).

Busque señales verificables y evite acciones que puedan empeorar el problema, como reinstalar plugins a ciegas, borrar registros o tocar DNS sin un plan. Lo prudente es reproducir el fallo con un caso controlado, registrar hora exacta y revisar logs del servidor y del propio WordPress si están disponibles.

• Mensajes de error visibles: “Could not instantiate mail function”, “SMTP connect() failed”, “mail() has been disabled”.
• Caídas o intermitencias: correos que a veces llegan y a veces no, coincidiendo con picos de CPU o límites de recursos.
• Cambios recientes: actualización de WordPress, tema, plugin de formularios, WooCommerce o cambios de PHP.
• Alertas del hosting: avisos de límites de envío, bloqueos por spam, suspensión temporal de la función mail.
• Alertas externas: notificaciones de rebote, quejas de usuarios o mensajes que llegan a spam de forma repentina.

Causas habituales y cómo confirmarlas sin suposiciones

La causa más común no es “WordPress” como tal, sino la ruta de salida del correo. En muchos alojamientos, el envío por PHP está limitado o monitorizado para evitar abuso. En otros casos, el correo sale, pero el destinatario lo rechaza por autenticación insuficiente o por incoherencias en el remitente.

Para confirmar la causa, piense en tres preguntas: ¿WordPress genera el correo?, ¿el servidor lo acepta y lo envía?, ¿el destinatario lo entrega? Cada respuesta requiere una evidencia distinta, y conviene no mezclar “no llega” con “se envía pero se filtra”.

• Fallo en la generación: el evento no se dispara (por ejemplo, el formulario no envía o WooCommerce no crea el email).
• Fallo en el transporte: la función mail está deshabilitada o el servidor no permite salida sin SMTP autenticado.
• Fallo de autenticación: el dominio no tiene SPF o DKIM correctos para el origen real del envío.
• Fallo por reputación: el servidor o IP tiene mala reputación o ha sido marcado por envíos abusivos.
• Fallo por configuración: remitente “From” no válido, cabeceras mal formadas o direcciones inexistentes.

Seguridad, malware y spam: cuando el correo se bloquea por riesgo

Si su sitio ha sido comprometido o está enviando spam sin que usted lo sepa, el hosting puede limitar el envío para proteger su infraestructura. También puede ocurrir que un atacante cree usuarios administradores, instale plugins maliciosos o inyecte código que envía correos masivos, lo que dispara bloqueos y deteriora la reputación del dominio.

No conviene asumir malware sin pruebas, pero sí tratarlo como una hipótesis razonable cuando hay picos de envío, quejas de spam, cuentas de correo comprometidas o cambios no autorizados. En ese escenario, el objetivo es contener, preservar evidencia y corregir el origen, no solo “hacer que vuelva a enviar”.

• Síntomas: correos de rebote masivos, quejas de destinatarios, bloqueo del hosting, lentitud repentina.
• Vectores habituales: plugins o temas vulnerables, credenciales filtradas, permisos de archivos inseguros.
• Revisión de usuarios: comprobar altas recientes, roles sospechosos y accesos anómalos.
• Medidas razonables: copia de seguridad antes de limpiar, rotación de contraseñas y claves, revisión de integridad.
• Hardening básico: limitar intentos de login, desactivar edición de archivos en el panel y mantener mínimos privilegios.

Rendimiento y estabilidad: colas, cron y límites que afectan al envío

El envío de correos también falla por causas de estabilidad. Si el servidor va justo de recursos, si hay picos de CPU o si el proceso PHP se corta, el correo puede no llegar a generarse o quedarse a medias. En WooCommerce, por ejemplo, algunos correos dependen de eventos y tareas programadas, y si el cron no ejecuta bien, se acumulan acciones.

En entornos con tráfico o con muchas automatizaciones, es importante distinguir entre un fallo puntual y un problema de cola o de ejecución. A veces el correo “sale” con retraso, lo que se percibe como fallo, pero en realidad es un síntoma de saturación o de tareas programadas que no se ejecutan a tiempo.

• Revisar picos de CPU, memoria y procesos coincidiendo con el intento de envío.
• Comprobar si hay retrasos sistemáticos en correos transaccionales (confirmaciones, restablecimientos).
• Verificar que el sitio no está en bucle de redirecciones o con errores que impiden ejecutar tareas.
• Evaluar si hay demasiados destinatarios o envíos en un corto periodo, lo que dispara límites del servidor.
• Confirmar que el correo no depende de una acción que está fallando antes (por ejemplo, pago no completado).

Plugins, temas y actualizaciones: conflictos típicos y buenas prácticas

Los correos en WordPress suelen depender de plugins: formularios, WooCommerce, membresías, reservas o automatizaciones. Un conflicto puede aparecer tras una actualización, por cambios en plantillas de correo, en cabeceras, en el remitente o en cómo se llama a wp_mail(). También puede influir un tema que sobreescribe plantillas o añade filtros al correo.

La práctica recomendada es probar actualizaciones en un entorno de staging, registrar cambios y validar el envío con casos reales antes de pasar a producción. Si ya está en producción y hay incidencia, conviene aislar: confirmar si el problema es global o de un plugin concreto, y revertir o ajustar con el mínimo impacto.

• Staging: probar actualizaciones y envíos de prueba antes de aplicarlas en el sitio público.
• Control de cambios: anotar versiones, fecha y qué se actualizó (núcleo, tema, plugins).
• Compatibilidades: revisar si el plugin de correo o formularios declara compatibilidad con su versión de WordPress y PHP.
• Aislamiento: desactivar temporalmente plugins no críticos para identificar el conflicto, evitando periodos de alta conversión.
• Plantillas: en WooCommerce, comprobar si hay personalizaciones de emails que rompan cabeceras o contenido.

Hosting, dominio y correo en España: DNS, SSL, PHP y correo transaccional

En España, el escenario más común es que el dominio esté en un registrador, el hosting en otro proveedor y el correo (buzones) en un servicio distinto. Esa separación es normal, pero aumenta los puntos de fallo: DNS mal configurado, cambios recientes de nameservers, registros SPF o DKIM incompletos, o un remitente que no corresponde con el dominio real.

Además, cada proveedor aplica políticas distintas: límites de envío por hora, bloqueo de la función mail, necesidad de SMTP autenticado, o filtros antispam propios. También influyen SSL y PHP: certificados caducados o versiones incompatibles pueden provocar errores indirectos en formularios o en procesos que disparan correos.

• DNS: verificar que el dominio resuelve correctamente y que los registros de autenticación del correo están alineados con el origen de envío.
• SPF, DKIM, DMARC: revisar que el dominio autoriza al servidor o servicio que realmente envía los correos.
• SSL: confirmar que el sitio carga sin errores de certificado, especialmente en formularios y checkout.
• PHP y límites: comprobar versión de PHP, límites de memoria y restricciones del proveedor que afecten a procesos de envío.
• Correo transaccional: valorar un envío autenticado por SMTP o servicio transaccional cuando el envío por PHP sea inestable o filtrado.

Pruebas, accesos y documentación técnica para resolverlo con trazabilidad

Para reducir el tiempo de resolución, prepare un paquete mínimo de pruebas y accesos. El objetivo no es acumular datos, sino poder reproducir el fallo, correlacionarlo con logs y confirmar la corrección. Si trabaja con un proveedor o con soporte técnico, esta documentación acelera la escalada.

En incidencias de correo, la trazabilidad es especialmente importante porque el fallo puede ocurrir fuera de WordPress. Si usted puede demostrar que WordPress generó el correo a una hora concreta, el hosting puede buscar el evento en sus registros. Y si puede mostrar rebotes o cabeceras, se puede analizar entregabilidad.

• Trazabilidad de cambios recientes: registro de actualizaciones (qué se actualizó y cuándo) y lista de plugins activos con versiones.
• Evidencias técnicas: logs del servidor (error log), registros del hosting relacionados con mail y capturas del error exacto.
• Casos de prueba: una URL y un flujo reproducible (formulario concreto, pedido de prueba, restablecimiento de contraseña).
• Datos del correo: destinatario, asunto, hora exacta, y si existe, rebote o mensaje de rechazo del servidor receptor.
• Copias y export: copia de seguridad previa y, si procede, export de base de datos antes de cambios de plugins o configuración.

Plan de acción ordenado para recuperar el envío sin improvisar

Un plan ordenado minimiza el riesgo de empeorar la incidencia y reduce el tiempo hasta recuperar correos críticos. La prioridad suele ser restaurar correos transaccionales (pedidos, contraseñas) y, en paralelo, corregir la causa raíz con pruebas y verificación.

Trabaje por fases: contención, copia, diagnóstico, corrección, verificación y monitorización. En cada fase, documente lo que cambia. Si está en un entorno con negocio activo, planifique ventanas de intervención y valide con pruebas controladas.

• Contención: identificar qué correos son críticos y habilitar un canal alternativo temporal si es necesario (sin romper el sitio).
• Copia: realizar backup antes de tocar plugins de correo, configuraciones o DNS.
• Diagnóstico: confirmar si el correo se genera en WordPress y si el servidor lo acepta, usando logs y pruebas reproducibles.
• Corrección: ajustar remitente, transporte (SMTP autenticado si procede) y autenticación del dominio según el origen real.
• Verificación: pruebas con varios destinatarios y dominios, revisión de spam, y confirmación de eventos de WooCommerce o formularios.

Si ya se ha tocado algo o hay urgencia: cómo evitar agravar la incidencia

En situaciones reales, es habitual que ya se hayan hecho cambios antes de diagnosticar: instalar un plugin de seguridad, restaurar una copia parcial, cambiar de hosting o tocar archivos del tema. En correo, esos cambios pueden introducir nuevas variables y dificultar saber qué fallaba originalmente.

Si hay urgencia, priorice recuperar el flujo crítico con el mínimo cambio posible y, después, reconstruya la trazabilidad. Evite borrar plugins “porque sí” o tocar DNS sin registrar el estado anterior. Si sospecha compromiso, preserve evidencia y actúe con contención.

• Se instaló un plugin de seguridad: revisar si bloquea peticiones del formulario, REST o cron, y documentar reglas activas.
• Se restauró una copia parcial: confirmar si se restauraron también base de datos y archivos, y si hay desajustes de URLs o claves.
• Se cambió de hosting: verificar DNS, propagación, límites de mail y si el nuevo servidor permite el método de envío anterior.
• Se tocó functions.php: revertir cambios no documentados y comprobar errores PHP que impidan ejecutar el envío.
• Se intentó limpiar malware sin copia: detener cambios, hacer una copia del estado actual y recopilar logs antes de seguir.

Preguntas frecuentes

Estas dudas aparecen a menudo cuando WordPress no envía correos o llegan a spam. Las respuestas son generales y deben adaptarse a su hosting y configuración.

P: ¿Cómo sé si WordPress está enviando el correo o si se pierde después?

R: Necesita evidencias en dos puntos: que el evento se dispara en WordPress (por ejemplo, al enviar el formulario o crear el pedido) y que el servidor registra el intento de envío. Si hay logs del hosting o del sistema de correo, la hora exacta del intento permite confirmarlo.

P: ¿Por qué los correos de WooCommerce no llegan pero los del formulario sí?

R: Suelen ser flujos distintos: WooCommerce depende de estados de pedido, plantillas y eventos internos. Si un pago no cambia de estado, si hay un conflicto con una plantilla de email o si hay tareas programadas retrasadas, puede fallar solo esa parte.

P: ¿Es obligatorio usar SMTP para que funcione en España?

R: No es obligatorio, pero es frecuente que mejore estabilidad y entregabilidad frente al envío por PHP, especialmente si su proveedor limita mail o si los destinatarios aplican filtros estrictos. Depende del hosting, del dominio y del volumen de envío.

P: ¿Qué riesgo hay si el sitio está enviando spam sin que yo lo sepa?

R: Puede sufrir bloqueos del hosting, pérdida de reputación del dominio, filtrado de correos legítimos y exposición a phishing. Además, si hay compromiso, el problema no se limita al correo: puede afectar a datos, SEO y estabilidad.

P: ¿Qué debo entregar a soporte para que lo resuelvan más rápido?

R: Un caso reproducible, hora exacta del intento, destinatario, tipo de correo (formulario, pedido, contraseña), capturas de error si existen, y cualquier aviso del hosting. Si hubo cambios recientes, incluya qué se actualizó y cuándo.