WooCommerce no envía emails al cliente cómo arreglar

Contexto del problema: por qué WooCommerce puede dejar de enviar emails

Este tipo de incidencia encaja sobre todo en deliverability de correo y en configuración técnica de WooCommerce y WordPress. No basta con comprobar si el pedido se ha creado. También hay que verificar si WooCommerce ha disparado el evento correcto, si WordPress ha podido usar la función de correo, si el servidor saliente lo acepta y si el dominio está autorizado para enviar. Un fallo en cualquiera de esas capas puede hacer que el cliente no reciba la notificación de nuevo pedido, pedido completado o cuenta creada.

En tiendas activas, el problema suele ser mixto. Hay casos en los que solo fallan algunos correos, por ejemplo los de clientes y no los de administrador. En otros, el envío depende del estado del pedido, de la pasarela de pago o de un plugin que modifica emails transaccionales. En ámbito general, y también en España, conviene separar dos preguntas desde el inicio: si el email se genera y si realmente se entrega.

• WooCommerce puede tener plantillas y estados de email activos, pero WordPress no lograr enviar el mensaje.
• El mensaje puede salir del sitio y ser rechazado por políticas de autenticación del dominio.
• El correo puede entregarse con retraso o acabar en spam por reputación o configuración deficiente.
• Un conflicto de plugin puede impedir que se dispare el email al cambiar el estado del pedido.
• Una actualización, un cambio de hosting o una migración parcial suelen ser detonantes frecuentes.

Diagnóstico inicial y señales útiles

El primer paso es observar sin alterar más de lo necesario. Si WooCommerce no envía emails al cliente, hay señales concretas que ayudan a acotar el fallo: pedidos que pasan a procesando o completado sin notificación, formularios de prueba que no llegan, avisos del hosting sobre límites de envío, errores en logs PHP, o cambios recientes de plugin, DNS, pasarela, tema o versión de PHP. Si además fallan otros correos del sitio, el foco suele estar en WordPress, en el servidor o en la autenticación del dominio.

Las comprobaciones prudentes deben intentar confirmar hipótesis sin romper más cosas. Lo razonable es usar un pedido de prueba en un entorno controlado, revisar la configuración de emails de WooCommerce, comprobar la dirección remitente, verificar si hay colas o límites en el hosting y consultar registros antes de desactivar componentes a ciegas. Si hay picos de CPU, caídas o avisos del proveedor, puede existir un problema paralelo de rendimiento o abuso del correo.

• Revise si el pedido cambia de estado y si el email asociado está habilitado en WooCommerce.
• Compruebe mensajes de error en logs PHP, errores fatales, avisos de SMTP o rechazos del servidor de correo.
• Observe señales como picos de CPU, tiempos de respuesta altos, tareas programadas retrasadas o avisos del hosting.
• Anote cambios recientes: actualización de plugins, ajuste de DNS, modificación del remitente o migración de servidor.
• Haga pruebas con cuentas de correo distintas y conserve cabeceras, capturas y horas exactas sin repetir envíos masivos.

Causas habituales y cómo confirmarlas

Las causas más comunes se repiten bastante. La primera es una configuración de correo insuficiente, sobre todo cuando el sitio intenta enviar con la función nativa de PHP sin autenticación sólida. La segunda es una mala configuración del dominio, especialmente de SPF, DKIM o DMARC, que hace que muchos proveedores desconfíen del mensaje. La tercera es un conflicto funcional: el email no se dispara porque un plugin altera el estado del pedido, el checkout o los hooks de WooCommerce.

También aparecen causas menos visibles. Por ejemplo, tareas programadas atascadas, errores de PHP tras una actualización, límites de envío del proveedor, dirección remitente distinta al dominio autenticado o reglas de seguridad que bloquean conexiones salientes. Para confirmarlas, hay que cruzar la hora del pedido con logs, cabeceras del mensaje, registros del plugin de correo si existe y configuración real del DNS. En ámbito general, no conviene asumir que el problema está en WooCommerce solo porque el síntoma aparece en la tienda.

