WordPress no recibe correos de pedidos WooCommerce

Contexto del problema en WordPress y WooCommerce

En WooCommerce, los correos de nuevo pedido, pedido procesando, pedido completado o avisos internos dependen de varios eventos. Primero se genera el estado del pedido. Después WooCommerce dispara la plantilla de email correspondiente. Finalmente WordPress intenta entregarlo mediante wp_mail(), ya sea usando la configuración del servidor o una capa SMTP. Si una sola parte falla, el correo puede no salir, salir tarde o terminar en spam.

Esto tiene un impacto operativo claro. El negocio puede creer que no hay ventas cuando sí las hay, o el cliente puede pensar que el pago no se registró. En España es habitual encontrar tiendas en hostings compartidos con restricciones de correo saliente, límites de recursos, DNS mal alineado o remitentes configurados con dominios distintos al del sitio. Por eso conviene tratar esta incidencia como un problema de negocio y no solo como un ajuste menor.

• Puede afectar al aviso interno de nuevo pedido y a los correos hacia el cliente al mismo tiempo.
• No siempre significa que WooCommerce esté roto, a veces el pedido existe pero el correo no salió.
• El fallo puede aparecer tras una actualización, un cambio de DNS o una migración de hosting.
• La ausencia de registros complica distinguir entre envío fallido, rebote o filtrado como spam.
• Una configuración de remitente poco coherente suele perjudicar la entregabilidad.

Diagnóstico inicial y señales útiles del correo

El primer paso es definir con precisión qué falla. No es lo mismo que no llegue el correo al administrador que no llegue al cliente, o que falle solo cierto tipo de pedido. Conviene revisar varios pedidos reales y anotar fecha, estado, método de pago, destinatario y si existe alguna notificación en cola. Si el hosting o un plugin de correo ofrece registros de envío, pueden aportar una pista importante sin alterar el entorno.

Las comprobaciones prudentes deben evitar cambios bruscos. Lo recomendable es no desactivar plugins al azar en producción ni cambiar DNS sin copia y sin ventana controlada. Antes conviene comprobar mensajes de error en registros de PHP, avisos del hosting, picos de CPU, cambios recientes, incidencias del proveedor de correo y si la función de correo funciona con un mensaje de prueba controlado. Si hay caída, lentitud o errores 500, la prioridad es recuperar estabilidad antes de forzar más envíos.

• Señales verificables: pedidos creados sin email, mensajes del tipo SMTP connect failed, rejected, deferred o timeout en logs.
• Avisos del hosting sobre límites de envío, uso excesivo de CPU, procesos suspendidos o bloqueo de la función mail.
• Cambios recientes en plugins, versión de PHP, DNS, SSL, pasarela de pago o proveedor de correo transaccional.
• Comprobación prudente de ajustes de WooCommerce en correos, remitente, destinatarios y estados de pedido que disparan avisos.
• Revisión de spam, cuarentena, cabeceras y rebotes para diferenciar no enviado, rechazado o filtrado.

Causas habituales y cómo confirmarlas

Las causas más comunes se repiten. La primera es una configuración incompleta de correo saliente. WordPress puede intentar enviar por la función del servidor, pero el proveedor limita esa vía o no la autentica correctamente. La segunda es una incoherencia entre el dominio web y el dominio usado como remitente. La tercera es un fallo en el estado del pedido, que impide que WooCommerce active el email esperado. También son habituales los conflictos con plugins SMTP, automatizaciones, seguridad o personalizaciones del tema.

Confirmar la causa exige revisar capas distintas. En WooCommerce hay que mirar qué plantillas de correo están activas y qué eventos las disparan. En WordPress conviene revisar si wp_mail() se ejecuta y con qué respuesta. En DNS hay que validar SPF, DKIM y, cuando exista, DMARC. En el buzón receptor interesa comprobar si hay rebote, filtrado o simple retraso. En muchos casos no hay una sola causa, sino una combinación de mala autenticación del remitente y cambios recientes mal documentados.

