Un pedido completado sin email puede fallar en varios puntos: WooCommerce no genera el mensaje, WordPress no lo entrega a SMTP, el proveedor lo rechaza o el buzón lo filtra tras aceptarlo. El estado y el tipo de email determinan qué ruta debía ejecutarse.
No reenvíes todos los mensajes durante el diagnóstico; si estaban retrasados, el cliente podría recibir varias copias.
Elige un pedido afectado
Registra ID, cronología, dominio del destinatario, tipo esperado y hora exacta. Verifica la dirección sin mostrarla en capturas.
Compara un email de Processing con la notificación administrativa New order. Si uno llega, el transporte puede funcionar y diferir el destinatario, trigger o plantilla. El email transaccional no depende del consentimiento de marketing.
Confirma que esté habilitado
En WooCommerce > Ajustes > Emails abre el mensaje concreto. Comprueba activación, destinatario cuando corresponda y remitente válido.
Los emails al cliente toman la dirección del pedido; los administrativos usan listas configuradas. Busca espacios, separadores incorrectos y dominios antiguos. No uses como From la dirección del comprador: emplea un buzón del dominio autorizado.
Revisa el estado disparador
Cada mensaje responde a transiciones Pending, On hold, Processing, Completed, Cancelled, Failed o refund. Lee las notas para demostrar que ocurrió.
Asignar el mismo estado puede no repetir el trigger. Moverlo de ida y vuelta afecta stock, fulfilment e integraciones. Tras reparar, utiliza la acción explícita de reenvío para un pedido conciliado.
Demuestra la generación
Usa temporalmente un registro de correo fiable que guarde ID, dominio receptor, asunto, estado y error, no el contenido completo salvo necesidad protegida.
- hora del evento
- clase de email WooCommerce
- llamada a wp_mail
- ID del mensaje SMTP
- error inmediatoSi no existe intento, revisa errores PHP, overrides de plantilla y hooks que eliminan destinatarios.
Renderiza la plantilla de forma controlada. Un override antiguo puede lanzar un fatal solo para cierto tipo de pedido, idioma o método de envío. Compara su versión declarada con la plantilla actual de WooCommerce y revisa variables personalizadas. No sustituyas toda la plantilla si basta con corregir el override responsable.
Sigue la aceptación SMTP
Configura SMTP autenticado o un proveedor transaccional en lugar de PHP mail sin verificar. Relaciona el intento con su panel.
Un 2xx indica aceptación por el proveedor, no aparición en Inbox. Un 5xx debe explicar autenticación, política del remitente o receptor inválido. No expongas contraseñas o claves; rota cualquier secreto filtrado.
Conserva el identificador de mensaje para seguirlo hasta la entrega, rebote o aplazamiento. Si queda Deferred, revisa durante el plazo normal del proveedor antes de reenviar. Un rebote permanente de dirección inválida necesita corregir el destinatario, mientras uno temporal exige tratar la causa y mantener una cola limitada.
Comprueba SPF, DKIM y DMARC
DNS debe autorizar el servicio mediante SPF, firmar con DKIM y publicar una política DMARC intencionada. Analiza cabeceras de una prueba controlada.
No crees varios registros SPF en el mismo host; combina servicios respetando el límite de consultas DNS. Verifica públicamente la propagación y la alineación del dominio From.
Comprueba también el Return-Path y el selector DKIM realmente usados, no solo los registros que esperabas configurar. Una prueba enviada por otro servidor puede pasar SPF y aun fallar alineación DMARC.
Investiga el buzón receptor
Busca spam, cuarentena, reglas y logs del proveedor. Compara con un buzón controlado de otro servicio.
Adjuntos grandes, HTML roto, reputación o ráfagas de reenvíos pueden provocar filtrado. Mantén la plantilla concisa y evita datos sensibles innecesarios. Si falla un único dominio receptor, usa su respuesta SMTP antes de cambiar globalmente WooCommerce.
Repara y prueba el ciclo
Corrige el trigger, plantilla, dirección, autenticación o DNS demostrado. Envía un mensaje controlado y confirma generación, aceptación e Inbox.
Completa una compra de prueba y valida Processing, Completed, refund y cuenta según la tienda. El mantenimiento recurrente debe alertar sobre rechazos y repetir pruebas después de cambios de dominio, SMTP, plantilla o WooCommerce.