• Remitente y dominio no alineados, lo que perjudica la autenticación y la confianza del receptor.
• SPF, DKIM o DMARC ausentes, mal escritos o sin propagación completa tras cambios de DNS.
• Plugin de checkout, pasarela o automatización que evita el cambio de estado esperado del pedido.
• Errores de PHP o incompatibilidades que rompen el proceso antes de que se llame a wp_mail().
• Límites del hosting o bloqueo de correo saliente por reputación, volumen o políticas internas.

Seguridad, malware y spam

No todos los fallos de correo son de seguridad, pero conviene contemplarla desde el principio. Un sitio comprometido puede enviar spam sin que el propietario lo advierta, consumir reputación del servidor y provocar bloqueos de salida. También puede haber cuentas de usuario no autorizadas, cambios en opciones de WordPress, scripts inyectados o plugins vulnerables que alteren el comportamiento del email transaccional. El síntoma visible es que los correos de clientes dejan de llegar o el hosting notifica actividad anómala.

La respuesta debe ser proporcionada. Antes de limpiar nada, lo prudente es preservar evidencias, hacer copia de archivos y base de datos, rotar contraseñas de accesos críticos, revisar usuarios administradores y verificar integridad básica de plugins y tema. Si hay indicios de abuso, es recomendable revisar permisos, tareas programadas y conexiones salientes. En España, algunos proveedores aplican bloqueos preventivos de correo cuando detectan patrones de spam, por lo que la investigación debe incluir tanto seguridad como deliverability.

• Plugins vulnerables o abandonados pueden abrir la puerta a inyecciones o uso indebido del envío de correo.
• Credenciales filtradas de WordPress, hosting o cuentas de email permiten cambios invisibles en la configuración.
• Permisos inseguros y archivos alterados pueden afectar a funciones, cron o plantillas de correo.
• La rotación de contraseñas, revisión de usuarios y hardening básico ayudan a contener el problema.
• Una copia previa y un análisis ordenado evitan borrar la evidencia técnica necesaria para entender el origen.

Rendimiento y estabilidad: cuando el correo falla por carga o procesos

WooCommerce depende de varios procesos para enviar bien sus emails: cambio de estado del pedido, ejecución de código del plugin, disponibilidad de recursos y, en algunos casos, tareas programadas. Si el servidor está saturado, si PHP alcanza límites de memoria o tiempo, o si hay bloqueos por caché y optimización agresiva en páginas críticas, el pedido puede completarse de forma inconsistente y el envío quedar a medias. El usuario solo percibe que no le llega el correo.

No siempre hay un error visible en pantalla. Puede haber lentitud, respuestas intermitentes, cron retrasado o procesos concurrentes que fallan en horas punta. Esto es importante en campañas, rebajas o periodos de alta demanda. Una tienda estable no solo debe cargar rápido. También debe procesar pedidos y comunicaciones de forma predecible. Si el problema se reproduce más en picos de tráfico, conviene revisar recursos, cachés de servidor, ejecución de cron y estabilidad de la base de datos.

• Picos de CPU o memoria pueden cortar procesos relacionados con checkout y envío de correo.
• Un WP-Cron retrasado o deshabilitado sin alternativa fiable puede afectar tareas relacionadas.
• Cachés mal configuradas pueden interferir en flujos delicados si se extienden al checkout o áreas privadas.
• Versiones de PHP no recomendadas o extensiones incompatibles introducen fallos difíciles de ver.
• La monitorización de tiempos, errores y carga ayuda a detectar correlaciones con los fallos de email.

Plugins, temas y actualizaciones

El ecosistema de WooCommerce depende mucho de plugins y personalizaciones. Por eso, una actualización aparentemente rutinaria puede alterar hooks, plantillas de email, estados de pedido o funciones del checkout. Si el problema comenzó tras actualizar WooCommerce, un plugin de pagos, un plugin SMTP o el tema, conviene asumir un posible conflicto hasta que se demuestre lo contrario. Lo mismo ocurre si se añadió código a functions.php o a un plugin de snippets.

La buena práctica es trabajar con staging, copia previa y control de cambios. Si la incidencia ya está en producción, lo prudente es identificar la ventana temporal exacta y probar con método. Desactivar en bloque puede agravar la caída si hay ventas activas. Es mejor revisar compatibilidades declaradas, changelogs, errores fatales y dependencias. Si se confirma conflicto, la solución puede pasar por ajustar código, revertir una actualización concreta o sustituir un complemento problemático por otro más mantenido.