• Remitente con un dominio distinto al dominio autenticado del servicio de correo.
• SPF o DKIM ausentes, incorrectos o desactualizados tras cambio de proveedor.
• Estados de pedido no esperados por la lógica de WooCommerce o de la pasarela de pago.
• Plugin SMTP mal configurado, con credenciales caducadas o autenticación bloqueada.
• Personalizaciones en código que alteran destinatarios, cabeceras o plantillas de email.

Seguridad, malware y abuso de correo

Aunque el síntoma principal sea la falta de correos de pedidos, también conviene revisar el plano de seguridad. Un sitio comprometido puede generar envío masivo de spam, alterar cabeceras, crear usuarios administradores no autorizados o modificar funciones del tema y de plugins. En ese contexto, el proveedor de hosting o el servicio de correo puede bloquear el envío saliente por reputación o por actividad sospechosa. El problema no es solo técnico, también afecta a la confianza del dominio.

Los vectores habituales incluyen plugins vulnerables, credenciales filtradas, contraseñas reutilizadas, permisos excesivos y código inyectado en archivos como functions.php o en tablas de opciones. La respuesta debe ser ordenada. Antes de limpiar, conviene tomar copia, preservar evidencia, revisar usuarios, rotar contraseñas y validar qué cambios son legítimos. Un hardening básico ayuda a prevenir recurrencias, pero no sustituye la investigación de la causa inicial.

• Síntomas de abuso: picos de envío, listas negras, rebotes masivos o bloqueos del proveedor de correo.
• Vectores comunes: plugins desactualizados, accesos comprometidos, permisos inseguros y código inyectado.
• Medidas razonables: copia previa, cambio de claves, revisión de usuarios y auditoría de archivos modificados.
• Endurecimiento básico: mínimo privilegio, autenticación robusta, actualizaciones revisadas y supervisión periódica.
• Precaución importante: no borrar evidencias ni reinstalar a ciegas si aún no se conoce el alcance.

Rendimiento y estabilidad del envío transaccional

El correo transaccional también depende del rendimiento general del sitio. Si la tienda sufre lentitud, timeouts, errores fatales o saturación de recursos, el proceso que genera el email puede quedar incompleto. Esto se ve con más frecuencia en campañas, picos de tráfico o catálogos grandes donde coinciden consultas pesadas, tareas programadas y pasarelas de pago con llamadas externas. Un servidor lento no siempre impide crear el pedido, pero sí puede afectar a tareas posteriores como el envío del email.

La estabilidad mejora cuando el entorno está dimensionado y la tienda tiene mantenimiento periódico. Revisar la versión de PHP, límites de memoria, ejecución de cron, cachés de servidor y tareas en segundo plano ayuda a separar un problema de correo de un problema de carga. En ámbito general, si el sitio arrastra errores de base de datos o cola de tareas atascada, conviene resolver primero esa base técnica antes de juzgar la entregabilidad.

• Picos de CPU, memoria o procesos pueden interrumpir tareas ligadas al checkout y al envío de emails.
• Un WP Cron poco fiable en tráfico bajo o saturado en tráfico alto puede retrasar acciones programadas.
• Errores de PHP o consultas lentas afectan a la ejecución de hooks de WooCommerce.
• La caché no suele impedir el correo por sí sola, pero una mala configuración puede distorsionar flujos de compra.
• La monitorización ayuda a relacionar fallos de email con momentos concretos de carga o mantenimiento.

Plugins, temas y actualizaciones en WooCommerce

WooCommerce depende de un ecosistema amplio y los correos pueden verse alterados por plugins SMTP, personalizadores de checkout, automatizaciones, seguridad, multilenguaje, constructor visual o fragmentos en el tema hijo. Tras actualizar, un conflicto puede impedir el disparo de una notificación o modificar el destinatario sin que el error sea evidente. Por eso conviene trabajar con staging, control de cambios y una política clara de pruebas antes de pasar a producción.

Cuando la incidencia aparece tras una actualización, lo sensato es comparar versiones, revisar el changelog y reproducir el caso en un entorno seguro. Desactivar extensiones una a una solo debe hacerse con criterio y preferiblemente fuera del entorno en vivo. Si existe personalización en functions.php o mediante snippets, hay que auditarla porque muchas veces ahí se encuentran filtros sobre correos, cabeceras o estados de pedido que dejaron de ser compatibles.

