¿Por qué mi tienda PrestaShop no envía correos a los clientes y cómo solucionarlo?

¿Por qué mi tienda PrestaShop no envía correos a los clientes y cómo solucionarlo?

Una tienda online puede sobrevivir unos minutos sin banners, sin carrusel y hasta sin ese pop-up heroico que promete un 10% de descuento. Pero si PrestaShop no envía correos a los clientes, el silencio cae como una persiana metálica: no hay confirmación de pedido, no hay recuperación de contraseña, no hay aviso de envío, no hay confianza. Y en comercio electrónico, la confianza no es decoración; es estructura. 📩

El problema suele presentarse con una frase engañosamente sencilla: “mi tienda PrestaShop no manda emails”. Como si el correo fuera una paloma obediente que sale del servidor y llega al buzón del cliente sin cruzar firewalls, filtros antispam, registros DNS, límites del hosting, certificados TLS, plantillas traducidas a medias y alguna que otra configuración escrita en piedra por un módulo instalado en 2019. La realidad es menos romántica. También más interesante.

En esta guía vamos a diseccionar el fallo con método: desde la configuración de correo en PrestaShop hasta la entregabilidad real, pasando por SMTP, PHP mail(), SPF, DKIM, DMARC, estados de pedido, logs, plantillas, hosting y módulos. Lo haremos sin supersticiones. Porque “a mí antes me funcionaba” no es un diagnóstico, aunque todos lo hayamos pronunciado alguna vez mirando la pantalla como quien mira un pozo.

Mapa rápido del problema 🧭

• Síntomas habituales
• Cómo envía correos PrestaShop
• Diagnóstico rápido en 15 minutos
• Configuración SMTP correcta
• Problemas con PHP mail()
• SPF, DKIM y DMARC
• Estados de pedido y emails transaccionales
• Plantillas de correo y traducciones
• Logs y errores frecuentes
• Hosting, firewalls y límites
• Módulos, overrides y caché
• Checklist final

PrestaShop 1.7
PrestaShop 8
SMTP
Correos transaccionales
Entregabilidad
Seguridad email

Síntomas habituales: cuando la tienda habla, pero nadie la oye

No todos los problemas de correo son iguales. Algunos emails no se generan. Otros se generan, pero no salen. Otros salen, pero acaban en spam, esa Siberia digital donde van a morir boletines, facturas y promesas de sorteos. Antes de tocar nada, conviene identificar el tipo de silencio.

La primera gran antítesis es esta: que PrestaShop diga “correo enviado” no significa necesariamente que el cliente lo haya recibido. Enviar y entregar son verbos primos, no gemelos. El primero ocurre en tu servidor; el segundo depende de un ecosistema entero de reputación, autenticación y filtros. Una cosa es lanzar una botella al mar; otra, que llegue a la isla correcta.

Cómo envía correos PrestaShop: el pequeño teatro detrás del botón “Enviar”

PrestaShop envía correos transaccionales para acciones críticas: creación de cuenta, confirmación de pedido, cambio de estado, recuperación de contraseña, mensajes del formulario de contacto, facturas, devoluciones, alertas de stock y notificaciones administrativas, según módulos instalados y configuración. En la práctica, el sistema se apoya en tres piezas:

1. El evento que dispara el correo: un pedido pagado, un cambio de estado, un registro de cliente, una solicitud de contraseña.
2. La plantilla de email: archivos HTML y texto ubicados por idioma y tema, con variables como nombre del cliente, número de pedido o enlace de seguimiento.
3. El método de envío: función PHP mail() o servidor SMTP externo.

El drama aparece cuando una de estas piezas se rompe. A veces el evento ocurre, pero la plantilla no existe. A veces la plantilla existe, pero el servidor no autentica. A veces el SMTP autentica, pero Gmail mira el mensaje con ceja levantada porque el SPF no coincide. La tecnología, tan precisa en los folletos, tan barroca en la cocina.

