BlogSoporte urgente

PrestaShop no envía correos: el diagnóstico completo

Confirmaciones de pedido que nunca llegan, formulario de contacto mudo: la causa rara vez es la que parece. Diagnóstico en cuatro niveles y la regresión SMTP de la 9.

Presta Debug21 de julio de 2026 5 min de lectura
Sobres en vuelo, uno de los cuales se desprende y se deshace

Una avería silenciosa y cara

Cuando PrestaShop deja de enviar correos, no se rompe nada a la vista. Los pedidos entran, el back-office funciona. Pero el cliente no recibe su confirmación, llama a atención al cliente y la confianza se resiente. Muchos comerciantes descubren el problema varias semanas después de que aparezca.

El diagnóstico se hace en cuatro niveles, del más sencillo al más técnico. No se salte ninguno: la causa suele estar en el nivel 1.

Nivel 1: la configuración de PrestaShop

Vaya a Parámetros avanzados > Correo electrónico.

La trampa número uno se lee directamente en la base de datos:

SELECT name, value FROM ps_configuration WHERE name LIKE 'PS_MAIL%';

El parámetro PS_MAIL_METHOD admite tres valores: 1 para la función mail de PHP, 2 para SMTP y 3 para desactivado. El valor 3 es la causa más frecuente del «no sale ningún correo». A veces lo deja ahí un módulo, o una fase de pruebas, y luego nadie se acuerda.

Compruebe después la dirección de envío. Debe pertenecer a su dominio. Una tienda que envía desde una dirección de Gmail o Yahoo ve cómo la mayoría de los servidores de recepción rechazan sus mensajes.

Use por último el botón de prueba de envío que hay en esa misma página: devuelve un mensaje de error en bruto mucho más útil que una prueba desde el proceso de compra.

Nivel 2: la regresión de SMTP en PrestaShop 9

Este caso merece un apartado propio, porque afecta a tiendas cuya configuración no se ha tocado.

PrestaShop 9 sustituyó Swift Mailer por Symfony Mailer, y el cifrado SSL desapareció de la capa de abstracción: solo quedan TLS o ningún cifrado. Consecuencia observada: la cadena de conexión se construye como ssl://servidor:587 allí donde la versión 8 usaba tcp://servidor:587.

Y el puerto 587 espera STARTTLS, es decir, una conexión en claro que después pasa a cifrada, no SSL implícito. El servidor responde entonces con un error del tipo:

SSL operation failed with code 1
error:0A00010B:SSL routines::wrong version number

Este mensaje, muy desconcertante, no indica un problema de certificado, sino una incompatibilidad de protocolo.

La solución inmediata consiste en cambiar al puerto 465 con SSL, que funciona correctamente. Si su proveedor no ofrece el 465, la alternativa es recurrir a un servicio de envío transaccional que disponga de un módulo específico.

Si sus correos dejaron de salir justo al subir a la versión 9, esta es la primera pista que hay que seguir.

Nivel 3: la autenticación del dominio

Sus correos salen, pero no llegan. Es otro problema distinto y, hoy por hoy, el más habitual.

Los proveedores de correo exigen tres registros DNS:

  • SPF: autoriza al servidor que envía en nombre de su dominio. Ojo con el límite de diez resoluciones DNS, que se alcanza enseguida al acumular varios servicios.
  • DKIM: firma criptográficamente los mensajes. Se configura en el servicio de envío, que le facilita la clave pública que debe publicar.
  • DMARC: indica qué hacer cuando fallan los dos anteriores. Empiece con la política none para observar y endurézcala después.

Un dominio sin DKIM ve cómo una parte importante de sus mensajes acaba en la carpeta de correo no deseado, sin ningún error del lado del servidor. Compruebe el estado de sus registros con una herramienta de test y lea las cabeceras de un mensaje recibido: indican el resultado de cada control.

Nivel 4: la cola de envío y los logs

PrestaShop guarda un historial de los mensajes enviados:

SELECT recipient, subject, date_add FROM ps_mail ORDER BY date_add DESC LIMIT 20;

Si aparecen líneas recientes, PrestaShop sí ha intentado el envío: el problema está aguas abajo, en el servidor de envío o de recepción. Si la tabla está vacía, el problema está aguas arriba, en la configuración o en el disparo del hook.

Consulte también var/logs/ y el registro de errores de PHP de su alojamiento. Un error de conexión SMTP suele aparecer ahí en texto claro.

Caso particular: los correos que dispara una tarea programada (recordatorios, informes) fallan a veces mientras los transaccionales funcionan sin problema. La causa casi siempre es la propia tarea programada, no el envío. Lea nuestro artículo sobre los crons que no se ejecutan.

La configuración recomendada

Para una tienda en producción, la función mail de PHP queda descartada: envía desde la IP compartida del alojamiento, cuya reputación no depende de usted.

La configuración sólida consiste en usar un servicio de envío transaccional específico, con SMTP autenticado, SPF y DKIM correctamente publicados y una vigilancia de la tasa de entrega. El coste es marginal; la diferencia de fiabilidad, enorme.

¿Sus clientes ya no reciben nada?

Diagnosticamos toda la cadena de envío, desde la configuración de PrestaShop hasta la autenticación del dominio. Diagnóstico gratuito, respuesta en menos de 1 h — consulte el soporte urgente de PrestaShop.