• Use staging para probar actualizaciones de WooCommerce, pasarelas y plugins de correo antes de publicarlas.
• Mantenga control de cambios con fechas, versiones, motivo de la actualización y resultado de la prueba.
• Revise compatibilidad entre versión de WooCommerce, PHP, tema activo y extensiones críticas.
• Si hubo conflicto, vuelva temporalmente a una combinación estable solo con copia y procedimiento documentado.
• Audite snippets y personalizaciones del tema, sobre todo si tocan hooks de email o checkout.

Hosting, dominio y correo en España

En España es habitual que la web, el dominio y el correo estén repartidos entre servicios distintos. Esa separación no es un problema en sí misma, pero exige coherencia técnica. Si la tienda usa un dominio para la web, otro servicio para el correo corporativo y un tercero para DNS o CDN, cualquier ajuste parcial puede romper la autenticación del remitente. También son frecuentes las restricciones del hosting compartido sobre correo saliente, la desactivación de la función mail o límites estrictos para evitar abuso.

En esta capa hay que revisar DNS, SSL, cachés de servidor, versión de PHP, límites de recursos y el servicio de correo transaccional. SPF y DKIM deben reflejar el proveedor real que envía. DMARC ayuda a alinear políticas y detectar abuso. Si el sitio usa SMTP autenticado, conviene validar puerto, cifrado, usuario y remitente. Si existe CDN o proxy, también hay que descartar que haya alterado rutas de webhook o validaciones asociadas a pagos y estados de pedido. Algunos detalles pueden variar según proveedor, condiciones del servicio y configuración concreta.

• Verifique quién gestiona DNS, quién envía el correo y si ambos servicios están alineados.
• Revise SPF, DKIM y DMARC del dominio remitente antes de culpar a WooCommerce.
• Compruebe SSL válido, versión de PHP soportada y límites de memoria, procesos y ejecución.
• Confirme si el hosting permite correo saliente nativo o exige SMTP autenticado.
• Analice si una migración de dominio, cambio de IP o caché de servidor coincide con el inicio del fallo.

Pruebas, accesos y documentación técnica

Una intervención rápida no debe ser desordenada. Para resolver un problema de correos de pedido hace falta acceso mínimo y evidencia suficiente. Lo ideal es reunir accesos de administrador de WordPress, panel de hosting, gestión DNS, correo transaccional y, si existe, entorno de staging. También conviene documentar qué tipo de pedidos fallan, si afectan a todos los destinatarios y desde qué fecha aproximada ocurre.

Las pruebas deben servir para comparar antes y después. Un pedido de prueba bien definido, con hora exacta, destinatario controlado y registro del estado en WooCommerce, permite validar cambios sin improvisar. La documentación ahorra tiempo si intervienen varias personas, si hay soporte del proveedor o si debe revertirse una acción. Además, reduce el riesgo de perder evidencias útiles para seguridad o para revisar impacto comercial.

• Trazabilidad de cambios recientes: registro de actualizaciones, lista de plugins activos, changelog y modificaciones en snippets o tema.
• Evidencias técnicas: logs de correo y PHP, capturas, URLs afectadas, pedido de prueba, rebotes y cabeceras completas.
• Copias de seguridad verificadas y, cuando sea posible, export de base de datos antes de modificar correo o DNS.
• Accesos necesarios: WordPress, hosting, DNS, buzón receptor y servicio SMTP o proveedor transaccional.
• Informes de seguridad o monitorización si hubo alertas de spam, malware, bloqueo o degradación del servidor.

Plan de acción ordenado en ámbito general

Un plan eficaz empieza por contener el impacto. Si la tienda sigue vendiendo pero no avisa, hay que establecer una vigilancia temporal del panel de pedidos y confirmar manualmente las compras más recientes. Después, se toma copia válida y se preservan registros. Solo entonces conviene diagnosticar: revisar estados de pedido, configuración de correos de WooCommerce, método de envío de WordPress, logs, DNS y reputación del remitente. A partir de ahí se corrige la causa identificada, no una lista de supuestos.