Ruta habitual de configuración: en el panel de administración de PrestaShop, revisa Parámetros avanzados > Correo electrónico. Según la versión o traducción del back office, el nombre puede variar ligeramente. Ahí encontrarás el método de envío y el formulario para enviar un correo de prueba.

Diagnóstico rápido en 15 minutos: antes de desmontar la casa

Cuando una tienda deja de mandar correos, la tentación es tocarlo todo: cambiar contraseñas, reinstalar módulos, borrar caché, rezar al router. No. Primero método. Como decía un viejo técnico que conocí en una agencia —tenía siempre un destornillador en el bolsillo aunque trabajábamos con servidores—: “si no sabes qué has roto, no arregles tres cosas a la vez”. Tenía razón, aunque olía a café quemado.

1. Envía un email de prueba desde PrestaShop

Ve a Parámetros avanzados > Correo electrónico y utiliza la opción de prueba. Usa una dirección externa, por ejemplo Gmail, Outlook o un dominio distinto al de la tienda. Si pruebas enviando de tienda.com a [email protected], puedes estar probando un circuito demasiado cómodo, como lanzar una pelota dentro de una habitación cerrada y celebrar que no se perdió.

• Si falla el envío de prueba: revisa SMTP, credenciales, puerto, cifrado, firewall y logs.
• Si funciona: el transporte básico está bien; revisa eventos, plantillas, estados de pedido y módulos.
• Si llega a spam: no es un fallo de PrestaShop en sentido estricto; revisa autenticación DNS y reputación.

2. Prueba varios tipos de correo

• Crear cuenta de cliente.
• Recuperar contraseña.
• Formulario de contacto.
• Cambio manual de estado de pedido a “Pago aceptado” o “Enviado”.
• Mensaje desde atención al cliente, si aplica.

Si solo falla uno, el problema probablemente está en su plantilla, módulo o evento. Si fallan todos, mira la configuración global de correo. El diagnóstico no siempre necesita una excavadora; a veces basta con una linterna.

3. Revisa el correo del administrador y el remitente

En Parámetros de la tienda > Contacto > Tiendas y en la configuración general, verifica que el email de la tienda sea válido y pertenezca al dominio correcto. Evita usar como remitente una cuenta gratuita del tipo [email protected] si envías desde un servidor propio o desde el dominio de la tienda. Muchos proveedores lo considerarán sospechoso.

Regla de oro: usa un remitente como [email protected] o [email protected], autenticado mediante SMTP y con SPF/DKIM correctamente configurados. El correo electrónico moderno premia la coherencia y castiga la improvisación. Bastante irónico, considerando que nació como un sistema universitario casi confiado e ingenuo. 📨

Configuración SMTP correcta en PrestaShop

Para una tienda profesional, lo recomendable es utilizar SMTP autenticado. La función PHP mail() puede servir en entornos pequeños, pero suele ser opaca, limitada y más propensa a problemas de entregabilidad. SMTP, en cambio, ofrece autenticación, trazabilidad y compatibilidad con proveedores transaccionales. Es la diferencia entre enviar una carta sin remitente claro y contratar un mensajero con credenciales.

Campos habituales de SMTP

Puertos SMTP más comunes

• 587 con TLS/STARTTLS: opción moderna y habitual para envío autenticado.
• 465 con SSL: muy usado por proveedores de hosting y correo tradicional.
• 25: histórico, pero frecuentemente bloqueado por hostings, firewalls y proveedores cloud para reducir spam.

Si tu proveedor indica puerto 587 con TLS, no selecciones SSL “por si acaso”. La criptografía no funciona con superstición. Es como intentar abrir una cerradura con una llave muy bonita pero equivocada.

Proveedores SMTP recomendables para tiendas online

Una tienda que envía pedidos, facturas y avisos de envío debería considerar un servicio de email transaccional. No es obligatorio, pero sí muy sensato si el negocio depende de que los mensajes lleguen.