• Use un entorno de staging para reproducir el fallo antes de tocar la tienda en producción.
• Conserve un registro de actualizaciones, versiones y cambios en snippets o functions.php.
• Revise compatibilidades entre WooCommerce, tema, pasarelas, plugins SMTP y extensiones de checkout.
• Si hay conflicto tras actualizar, pruebe una reversión controlada y documente el resultado.
• Evite modificar plantillas de email sin revisar si la personalización sigue siendo compatible.

Hosting, dominio y correo en España

En este tipo de incidencias, hosting, dominio y correo suelen ser el núcleo del problema. En muchos proveedores se aloja la web en un servicio y el correo transaccional en otro, o se usa un dominio con DNS externo. Eso obliga a revisar varias capas: resolución DNS, registros SPF, DKIM y DMARC, SSL válido, versión de PHP, límites de recursos, firewall, puertos salientes y cachés de servidor. Si hay CDN, proxy o sistema de seguridad perimetral, también conviene comprobar si influye en conexiones o cabeceras.

En España la casuística cambia bastante según proveedor, plan contratado y configuración concreta. Hay hostings que limitan el envío por PHP mail, otros exigen SMTP autenticado y otros bloquean temporalmente la salida si detectan reputación deficiente o picos de envío. Por eso es importante saber exactamente desde dónde envía la tienda y si el dominio autoriza ese origen. Un certificado SSL correcto no resuelve la deliverability, pero sí evita fallos en conexiones seguras asociadas a servicios externos.

• Compruebe DNS y propagación real de SPF, DKIM y DMARC tras cualquier cambio de proveedor o panel.
• Revise versión de PHP, límites de memoria y tiempo de ejecución, y disponibilidad de funciones necesarias.
• Verifique si el hosting bloquea el correo saliente por políticas antiabuso o por volumen.
• Confirme que el remitente coincide con un dominio autenticado y con buzones realmente existentes.
• Si usa correo transaccional externo, valide credenciales, cifrado, puertos y registros recomendados.

Pruebas, accesos y documentación técnica

Resolver bien una incidencia de correo requiere pruebas mínimas y accesos proporcionados. Sin evidencias, el análisis se convierte en intuición. Para un diagnóstico útil conviene reunir acceso a WordPress, panel del hosting, DNS, servicio de correo transaccional si existe y registros de errores. También ayuda contar con una cuenta de prueba para simular un pedido real y verificar qué paso falla. Cuanta más trazabilidad haya, menos tiempo se pierde y menor es el riesgo de tocar piezas innecesarias.

La documentación no es burocracia, sino protección técnica. Guardar horas exactas, URL afectadas, capturas y resultados de pruebas permite comparar antes y después. Además, si intervienen varias personas, evita que una corrección tape la evidencia de otra. En tiendas con facturación activa, esta disciplina reduce tiempos de caída y mejora la coordinación con soporte del proveedor, desarrolladores o mantenimiento externo.

• Trazabilidad de cambios recientes: registro de actualizaciones, lista de plugins activos, versiones y changelog de lo tocado.
• Evidencias técnicas: logs PHP, logs del servidor, capturas, URLs afectadas y horas exactas de cada intento.
• Copias de seguridad recientes de archivos y base de datos, y si es posible export de base de datos antes de intervenir.
• Cabeceras de emails recibidos o rechazados, informes del servicio SMTP y mensajes de rebote completos.
• Accesos temporales y acotados a WordPress, hosting, DNS y correo, con revisión posterior y rotación de claves.

Plan de acción ordenado

La forma más segura de abordar el problema es seguir un orden lógico. Primero hay que contener el impacto y evitar más cambios improvisados. Después conviene hacer copia y recoger evidencias. Con esa base, se revisa si los emails de WooCommerce están activados, si el pedido dispara el estado correcto, si WordPress puede enviar y si el dominio y el servidor autorizan la salida. Solo entonces tiene sentido aplicar correcciones, probar de nuevo y monitorizar el resultado durante unos días.