Una vez aplicada la corrección, la verificación debe ser completa. No basta con enviar un correo de prueba genérico. Hay que reproducir un flujo real de compra, comprobar el aviso interno y el del cliente, revisar spam, tiempos de entrega y consistencia de plantillas. Después, conviene monitorizar durante varios días y dejar documentado el cambio para futuras revisiones o incidencias.

• Contención: supervise pedidos manualmente mientras persista la incidencia para no perder operaciones.
• Copia previa: verifique backup de archivos y base de datos antes de tocar plugins, DNS o código.
• Diagnóstico: identifique si falla el disparo del email, el transporte o la entrega al buzón final.
• Corrección: ajuste SMTP, DNS, estados de pedido, conflictos de plugins o código solo según evidencia.
• Verificación y monitorización: ejecute pedidos de prueba y observe resultados durante un periodo razonable.

Si ya se ha tocado algo o hay urgencia

En situaciones urgentes es muy común que alguien intente arreglar el problema antes de documentarlo. Se instala un plugin de seguridad, se cambia de hosting, se restaura una copia parcial o se modifica functions.php para forzar envíos. Estas acciones pueden ser comprensibles, pero también eliminan evidencia o introducen nuevas variables. Lo importante es detener la improvisación y reconstruir una línea temporal mínima con qué se hizo, cuándo y con qué efecto aparente.

Si ya se han realizado cambios, la prioridad es no agravar la caída ni perder datos. Conviene congelar nuevas modificaciones, guardar configuración actual, exportar logs si siguen disponibles y comparar con el último estado conocido como estable. Si se borró un plugin crítico, se cambió de hosting o se intentó limpiar malware sin copia, hay que actuar con cautela porque una reversión incompleta puede romper pedidos, correos, sesiones o integraciones de pago.

• Si se instaló un plugin de seguridad, revise si bloquea SMTP, REST, cron o archivos temporales necesarios.
• Si se restauró una copia parcial, confirme coherencia entre archivos, base de datos, pedidos y ajustes de correo.
• Si se cambió de hosting, compruebe DNS, IP, versión de PHP, límites y autenticación del remitente.
• Si se tocó functions.php o se borró un plugin crítico, audite hooks, snippets y dependencias antes de seguir.
• Si hubo intento de limpieza sin copia, preserve ahora la evidencia restante y evite sobrescribir más archivos.

Preguntas frecuentes

Estas dudas aparecen a menudo cuando WooCommerce deja de notificar pedidos. Responderlas con orden ayuda a evitar pruebas que confundan más el diagnóstico.

P: ¿Si WordPress no recibe correos de pedidos significa que se han perdido las ventas?

R: No necesariamente. Muchas veces el pedido sí se registra en WooCommerce y el fallo está solo en la notificación. Por eso conviene revisar primero el listado de pedidos, el estado del pago y la pasarela antes de asumir una pérdida de ventas.

P: ¿Instalar un plugin SMTP soluciona siempre el problema?

R: No siempre. Puede ayudar mucho si el problema está en el envío nativo del servidor, pero no corrige por sí solo estados de pedido incorrectos, conflictos de plugins, DNS mal configurado o bloqueo del buzón receptor.

P: ¿Cómo sé si el correo salió pero acabó en spam?

R: La pista más útil está en los registros del proveedor de correo, en las cabeceras del mensaje recibido y en los rebotes. Si hay confirmación de salida y entrega, el problema suele estar en filtrado del buzón. Si ni siquiera hay intento de envío, la causa está antes.

P: ¿Puede influir una actualización de WooCommerce aunque el checkout siga funcionando?

R: Sí. El proceso de compra y el de envío de emails comparten eventos pero no son idénticos. Un cambio de compatibilidad puede permitir crear pedidos y, aun así, romper el disparo o la plantilla del correo.

P: ¿Qué debería preparar antes de pedir soporte técnico?

R: Conviene reunir accesos básicos, fecha aproximada de inicio del problema, último cambio realizado, un pedido de prueba, capturas, logs disponibles y detalle de si falla al administrador, al cliente o a ambos. Esa información acelera mucho la revisión.