• Brevo antes Sendinblue: popular en Europa, con SMTP y API.
• Mailgun: potente para desarrolladores, buen control técnico.
• SendGrid: extendido, con métricas y gestión de reputación.
• Amazon SES: económico y robusto, aunque menos amable para principiantes.
• Postmark: excelente foco en correo transaccional y entregabilidad.
• SMTP del hosting: suficiente para tiendas pequeñas, siempre que esté bien configurado y no tenga límites demasiado estrechos.

Recomendación profesional: separa los correos transaccionales de las campañas de marketing. Confirmaciones de pedido y newsletters no deberían competir en el mismo saco, porque una campaña agresiva puede dañar la reputación del remitente que necesitas para lo urgente. El cupón puede esperar; la confirmación de pago, no. ✅

Cuando PrestaShop usa PHP mail(): cómodo, sí; infalible, no

La función mail() de PHP permite enviar mensajes desde el servidor web sin configurar un SMTP externo. Suena práctico. Y lo es, hasta que deja de serlo. Muchos hostings la limitan, la filtran, la deshabilitan o la conectan a un servidor local con una reputación que viaja peor que una maleta sin etiqueta.

Problemas frecuentes de PHP mail()

• La función está deshabilitada por seguridad en el hosting.
• El servidor no tiene MTA configurado, como Postfix, Exim o Sendmail.
• La IP del servidor tiene mala reputación por abuso de otros clientes en hosting compartido.
• El remitente no coincide con el dominio, lo que genera rechazos por políticas SPF/DMARC.
• No hay trazabilidad clara, por lo que diagnosticar rebotes resulta más difícil.

En hosting compartido, además, tu tienda convive con vecinos invisibles. Algunos venden artesanía. Otros envían spam como si sembraran ortigas. Y todos, a veces, comparten reputación de IP. Una injusticia técnica bastante cotidiana.

Cuándo evitar PHP mail()

Evítalo si tu tienda procesa ventas reales, si tienes problemas recurrentes de spam, si usas Gmail, Outlook o Yahoo como destinatarios frecuentes, si trabajas con varios idiomas, si necesitas métricas o si simplemente prefieres dormir. SMTP autenticado es más limpio, más auditable y más alineado con las exigencias actuales de los proveedores de correo.

SPF, DKIM y DMARC: los documentos de identidad del correo moderno

Muchos comerciantes piensan que el correo se configura dentro de PrestaShop. Solo en parte. La otra mitad vive en el DNS del dominio, ese archivo de aduanas donde se decide quién puede hablar en nombre de tu tienda. Si no configuras SPF, DKIM y DMARC, tus emails pueden parecer legítimos para ti y sospechosos para todos los demás. Como un pasaporte sin foto.

SPF: quién está autorizado a enviar

SPF es un registro TXT que indica qué servidores pueden enviar correos en nombre de tu dominio. Si usas un SMTP externo, debes incluirlo en el SPF.

Ejemplo SPF genérico:
v=spf1 include:proveedor-smtp.com include:_spf.google.com -all

El valor exacto lo proporciona tu hosting o proveedor SMTP. Cuidado con tener varios registros SPF separados: debe existir un solo registro SPF por dominio, aunque puede contener varios include. Dos SPF no suman fuerzas; se estorban como dos directores dando órdenes opuestas.

DKIM: la firma criptográfica

DKIM añade una firma digital al mensaje. El servidor receptor comprueba en DNS si la firma corresponde al dominio. Si coincide, el correo gana credibilidad. No garantiza llegar a bandeja de entrada, pero sin él empiezas la carrera cojeando.

Los proveedores transaccionales suelen darte un registro TXT o CNAME para activar DKIM. Después de añadirlo en DNS, puede tardar desde minutos hasta varias horas en propagarse.

DMARC: la política de alineación

DMARC dice a los receptores qué hacer si SPF o DKIM fallan y, sobre todo, permite recibir reportes. Para empezar, suele recomendarse una política suave:

Ejemplo DMARC inicial:
_dmarc.tudominio.com TXT «v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s»