Este enfoque reduce riesgo y evita falsas soluciones. Si se corrige la salida de correo pero no se verifica la recepción real, el problema puede seguir afectando a clientes concretos. Si se tocan varios componentes a la vez, se pierde la relación causa efecto. En un entorno profesional, el objetivo no es solo hacer que hoy llegue una prueba, sino restablecer un flujo estable y dejar evidencia de qué se ha cambiado y por qué.

• Contención: pause cambios no esenciales y evite instalar más plugins sin criterio de diagnóstico.
• Copia previa: guarde archivos, base de datos y configuración relevante antes de corregir.
• Diagnóstico: revise WooCommerce, wp_mail(), logs, DNS, remitente, estados de pedido y proveedor de correo.
• Corrección: ajuste autenticación, conflicto detectado, versión incompatible o ruta de envío necesaria.
• Verificación y monitorización: haga pedidos de prueba, confirme recepción real y vigile logs posteriores.

Si ya se ha tocado algo o hay urgencia

Es muy común llegar a esta incidencia después de varios intentos previos. Quizá se instaló un plugin de seguridad, se restauró una copia parcial, se cambió de hosting, se editó functions.php, se borró un plugin crítico o se intentó limpiar malware sin copia. En esos casos, antes de tocar nada más conviene reconstruir la secuencia de acciones. Saber qué se cambió y en qué orden es tan importante como la configuración actual, porque muchos fallos nacen de una intervención bienintencionada pero incompleta.

Si hay urgencia comercial, la prioridad es estabilizar y recuperar trazabilidad, no improvisar. Evite borrar evidencia técnica, sobrescribir logs o restaurar otra copia sin entender el estado actual. Una restauración parcial puede dejar mezcla de archivos y base de datos de fechas distintas, lo que complica aún más WooCommerce. Si se manipuló código en functions.php o en snippets, documente la edición exacta. Si se borró un plugin crítico, revise dependencias antes de reinstalar o revertir.

• Si se instaló un plugin de seguridad, compruebe qué bloqueos, limpiezas o cuarentenas aplicó realmente.
• Si hubo restauración parcial, confirme coherencia entre archivos, base de datos y configuración de WooCommerce.
• Si cambió de hosting, revise DNS, remitente, límites de salida y rutas de correo aún heredadas del entorno anterior.
• Si se tocó functions.php, conserve la versión previa y localice hooks o filtros que afecten a emails o pedidos.
• Si se intentó limpiar malware sin copia, no elimine más elementos hasta asegurar evidencia y alcance del incidente.

Preguntas frecuentes

Estas dudas aparecen con frecuencia cuando WooCommerce no envía emails al cliente. La respuesta útil casi siempre depende de distinguir entre generación, envío y entrega.

P: Si el administrador recibe avisos, ¿por qué el cliente no recibe su email?

R: Porque pueden ser correos distintos, disparados por estados diferentes y enviados a dominios con políticas de filtrado distintas. También puede influir la autenticación del remitente o una personalización concreta del email al cliente.

P: ¿Instalar SMTP soluciona siempre el problema?

R: No siempre. Ayuda mucho cuando la causa está en la salida de correo o en la autenticación, pero no corrige por sí solo un conflicto de plugins, un estado de pedido incorrecto, un cron atascado o un rechazo por DNS mal configurado.

P: ¿Cómo sé si el correo se envió y se perdió o si nunca llegó a generarse?

R: Debe revisar la configuración de emails de WooCommerce, el estado del pedido, los logs de WordPress o del plugin SMTP y, si es posible, las cabeceras o rebotes del servicio de correo. Esa combinación permite separar generación de entrega.

P: ¿Puede influir una migración o cambio de DNS aunque la web cargue bien?

R: Sí. Es una causa muy habitual. La web puede funcionar en el nuevo servidor mientras el correo sigue intentando salir por una ruta no autorizada o con registros SPF y DKIM desactualizados.

P: ¿Cuándo conviene pedir una revisión técnica?

R: Cuando el fallo afecta a ventas, hay cambios recientes, no dispone de logs claros o ya se han hecho varias pruebas sin conclusión. En esos casos compensa revisar primero el flujo completo antes de seguir tocando la tienda.