Más adelante puedes endurecerla a quarantine o reject, pero no conviene hacerlo a ciegas. DMARC mal aplicado puede bloquear correos legítimos. La seguridad, cuando no se entiende, se parece inquietantemente al sabotaje.

Importante: Gmail y Yahoo endurecieron sus exigencias

Desde 2024, Gmail y Yahoo aplican requisitos más estrictos para remitentes masivos, especialmente en autenticación de dominio, tasas de spam y facilidad de baja en correos comerciales. Aunque muchas tiendas PrestaShop no entren formalmente en la categoría de “bulk sender”, estas prácticas se han convertido en estándar de facto. Si tus correos transaccionales no están autenticados, cada vez lo tendrán más difícil.

Herramientas útiles: puedes comprobar SPF, DKIM y DMARC con servicios como MXToolbox, Google Admin Toolbox, Mail Tester o los paneles de tu proveedor SMTP. Envía un correo de prueba y analiza cabeceras. Las cabeceras de email son feas, sí, pero dicen la verdad con una frialdad admirable. 🔍

Estados de pedido: el interruptor olvidado de muchos emails

En PrestaShop, muchas notificaciones de pedido dependen de los estados de pedido. Cada estado puede tener asociada una plantilla y una opción para enviar correo al cliente. Si esa casilla no está activa, no se enviará nada, aunque el SMTP esté perfecto y los DNS canten como un coro.

Qué revisar

Ve a Parámetros de la tienda > Configuración de pedidos > Estados o una ruta similar según tu versión. Abre estados como:

• Pago aceptado
• Preparación en curso
• Enviado
• Cancelado
• Reembolso
• Esperando pago por transferencia bancaria
• Esperando pago contra reembolso

Comprueba:

• Que la opción Enviar email al cliente esté activada cuando corresponda.
• Que exista una plantilla de email asociada.
• Que la plantilla exista en el idioma del cliente.
• Que el módulo de pago cambie el pedido al estado correcto.
• Que el pedido no se quede en un estado intermedio que no dispara email.

Este punto se pasa por alto con frecuencia. Se revisa el servidor, se culpa al hosting, se amenaza al SMTP, y al final el culpable era una casilla sin marcar. La informática tiene ese talento para humillarnos con detalles pequeños.

Plantillas de correo: cuando falta una pieza del idioma

PrestaShop utiliza plantillas de email en formato HTML y texto. Normalmente se encuentran en directorios como /mails/, dentro del tema o del núcleo, organizadas por idioma: /mails/es/, /mails/en/, /themes/tu_tema/mails/es/, etc. La ubicación exacta puede variar según la versión, el tema y las personalizaciones.

Fallos habituales en plantillas

• La plantilla existe en inglés pero no en español.
• El tema sobrescribe una plantilla antigua incompatible.
• Falta la versión .txt o .html.
• Hay variables mal escritas o eliminadas.
• Una traducción desde el back office guardó contenido incompleto.
• Permisos de archivos impiden leer las plantillas.

Si el email de prueba funciona pero un estado de pedido no envía nada, las plantillas deben estar entre los primeros sospechosos. Especialmente en tiendas multidioma. Lo multidioma promete cosmopolitismo; a veces entrega carpetas incompletas con nombres de dos letras.

Cómo regenerar o revisar plantillas

1. Haz copia de seguridad del tema y de la carpeta /mails/.
2. Compara las plantillas del tema con las del núcleo de PrestaShop.
3. Verifica que exista la plantilla asociada al estado de pedido.
4. Revisa traducciones desde Internacional > Traducciones.
5. Si usas un tema comprado, comprueba si incluye plantillas desactualizadas.
6. Prueba temporalmente con el tema clásico o con plantillas originales en un entorno de pruebas.

No edites en producción sin respaldo. Una plantilla de email parece inocente, pero puede romper confirmaciones de pedido, facturas adjuntas o variables críticas. Trabaja primero en staging si la tienda vende activamente. 🛠️

Logs de PrestaShop y del servidor: donde el sistema deja migas

Un diagnóstico serio exige mirar registros. No siempre son claros, pero suelen dejar pistas. PrestaShop puede mostrar errores en el back office y guardar logs en el sistema de archivos. El servidor web, PHP y el servicio de correo también pueden registrar rechazos, timeouts o errores de autenticación.

Dónde mirar

• Back office: Parámetros avanzados > Registros, según versión.
• Archivos de logs de PrestaShop: carpetas como /var/logs/ en instalaciones modernas.
• Logs de PHP: definidos por el hosting o por php.ini.
• Logs del servidor web: Apache o Nginx.
• Logs del servidor de correo: Exim, Postfix, Sendmail, si tienes acceso.
• Panel del proveedor SMTP: eventos de entrega, rebotes, bloqueos, quejas y rechazos.

Errores frecuentes y qué significan

Si tienes acceso SSH, una prueba de conectividad puede ahorrar horas. Por ejemplo, comprobar si el servidor alcanza el SMTP:

Comprobar conexión al puerto 587:
telnet smtp.tudominio.com 587

O con OpenSSL para STARTTLS:
openssl s_client -starttls smtp -connect smtp.tudominio.com:587

En muchos hostings compartidos no tendrás acceso a estas herramientas. No pasa nada. Pide al soporte que confirme si los puertos 465 y 587 están permitidos para conexiones salientes. Hazlo con precisión: “¿bloquean ustedes conexiones SMTP salientes al puerto 587?” funciona mejor que “el correo no va”, esa frase que en soporte técnico cae como lluvia sobre un tejado de zinc.

Hosting, firewalls y límites: el cartero también tiene horario

El hosting influye más de lo que parece. Hay servidores que limitan el número de correos por hora, bloquean puertos SMTP externos, deshabilitan funciones PHP o aplican filtros automáticos al contenido. No necesariamente por maldad; casi siempre por supervivencia. El spam convirtió Internet en una ciudad con demasiadas cerraduras.

Límites típicos del hosting

• Máximo de emails por hora o por día.
• Bloqueo del puerto 25.
• Bloqueo parcial de SMTP externo en planes compartidos.
• Rechazo de remitentes que no pertenezcan al dominio alojado.
• Suspensión temporal por tasa elevada de rebotes.
• Filtros antispam salientes que bloquean mensajes con enlaces sospechosos.

Casos típicos tras una migración

Después de migrar PrestaShop a otro servidor, pueden aparecer fallos que antes no existían:

1. El DNS del dominio apunta a la web nueva, pero los registros MX siguen mal configurados.
2. El SPF aún autoriza al proveedor antiguo, no al nuevo.
3. El servidor nuevo no tiene permisos para usar mail().
4. La versión de PHP cambió y un módulo de correo quedó incompatible.
5. Las plantillas no se copiaron con permisos correctos.
6. El firewall bloquea conexiones SMTP salientes.

La migración es una mudanza: uno cree haber llevado todos los muebles, hasta que descubre que la llave de la caja fuerte se quedó en el cajón de la cocina antigua.

Módulos, overrides y caché: los fantasmas elegantes de PrestaShop

PrestaShop es flexible, y esa flexibilidad es al mismo tiempo virtud y trampa. Módulos de pago, módulos de alertas, integraciones ERP, temas comerciales y overrides pueden intervenir en el proceso de envío. Algunos lo hacen bien. Otros lo hacen como quien repara un reloj con cinta adhesiva.

Módulos que pueden afectar los correos

• Módulos de pago: cambian estados de pedido y disparan confirmaciones.
• Módulos de email marketing: capturan eventos o modifican plantillas.
• Módulos SMTP de terceros: reemplazan el envío nativo.
• Módulos de facturación: adjuntan PDF o modifican emails de pedido.
• Módulos de atención al cliente: alteran formularios de contacto.
• Conectores externos: ERP, marketplaces, logística, CRM.

Cómo aislar un conflicto

1. Activa el modo mantenimiento si vas a probar en producción, o mejor usa staging.
2. Revisa módulos instalados o actualizados justo antes del fallo.
3. Desactiva temporalmente módulos relacionados con email, pago o pedido.
4. Limpia caché desde el back office.
5. Si tienes overrides, revisa especialmente clases relacionadas con Mail, OrderHistory y estados de pedido.
6. Consulta logs después de cada cambio, no diez cambios después.

En PrestaShop, los overrides pueden ser útiles, pero también son cápsulas del tiempo: código escrito para una versión concreta que sigue ejecutándose años después, solemne y desactualizado, como un funcionario imperial en una oficina con fibra óptica.

Correos que se envían pero no llegan: entregabilidad, spam y reputación

Este es el territorio más traicionero. PrestaShop puede enviar correctamente y, aun así, el cliente no recibe el correo en bandeja de entrada. No es magia negra; es entregabilidad. Los grandes proveedores analizan reputación de IP, dominio, autenticación, contenido, enlaces, historial de quejas y comportamiento de usuarios. El email moderno se parece menos a una carta y más a una entrevista de seguridad en un aeropuerto.

Factores que dañan la entregabilidad

• Dominio sin SPF, DKIM o DMARC.
• Remitente distinto al dominio autenticado.
• IP compartida con mala reputación.
• Muchos rebotes a direcciones inexistentes.
• Clientes marcando emails como spam.
• Contenido con demasiadas mayúsculas, signos de exclamación o enlaces acortados.
• Adjuntos pesados o sospechosos.
• Plantillas HTML mal formadas o sin versión texto.
• Enviar campañas promocionales desde el mismo canal que los emails transaccionales.

Buenas prácticas para emails transaccionales de PrestaShop

• Usa un remitente reconocible: [email protected].
• No cambies de remitente constantemente.
• Incluye nombre comercial claro en el campo “De”.
• Mantén plantillas limpias, ligeras y con enlaces al dominio correcto.
• No uses acortadores de URL en confirmaciones de pedido.
• Asegura que el dominio en enlaces coincide con la tienda.
• Configura SPF, DKIM y DMARC.
• Monitorea rebotes en el proveedor SMTP.
• Separa marketing de transaccional.

Prueba práctica: envía un correo transaccional a una cuenta Gmail, abre el mensaje, pulsa “Mostrar original” y revisa si SPF, DKIM y DMARC aparecen como PASS. Si alguno falla, ahí tienes una pista luminosa. No siempre la única, pero sí una buena.

Problemas específicos con Gmail, Outlook, Microsoft 365 y Yahoo

Los grandes buzones no rechazan correos por capricho, aunque a veces lo parezca. Gmail, Outlook.com, Microsoft 365 y Yahoo aplican filtros complejos. Si una tienda PrestaShop envía desde un dominio mal autenticado, con IP nueva o con una plantilla dudosa, puede caer en spam o ser rechazada.

Gmail

• Exige autenticación sólida para remitentes con volumen.
• Valora DKIM y DMARC alineados.
• Penaliza dominios con alta tasa de quejas.
• Puede clasificar como spam mensajes con enlaces inconsistentes o contenido agresivo.

Outlook y Microsoft 365

• Suelen ser estrictos con reputación de IP.
• Algunos rangos de hosting compartido tienen peor aceptación.
• Microsoft puede bloquear temporalmente IPs con historial problemático.
• Conviene revisar registros SPF y DKIM con especial cuidado.

Yahoo

• Aplica controles fuertes de autenticación.
• Observa la tasa de spam reportada por usuarios.
• Tiende a favorecer remitentes consistentes y bien configurados.

Si tus correos llegan a dominios corporativos pero no a Gmail, o al revés, no asumas que PrestaShop falló. Puede ser una política del receptor. El correo electrónico es una frontera con múltiples guardias, y cada guardia tiene su propio humor.

Errores después de actualizar PrestaShop o cambiar PHP

Actualizar PrestaShop o PHP mejora seguridad y rendimiento, pero también puede exponer módulos antiguos, overrides incompatibles o dependencias obsoletas. Una tienda que enviaba correos en PHP 7.4 puede comportarse distinto en PHP 8.1 si un módulo usa código no compatible. La modernidad entra por la puerta con casco brillante; detrás vienen los avisos de deprecación.

Qué revisar tras una actualización

• Compatibilidad de módulos SMTP o email.
• Overrides de clases relacionadas con correo.
• Errores PHP en logs.
• Permisos de carpetas tras despliegue.
• Plantillas del tema frente a nuevas plantillas del núcleo.
• Caché de Symfony/PrestaShop, según versión.

Si el fallo empezó justo después de una actualización, no pierdas tiempo mirando DNS durante tres horas. Mira primero el cambio reciente. En soporte técnico, la cronología suele ser más honesta que la intuición.

Seguridad: no conviertas tu tienda en una máquina de spam

Un formulario de contacto mal protegido, una cuenta SMTP con contraseña débil o un módulo vulnerable pueden convertir tu PrestaShop en un emisor de spam. Entonces los correos legítimos empiezan a fallar porque tu dominio o servidor queda marcado. Es la paradoja amarga: el sistema que debía hablar con tus clientes acaba gritando basura al mundo.

Medidas básicas de protección

• Usa contraseñas robustas para cuentas SMTP.
• Activa autenticación de dos factores donde el proveedor lo permita.
• Utiliza claves de aplicación en Gmail o servicios similares.
• Mantén PrestaShop, módulos y tema actualizados.
• Protege formularios con reCAPTCHA o soluciones antispam adecuadas.
• Limita envíos desde formularios públicos.
• Revisa usuarios administradores y permisos.
• Escanea malware si aparecen envíos desconocidos.

Si tu proveedor SMTP muestra miles de envíos que no reconoces, detén la cuenta, cambia credenciales y audita la instalación. No sigas probando. Un grifo roto no se arregla observando cómo inunda el salón.

Guía paso a paso para solucionar el problema

Ahora, el procedimiento ordenado. Sin épica innecesaria. Sin disparar a todas las sombras.

Paso 1: Confirma el alcance del fallo

• ¿No se envía ningún correo?
• ¿Solo fallan pedidos?
• ¿Solo falla el formulario de contacto?
• ¿Se envían pero llegan a spam?
• ¿Falla con ciertos dominios como Gmail u Outlook?

Paso 2: Prueba el envío desde PrestaShop

Usa el correo de prueba del back office. Guarda el error exacto si aparece. No lo resumas como “sale algo rojo”; copia el mensaje completo.

Paso 3: Cambia a SMTP autenticado

Si estás usando PHP mail(), configura SMTP. Usa datos oficiales del proveedor. Verifica puerto y cifrado:

• 587 + TLS/STARTTLS
• 465 + SSL

Paso 4: Alinea el remitente

El usuario SMTP y el remitente deberían pertenecer al mismo dominio o estar autorizados por el proveedor. Por ejemplo:

• Usuario SMTP: [email protected]
• Remitente de la tienda: [email protected]
• Nombre remitente: Nombre de tu tienda

Paso 5: Configura SPF, DKIM y DMARC

Entra al panel DNS del dominio y añade los registros indicados por tu proveedor SMTP. Después verifica con herramientas externas. No confíes solo en “ya lo puse”; DNS tiene esa cortesía antigua de tardar un poco en ser verdad.

Paso 6: Revisa estados de pedido

Comprueba que los estados relevantes envían email y tienen plantilla. Haz una prueba cambiando manualmente el estado de un pedido de prueba.

Paso 7: Revisa plantillas por idioma

Si la tienda está en español, confirma que existan las plantillas en /mails/es/ o en la ruta equivalente del tema. Si tienes varios idiomas, prueba con clientes de cada idioma.

Paso 8: Mira logs

Consulta registros de PrestaShop, PHP, servidor y proveedor SMTP. Los errores de autenticación, conexión o rechazo suelen aparecer allí antes que en la interfaz.

Paso 9: Descarta módulos conflictivos

Desactiva temporalmente módulos relacionados con correo, pagos o pedidos en un entorno seguro. Limpia caché y prueba de nuevo.

Paso 10: Consulta al hosting con datos concretos

Envía al soporte:

• Hora exacta de la prueba.
• Dirección remitente y destinataria.
• Servidor SMTP y puerto usado.
• Error registrado.
• Versión de PHP y PrestaShop.

Un ticket preciso recibe mejores respuestas. El soporte no es oráculo; aunque algunos técnicos, en noches largas, casi lo parezcan.

Checklist final para recuperar los emails de tu PrestaShop ✅

Preguntas frecuentes sobre correos en PrestaShop

¿Por qué el email de prueba funciona pero los clientes no reciben confirmaciones de pedido?

Porque el transporte SMTP puede estar bien, pero el evento de pedido puede no estar disparando el email. Revisa estados de pedido, plantillas asociadas, módulo de pago y logs. También verifica si el correo llega a spam o si el proveedor SMTP registra rebotes.

¿Es mejor usar SMTP que PHP mail()?

Sí, para una tienda profesional casi siempre es mejor SMTP autenticado. Ofrece más control, mejor entregabilidad, registros de envío y compatibilidad con SPF, DKIM y DMARC. PHP mail() puede funcionar, pero suele ser menos fiable y más opaco.

¿Puedo usar Gmail como SMTP en PrestaShop?

Se puede, pero no siempre es lo ideal para una tienda. Gmail puede requerir claves de aplicación, autenticación adicional y tiene límites de envío. Para comercio electrónico serio conviene usar un correo del dominio o un proveedor transaccional especializado.

¿Por qué mis correos llegan a spam?

Las causas más comunes son ausencia de SPF/DKIM/DMARC, mala reputación de IP o dominio, remitente no alineado, contenido sospechoso, enlaces acortados, exceso de imágenes o historial de quejas. PrestaShop puede enviar bien y aun así sufrir problemas de entregabilidad.

¿Dónde están las plantillas de email en PrestaShop?

Suelen estar en carpetas como /mails/ o dentro del tema en /themes/tu_tema/mails/, organizadas por idioma. La ubicación exacta depende de la versión y del tema. Revisa también las traducciones desde el back office.

¿Qué hago si el hosting bloquea SMTP?

Pide que habiliten conexiones salientes al puerto recomendado por tu proveedor, normalmente 587 o 465. Si no lo permiten, usa el SMTP del propio hosting o considera migrar a un proveedor más adecuado para comercio electrónico.

Cuando el correo vuelve, vuelve algo más que un mensaje

Arreglar los emails de PrestaShop no es solo resolver una incidencia técnica. Es restaurar el hilo de conversación entre la tienda y el cliente. Un pedido sin confirmación parece una habitación sin luz: quizá todo esté en su sitio, pero nadie se siente tranquilo. En cambio, un correo puntual —sobrio, claro, autenticado— funciona como una mano que se extiende desde la maquinaria invisible del ecommerce y dice: “hemos recibido tu pedido, todo va bien”.

La solución rara vez está en un único botón milagroso. Puede estar en un puerto SMTP cerrado, en un DKIM olvidado, en una plantilla ausente, en un estado de pedido mudo o en un módulo con demasiada memoria del pasado. Pero con un método ordenado, el problema deja de ser niebla. Se vuelve mapa.

Y esa es la pequeña victoria: que la tienda, por fin, vuelva a hablar. Que los correos salgan limpios, atraviesen filtros y lleguen a destino como golondrinas con brújula. Que el cliente compre, reciba su confirmación y no tenga que preguntarse si acaba de pagar en una tienda o en un agujero negro con logotipo. ✉️🚀