{"id":3685,"date":"2026-07-08T21:43:39","date_gmt":"2026-07-08T19:43:39","guid":{"rendered":"https:\/\/mantenimientoweb.pro\/blog\/por-que-mi-tienda-prestashop-no-envia-correos-a-los-clientes-y-como-solucionarlo\/"},"modified":"2026-07-08T21:43:41","modified_gmt":"2026-07-08T19:43:41","slug":"por-que-mi-tienda-prestashop-no-envia-correos-a-los-clientes-y-como-solucionarlo","status":"publish","type":"post","link":"https:\/\/mantenimientoweb.pro\/blog\/por-que-mi-tienda-prestashop-no-envia-correos-a-los-clientes-y-como-solucionarlo\/","title":{"rendered":"\u00bfPor qu\u00e9 mi tienda PrestaShop no env\u00eda correos a los clientes y c\u00f3mo solucionarlo?"},"content":{"rendered":"<p><main><\/p>\n<article>\n<p>  \u00bfPor qu\u00e9 mi tienda PrestaShop no env\u00eda correos a los clientes y c\u00f3mo solucionarlo?<\/p>\n<p>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\u00eda correos a los clientes, el silencio cae como una persiana met\u00e1lica: no hay confirmaci\u00f3n de pedido, no hay recuperaci\u00f3n de contrase\u00f1a, no hay aviso de env\u00edo, no hay confianza. Y en comercio electr\u00f3nico, la confianza no es decoraci\u00f3n; es estructura. \ud83d\udce9<\/p>\n<p>El problema suele presentarse con una frase enga\u00f1osamente sencilla: \u201cmi tienda PrestaShop no manda emails\u201d. Como si el correo fuera una paloma obediente que sale del servidor y llega al buz\u00f3n del cliente sin cruzar firewalls, filtros antispam, registros DNS, l\u00edmites del hosting, certificados TLS, plantillas traducidas a medias y alguna que otra configuraci\u00f3n escrita en piedra por un m\u00f3dulo instalado en 2019. La realidad es menos rom\u00e1ntica. Tambi\u00e9n m\u00e1s interesante.<\/p>\n<p>En esta gu\u00eda vamos a diseccionar el fallo con m\u00e9todo: desde la configuraci\u00f3n de correo en PrestaShop hasta la entregabilidad real, pasando por SMTP, PHP mail(), SPF, DKIM, DMARC, estados de pedido, logs, plantillas, hosting y m\u00f3dulos. Lo haremos sin supersticiones. Porque \u201ca m\u00ed antes me funcionaba\u201d no es un diagn\u00f3stico, aunque todos lo hayamos pronunciado alguna vez mirando la pantalla como quien mira un pozo.<\/p>\n<p>    <strong>Mapa r\u00e1pido del problema \ud83e\udded<\/strong><\/p>\n<ul>\n<li><a href=\"#sintomas\">S\u00edntomas habituales<\/a><\/li>\n<li><a href=\"#como-funciona\">C\u00f3mo env\u00eda correos PrestaShop<\/a><\/li>\n<li><a href=\"#diagnostico-rapido\">Diagn\u00f3stico r\u00e1pido en 15 minutos<\/a><\/li>\n<li><a href=\"#smtp\">Configuraci\u00f3n SMTP correcta<\/a><\/li>\n<li><a href=\"#php-mail\">Problemas con PHP mail()<\/a><\/li>\n<li><a href=\"#dns\">SPF, DKIM y DMARC<\/a><\/li>\n<li><a href=\"#estados\">Estados de pedido y emails transaccionales<\/a><\/li>\n<li><a href=\"#plantillas\">Plantillas de correo y traducciones<\/a><\/li>\n<li><a href=\"#logs\">Logs y errores frecuentes<\/a><\/li>\n<li><a href=\"#hosting\">Hosting, firewalls y l\u00edmites<\/a><\/li>\n<li><a href=\"#modulos\">M\u00f3dulos, overrides y cach\u00e9<\/a><\/li>\n<li><a href=\"#checklist\">Checklist final<\/a><\/li>\n<\/ul>\n<p>\n    <span>PrestaShop 1.7<\/span><br \/>\n    <span>PrestaShop 8<\/span><br \/>\n    <span>SMTP<\/span><br \/>\n    <span>Correos transaccionales<\/span><br \/>\n    <span>Entregabilidad<\/span><br \/>\n    <span>Seguridad email<\/span>\n  <\/p>\n<h2 id=\"sintomas\">S\u00edntomas habituales: cuando la tienda habla, pero nadie la oye<\/h2>\n<p>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.<\/p>\n<table>\n<thead>\n<tr>\n<th>S\u00edntoma<\/th>\n<th>Posible causa<\/th>\n<th>Prioridad de revisi\u00f3n<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>El email de prueba desde PrestaShop falla<\/td>\n<td>Configuraci\u00f3n SMTP incorrecta, puerto bloqueado, credenciales err\u00f3neas, TLS\/SSL mal elegido<\/td>\n<td>Alta<\/td>\n<\/tr>\n<tr>\n<td>El email de prueba funciona, pero no llegan confirmaciones de pedido<\/td>\n<td>Estado de pedido sin plantilla asociada, plantilla ausente, error en m\u00f3dulo de pago, override<\/td>\n<td>Alta<\/td>\n<\/tr>\n<tr>\n<td>Los clientes no reciben emails, pero el administrador s\u00ed<\/td>\n<td>Plantillas por idioma, restricciones del proveedor, destinatarios rechazados, problemas de entregabilidad<\/td>\n<td>Media\/Alta<\/td>\n<\/tr>\n<tr>\n<td>Los correos llegan a spam<\/td>\n<td>SPF, DKIM o DMARC ausentes, reputaci\u00f3n baja, remitente no alineado, contenido sospechoso<\/td>\n<td>Alta<\/td>\n<\/tr>\n<tr>\n<td>Solo falla \u201crecuperar contrase\u00f1a\u201d o \u201ccontacto\u201d<\/td>\n<td>Plantilla espec\u00edfica da\u00f1ada, m\u00f3dulo afectado, restricci\u00f3n antispam, error de formulario<\/td>\n<td>Media<\/td>\n<\/tr>\n<tr>\n<td>Funcionaba hasta cambiar de hosting o dominio<\/td>\n<td>DNS incompleto, puertos SMTP cerrados, mail() deshabilitado, IP con mala reputaci\u00f3n<\/td>\n<td>Muy alta<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>La primera gran ant\u00edtesis es esta: <strong>que PrestaShop diga \u201ccorreo enviado\u201d no significa necesariamente que el cliente lo haya recibido<\/strong>. Enviar y entregar son verbos primos, no gemelos. El primero ocurre en tu servidor; el segundo depende de un ecosistema entero de reputaci\u00f3n, autenticaci\u00f3n y filtros. Una cosa es lanzar una botella al mar; otra, que llegue a la isla correcta.<\/p>\n<h2 id=\"como-funciona\">C\u00f3mo env\u00eda correos PrestaShop: el peque\u00f1o teatro detr\u00e1s del bot\u00f3n \u201cEnviar\u201d<\/h2>\n<p>PrestaShop env\u00eda correos transaccionales para acciones cr\u00edticas: creaci\u00f3n de cuenta, confirmaci\u00f3n de pedido, cambio de estado, recuperaci\u00f3n de contrase\u00f1a, mensajes del formulario de contacto, facturas, devoluciones, alertas de stock y notificaciones administrativas, seg\u00fan m\u00f3dulos instalados y configuraci\u00f3n. En la pr\u00e1ctica, el sistema se apoya en tres piezas:<\/p>\n<ol>\n<li><strong>El evento que dispara el correo:<\/strong> un pedido pagado, un cambio de estado, un registro de cliente, una solicitud de contrase\u00f1a.<\/li>\n<li><strong>La plantilla de email:<\/strong> archivos HTML y texto ubicados por idioma y tema, con variables como nombre del cliente, n\u00famero de pedido o enlace de seguimiento.<\/li>\n<li><strong>El m\u00e9todo de env\u00edo:<\/strong> funci\u00f3n PHP <em>mail()<\/em> o servidor SMTP externo.<\/li>\n<\/ol>\n<p>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\u00eda, tan precisa en los folletos, tan barroca en la cocina.<\/p>\n<p>    <strong>Ruta habitual de configuraci\u00f3n:<\/strong> en el panel de administraci\u00f3n de PrestaShop, revisa <strong>Par\u00e1metros avanzados &gt; Correo electr\u00f3nico<\/strong>. Seg\u00fan la versi\u00f3n o traducci\u00f3n del back office, el nombre puede variar ligeramente. Ah\u00ed encontrar\u00e1s el m\u00e9todo de env\u00edo y el formulario para enviar un correo de prueba.<\/p>\n<h2 id=\"diagnostico-rapido\">Diagn\u00f3stico r\u00e1pido en 15 minutos: antes de desmontar la casa<\/h2>\n<p>Cuando una tienda deja de mandar correos, la tentaci\u00f3n es tocarlo todo: cambiar contrase\u00f1as, reinstalar m\u00f3dulos, borrar cach\u00e9, rezar al router. No. Primero m\u00e9todo. Como dec\u00eda un viejo t\u00e9cnico que conoc\u00ed en una agencia \u2014ten\u00eda siempre un destornillador en el bolsillo aunque trabaj\u00e1bamos con servidores\u2014: \u201csi no sabes qu\u00e9 has roto, no arregles tres cosas a la vez\u201d. Ten\u00eda raz\u00f3n, aunque ol\u00eda a caf\u00e9 quemado.<\/p>\n<h3>1. Env\u00eda un email de prueba desde PrestaShop<\/h3>\n<p>Ve a <strong>Par\u00e1metros avanzados &gt; Correo electr\u00f3nico<\/strong> y utiliza la opci\u00f3n de prueba. Usa una direcci\u00f3n externa, por ejemplo Gmail, Outlook o un dominio distinto al de la tienda. Si pruebas enviando de <em>tienda.com<\/em> a <em>info@tienda.com<\/em>, puedes estar probando un circuito demasiado c\u00f3modo, como lanzar una pelota dentro de una habitaci\u00f3n cerrada y celebrar que no se perdi\u00f3.<\/p>\n<ul>\n<li>Si falla el env\u00edo de prueba: revisa SMTP, credenciales, puerto, cifrado, firewall y logs.<\/li>\n<li>Si funciona: el transporte b\u00e1sico est\u00e1 bien; revisa eventos, plantillas, estados de pedido y m\u00f3dulos.<\/li>\n<li>Si llega a spam: no es un fallo de PrestaShop en sentido estricto; revisa autenticaci\u00f3n DNS y reputaci\u00f3n.<\/li>\n<\/ul>\n<h3>2. Prueba varios tipos de correo<\/h3>\n<ul>\n<li>Crear cuenta de cliente.<\/li>\n<li>Recuperar contrase\u00f1a.<\/li>\n<li>Formulario de contacto.<\/li>\n<li>Cambio manual de estado de pedido a \u201cPago aceptado\u201d o \u201cEnviado\u201d.<\/li>\n<li>Mensaje desde atenci\u00f3n al cliente, si aplica.<\/li>\n<\/ul>\n<p>Si solo falla uno, el problema probablemente est\u00e1 en su plantilla, m\u00f3dulo o evento. Si fallan todos, mira la configuraci\u00f3n global de correo. El diagn\u00f3stico no siempre necesita una excavadora; a veces basta con una linterna.<\/p>\n<h3>3. Revisa el correo del administrador y el remitente<\/h3>\n<p>En <strong>Par\u00e1metros de la tienda &gt; Contacto &gt; Tiendas<\/strong> y en la configuraci\u00f3n general, verifica que el email de la tienda sea v\u00e1lido y pertenezca al dominio correcto. Evita usar como remitente una cuenta gratuita del tipo <em>mitienda@gmail.com<\/em> si env\u00edas desde un servidor propio o desde el dominio de la tienda. Muchos proveedores lo considerar\u00e1n sospechoso.<\/p>\n<p>    <strong>Regla de oro:<\/strong> usa un remitente como <strong>ventas@tudominio.com<\/strong> o <strong>no-reply@tudominio.com<\/strong>, autenticado mediante SMTP y con SPF\/DKIM correctamente configurados. El correo electr\u00f3nico moderno premia la coherencia y castiga la improvisaci\u00f3n. Bastante ir\u00f3nico, considerando que naci\u00f3 como un sistema universitario casi confiado e ingenuo. \ud83d\udce8<\/p>\n<h2 id=\"smtp\">Configuraci\u00f3n SMTP correcta en PrestaShop<\/h2>\n<p>Para una tienda profesional, lo recomendable es utilizar SMTP autenticado. La funci\u00f3n PHP <em>mail()<\/em> puede servir en entornos peque\u00f1os, pero suele ser opaca, limitada y m\u00e1s propensa a problemas de entregabilidad. SMTP, en cambio, ofrece autenticaci\u00f3n, trazabilidad y compatibilidad con proveedores transaccionales. Es la diferencia entre enviar una carta sin remitente claro y contratar un mensajero con credenciales.<\/p>\n<h3>Campos habituales de SMTP<\/h3>\n<table>\n<thead>\n<tr>\n<th>Campo en PrestaShop<\/th>\n<th>Qu\u00e9 significa<\/th>\n<th>Ejemplo<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Servidor SMTP<\/td>\n<td>Host del servidor de correo saliente<\/td>\n<td>smtp.tudominio.com, smtp.gmail.com, smtp.mailgun.org<\/td>\n<\/tr>\n<tr>\n<td>Usuario SMTP<\/td>\n<td>Cuenta autenticada para enviar<\/td>\n<td>ventas@tudominio.com<\/td>\n<\/tr>\n<tr>\n<td>Contrase\u00f1a SMTP<\/td>\n<td>Contrase\u00f1a de la cuenta o clave de aplicaci\u00f3n\/API<\/td>\n<td>No debe ser la contrase\u00f1a del back office<\/td>\n<\/tr>\n<tr>\n<td>Cifrado<\/td>\n<td>SSL, TLS o ninguno<\/td>\n<td>TLS para puerto 587; SSL para 465<\/td>\n<\/tr>\n<tr>\n<td>Puerto<\/td>\n<td>Puerto de conexi\u00f3n SMTP<\/td>\n<td>587, 465 o 25 seg\u00fan proveedor<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Puertos SMTP m\u00e1s comunes<\/h3>\n<ul>\n<li><strong>587 con TLS\/STARTTLS:<\/strong> opci\u00f3n moderna y habitual para env\u00edo autenticado.<\/li>\n<li><strong>465 con SSL:<\/strong> muy usado por proveedores de hosting y correo tradicional.<\/li>\n<li><strong>25:<\/strong> hist\u00f3rico, pero frecuentemente bloqueado por hostings, firewalls y proveedores cloud para reducir spam.<\/li>\n<\/ul>\n<p>Si tu proveedor indica puerto 587 con TLS, no selecciones SSL \u201cpor si acaso\u201d. La criptograf\u00eda no funciona con superstici\u00f3n. Es como intentar abrir una cerradura con una llave muy bonita pero equivocada.<\/p>\n<h3>Proveedores SMTP recomendables para tiendas online<\/h3>\n<p>Una tienda que env\u00eda pedidos, facturas y avisos de env\u00edo deber\u00eda considerar un servicio de email transaccional. No es obligatorio, pero s\u00ed muy sensato si el negocio depende de que los mensajes lleguen.<\/p>\n<ul>\n<li><strong>Brevo<\/strong> antes Sendinblue: popular en Europa, con SMTP y API.<\/li>\n<li><strong>Mailgun:<\/strong> potente para desarrolladores, buen control t\u00e9cnico.<\/li>\n<li><strong>SendGrid:<\/strong> extendido, con m\u00e9tricas y gesti\u00f3n de reputaci\u00f3n.<\/li>\n<li><strong>Amazon SES:<\/strong> econ\u00f3mico y robusto, aunque menos amable para principiantes.<\/li>\n<li><strong>Postmark:<\/strong> excelente foco en correo transaccional y entregabilidad.<\/li>\n<li><strong>SMTP del hosting:<\/strong> suficiente para tiendas peque\u00f1as, siempre que est\u00e9 bien configurado y no tenga l\u00edmites demasiado estrechos.<\/li>\n<\/ul>\n<p>    <strong>Recomendaci\u00f3n profesional:<\/strong> separa los correos transaccionales de las campa\u00f1as de marketing. Confirmaciones de pedido y newsletters no deber\u00edan competir en el mismo saco, porque una campa\u00f1a agresiva puede da\u00f1ar la reputaci\u00f3n del remitente que necesitas para lo urgente. El cup\u00f3n puede esperar; la confirmaci\u00f3n de pago, no. \u2705<\/p>\n<h2 id=\"php-mail\">Cuando PrestaShop usa PHP mail(): c\u00f3modo, s\u00ed; infalible, no<\/h2>\n<p>La funci\u00f3n <em>mail()<\/em> de PHP permite enviar mensajes desde el servidor web sin configurar un SMTP externo. Suena pr\u00e1ctico. 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\u00f3n que viaja peor que una maleta sin etiqueta.<\/p>\n<h3>Problemas frecuentes de PHP mail()<\/h3>\n<ul>\n<li><strong>La funci\u00f3n est\u00e1 deshabilitada<\/strong> por seguridad en el hosting.<\/li>\n<li><strong>El servidor no tiene MTA configurado<\/strong>, como Postfix, Exim o Sendmail.<\/li>\n<li><strong>La IP del servidor tiene mala reputaci\u00f3n<\/strong> por abuso de otros clientes en hosting compartido.<\/li>\n<li><strong>El remitente no coincide con el dominio<\/strong>, lo que genera rechazos por pol\u00edticas SPF\/DMARC.<\/li>\n<li><strong>No hay trazabilidad clara<\/strong>, por lo que diagnosticar rebotes resulta m\u00e1s dif\u00edcil.<\/li>\n<\/ul>\n<p>En hosting compartido, adem\u00e1s, tu tienda convive con vecinos invisibles. Algunos venden artesan\u00eda. Otros env\u00edan spam como si sembraran ortigas. Y todos, a veces, comparten reputaci\u00f3n de IP. Una injusticia t\u00e9cnica bastante cotidiana.<\/p>\n<h3>Cu\u00e1ndo evitar PHP mail()<\/h3>\n<p>Ev\u00edtalo 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\u00e9tricas o si simplemente prefieres dormir. SMTP autenticado es m\u00e1s limpio, m\u00e1s auditable y m\u00e1s alineado con las exigencias actuales de los proveedores de correo.<\/p>\n<h2 id=\"dns\">SPF, DKIM y DMARC: los documentos de identidad del correo moderno<\/h2>\n<p>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\u00e9n puede hablar en nombre de tu tienda. Si no configuras SPF, DKIM y DMARC, tus emails pueden parecer leg\u00edtimos para ti y sospechosos para todos los dem\u00e1s. Como un pasaporte sin foto.<\/p>\n<h3>SPF: qui\u00e9n est\u00e1 autorizado a enviar<\/h3>\n<p><strong>SPF<\/strong> es un registro TXT que indica qu\u00e9 servidores pueden enviar correos en nombre de tu dominio. Si usas un SMTP externo, debes incluirlo en el SPF.<\/p>\n<p>    Ejemplo SPF gen\u00e9rico:<br \/>\n    v=spf1 include:proveedor-smtp.com include:_spf.google.com -all<\/p>\n<p>El valor exacto lo proporciona tu hosting o proveedor SMTP. Cuidado con tener varios registros SPF separados: debe existir <strong>un solo registro SPF<\/strong> por dominio, aunque puede contener varios <em>include<\/em>. Dos SPF no suman fuerzas; se estorban como dos directores dando \u00f3rdenes opuestas.<\/p>\n<h3>DKIM: la firma criptogr\u00e1fica<\/h3>\n<p><strong>DKIM<\/strong> a\u00f1ade 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 \u00e9l empiezas la carrera cojeando.<\/p>\n<p>Los proveedores transaccionales suelen darte un registro TXT o CNAME para activar DKIM. Despu\u00e9s de a\u00f1adirlo en DNS, puede tardar desde minutos hasta varias horas en propagarse.<\/p>\n<h3>DMARC: la pol\u00edtica de alineaci\u00f3n<\/h3>\n<p><strong>DMARC<\/strong> dice a los receptores qu\u00e9 hacer si SPF o DKIM fallan y, sobre todo, permite recibir reportes. Para empezar, suele recomendarse una pol\u00edtica suave:<\/p>\n<p>    Ejemplo DMARC inicial:<br \/>\n    _dmarc.tudominio.com TXT \u00abv=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; adkim=s; aspf=s\u00bb<\/p>\n<p>M\u00e1s adelante puedes endurecerla a <em>quarantine<\/em> o <em>reject<\/em>, pero no conviene hacerlo a ciegas. DMARC mal aplicado puede bloquear correos leg\u00edtimos. La seguridad, cuando no se entiende, se parece inquietantemente al sabotaje.<\/p>\n<h3>Importante: Gmail y Yahoo endurecieron sus exigencias<\/h3>\n<p>Desde 2024, Gmail y Yahoo aplican requisitos m\u00e1s estrictos para remitentes masivos, especialmente en autenticaci\u00f3n de dominio, tasas de spam y facilidad de baja en correos comerciales. Aunque muchas tiendas PrestaShop no entren formalmente en la categor\u00eda de \u201cbulk sender\u201d, estas pr\u00e1cticas se han convertido en est\u00e1ndar de facto. Si tus correos transaccionales no est\u00e1n autenticados, cada vez lo tendr\u00e1n m\u00e1s dif\u00edcil.<\/p>\n<p>    <strong>Herramientas \u00fatiles:<\/strong> puedes comprobar SPF, DKIM y DMARC con servicios como MXToolbox, Google Admin Toolbox, Mail Tester o los paneles de tu proveedor SMTP. Env\u00eda un correo de prueba y analiza cabeceras. Las cabeceras de email son feas, s\u00ed, pero dicen la verdad con una frialdad admirable. \ud83d\udd0d<\/p>\n<h2 id=\"estados\">Estados de pedido: el interruptor olvidado de muchos emails<\/h2>\n<p>En PrestaShop, muchas notificaciones de pedido dependen de los <strong>estados de pedido<\/strong>. Cada estado puede tener asociada una plantilla y una opci\u00f3n para enviar correo al cliente. Si esa casilla no est\u00e1 activa, no se enviar\u00e1 nada, aunque el SMTP est\u00e9 perfecto y los DNS canten como un coro.<\/p>\n<h3>Qu\u00e9 revisar<\/h3>\n<p>Ve a <strong>Par\u00e1metros de la tienda &gt; Configuraci\u00f3n de pedidos &gt; Estados<\/strong> o una ruta similar seg\u00fan tu versi\u00f3n. Abre estados como:<\/p>\n<ul>\n<li>Pago aceptado<\/li>\n<li>Preparaci\u00f3n en curso<\/li>\n<li>Enviado<\/li>\n<li>Cancelado<\/li>\n<li>Reembolso<\/li>\n<li>Esperando pago por transferencia bancaria<\/li>\n<li>Esperando pago contra reembolso<\/li>\n<\/ul>\n<p>Comprueba:<\/p>\n<ul>\n<li>Que la opci\u00f3n <strong>Enviar email al cliente<\/strong> est\u00e9 activada cuando corresponda.<\/li>\n<li>Que exista una <strong>plantilla de email<\/strong> asociada.<\/li>\n<li>Que la plantilla exista en el idioma del cliente.<\/li>\n<li>Que el m\u00f3dulo de pago cambie el pedido al estado correcto.<\/li>\n<li>Que el pedido no se quede en un estado intermedio que no dispara email.<\/li>\n<\/ul>\n<p>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\u00e1tica tiene ese talento para humillarnos con detalles peque\u00f1os.<\/p>\n<h2 id=\"plantillas\">Plantillas de correo: cuando falta una pieza del idioma<\/h2>\n<p>PrestaShop utiliza plantillas de email en formato HTML y texto. Normalmente se encuentran en directorios como <strong>\/mails\/<\/strong>, dentro del tema o del n\u00facleo, organizadas por idioma: <strong>\/mails\/es\/<\/strong>, <strong>\/mails\/en\/<\/strong>, <strong>\/themes\/tu_tema\/mails\/es\/<\/strong>, etc. La ubicaci\u00f3n exacta puede variar seg\u00fan la versi\u00f3n, el tema y las personalizaciones.<\/p>\n<h3>Fallos habituales en plantillas<\/h3>\n<ul>\n<li>La plantilla existe en ingl\u00e9s pero no en espa\u00f1ol.<\/li>\n<li>El tema sobrescribe una plantilla antigua incompatible.<\/li>\n<li>Falta la versi\u00f3n <strong>.txt<\/strong> o <strong>.html<\/strong>.<\/li>\n<li>Hay variables mal escritas o eliminadas.<\/li>\n<li>Una traducci\u00f3n desde el back office guard\u00f3 contenido incompleto.<\/li>\n<li>Permisos de archivos impiden leer las plantillas.<\/li>\n<\/ul>\n<p>Si el email de prueba funciona pero un estado de pedido no env\u00eda 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.<\/p>\n<h3>C\u00f3mo regenerar o revisar plantillas<\/h3>\n<ol>\n<li>Haz copia de seguridad del tema y de la carpeta <strong>\/mails\/<\/strong>.<\/li>\n<li>Compara las plantillas del tema con las del n\u00facleo de PrestaShop.<\/li>\n<li>Verifica que exista la plantilla asociada al estado de pedido.<\/li>\n<li>Revisa traducciones desde <strong>Internacional &gt; Traducciones<\/strong>.<\/li>\n<li>Si usas un tema comprado, comprueba si incluye plantillas desactualizadas.<\/li>\n<li>Prueba temporalmente con el tema cl\u00e1sico o con plantillas originales en un entorno de pruebas.<\/li>\n<\/ol>\n<p>    <strong>No edites en producci\u00f3n sin respaldo.<\/strong> Una plantilla de email parece inocente, pero puede romper confirmaciones de pedido, facturas adjuntas o variables cr\u00edticas. Trabaja primero en staging si la tienda vende activamente. \ud83d\udee0\ufe0f<\/p>\n<h2 id=\"logs\">Logs de PrestaShop y del servidor: donde el sistema deja migas<\/h2>\n<p>Un diagn\u00f3stico 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\u00e9n pueden registrar rechazos, timeouts o errores de autenticaci\u00f3n.<\/p>\n<h3>D\u00f3nde mirar<\/h3>\n<ul>\n<li><strong>Back office:<\/strong> Par\u00e1metros avanzados &gt; Registros, seg\u00fan versi\u00f3n.<\/li>\n<li><strong>Archivos de logs de PrestaShop:<\/strong> carpetas como <strong>\/var\/logs\/<\/strong> en instalaciones modernas.<\/li>\n<li><strong>Logs de PHP:<\/strong> definidos por el hosting o por <strong>php.ini<\/strong>.<\/li>\n<li><strong>Logs del servidor web:<\/strong> Apache o Nginx.<\/li>\n<li><strong>Logs del servidor de correo:<\/strong> Exim, Postfix, Sendmail, si tienes acceso.<\/li>\n<li><strong>Panel del proveedor SMTP:<\/strong> eventos de entrega, rebotes, bloqueos, quejas y rechazos.<\/li>\n<\/ul>\n<h3>Errores frecuentes y qu\u00e9 significan<\/h3>\n<table>\n<thead>\n<tr>\n<th>Error o mensaje<\/th>\n<th>Interpretaci\u00f3n probable<\/th>\n<th>Acci\u00f3n recomendada<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Authentication failed<\/td>\n<td>Usuario, contrase\u00f1a o m\u00e9todo de autenticaci\u00f3n incorrectos<\/td>\n<td>Verifica credenciales, usa clave de aplicaci\u00f3n si el proveedor la exige<\/td>\n<\/tr>\n<tr>\n<td>Connection timed out<\/td>\n<td>Puerto bloqueado, firewall, host SMTP inaccesible<\/td>\n<td>Prueba otro puerto, consulta al hosting, revisa reglas de salida<\/td>\n<\/tr>\n<tr>\n<td>Connection refused<\/td>\n<td>Servidor SMTP rechaza conexi\u00f3n o puerto equivocado<\/td>\n<td>Confirma host, puerto y cifrado<\/td>\n<\/tr>\n<tr>\n<td>Relay access denied<\/td>\n<td>El servidor no permite enviar desde esa cuenta o dominio<\/td>\n<td>Autentica SMTP, alinea remitente y usuario<\/td>\n<\/tr>\n<tr>\n<td>Could not instantiate mail function<\/td>\n<td>Problema con PHP mail() o MTA local<\/td>\n<td>Cambia a SMTP autenticado o pide soporte al hosting<\/td>\n<\/tr>\n<tr>\n<td>Expected response code 250 but got 550<\/td>\n<td>Rechazo del servidor receptor o pol\u00edtica antispam<\/td>\n<td>Analiza rebote, SPF\/DKIM\/DMARC y reputaci\u00f3n<\/td>\n<\/tr>\n<tr>\n<td>SSL routines \/ certificate verify failed<\/td>\n<td>Problema con certificado, CA o protocolo<\/td>\n<td>Actualiza certificados del servidor, usa puerto\/cifrado correcto<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Si tienes acceso SSH, una prueba de conectividad puede ahorrar horas. Por ejemplo, comprobar si el servidor alcanza el SMTP:<\/p>\n<p>    Comprobar conexi\u00f3n al puerto 587:<br \/>\n    telnet smtp.tudominio.com 587<\/p>\n<p>    O con OpenSSL para STARTTLS:<br \/>\n    openssl s_client -starttls smtp -connect smtp.tudominio.com:587<\/p>\n<p>En muchos hostings compartidos no tendr\u00e1s acceso a estas herramientas. No pasa nada. Pide al soporte que confirme si los puertos 465 y 587 est\u00e1n permitidos para conexiones salientes. Hazlo con precisi\u00f3n: \u201c\u00bfbloquean ustedes conexiones SMTP salientes al puerto 587?\u201d funciona mejor que \u201cel correo no va\u201d, esa frase que en soporte t\u00e9cnico cae como lluvia sobre un tejado de zinc.<\/p>\n<h2 id=\"hosting\">Hosting, firewalls y l\u00edmites: el cartero tambi\u00e9n tiene horario<\/h2>\n<p>El hosting influye m\u00e1s de lo que parece. Hay servidores que limitan el n\u00famero de correos por hora, bloquean puertos SMTP externos, deshabilitan funciones PHP o aplican filtros autom\u00e1ticos al contenido. No necesariamente por maldad; casi siempre por supervivencia. El spam convirti\u00f3 Internet en una ciudad con demasiadas cerraduras.<\/p>\n<h3>L\u00edmites t\u00edpicos del hosting<\/h3>\n<ul>\n<li>M\u00e1ximo de emails por hora o por d\u00eda.<\/li>\n<li>Bloqueo del puerto 25.<\/li>\n<li>Bloqueo parcial de SMTP externo en planes compartidos.<\/li>\n<li>Rechazo de remitentes que no pertenezcan al dominio alojado.<\/li>\n<li>Suspensi\u00f3n temporal por tasa elevada de rebotes.<\/li>\n<li>Filtros antispam salientes que bloquean mensajes con enlaces sospechosos.<\/li>\n<\/ul>\n<h3>Casos t\u00edpicos tras una migraci\u00f3n<\/h3>\n<p>Despu\u00e9s de migrar PrestaShop a otro servidor, pueden aparecer fallos que antes no exist\u00edan:<\/p>\n<ol>\n<li>El DNS del dominio apunta a la web nueva, pero los registros MX siguen mal configurados.<\/li>\n<li>El SPF a\u00fan autoriza al proveedor antiguo, no al nuevo.<\/li>\n<li>El servidor nuevo no tiene permisos para usar mail().<\/li>\n<li>La versi\u00f3n de PHP cambi\u00f3 y un m\u00f3dulo de correo qued\u00f3 incompatible.<\/li>\n<li>Las plantillas no se copiaron con permisos correctos.<\/li>\n<li>El firewall bloquea conexiones SMTP salientes.<\/li>\n<\/ol>\n<p>La migraci\u00f3n es una mudanza: uno cree haber llevado todos los muebles, hasta que descubre que la llave de la caja fuerte se qued\u00f3 en el caj\u00f3n de la cocina antigua.<\/p>\n<h2 id=\"modulos\">M\u00f3dulos, overrides y cach\u00e9: los fantasmas elegantes de PrestaShop<\/h2>\n<p>PrestaShop es flexible, y esa flexibilidad es al mismo tiempo virtud y trampa. M\u00f3dulos de pago, m\u00f3dulos de alertas, integraciones ERP, temas comerciales y overrides pueden intervenir en el proceso de env\u00edo. Algunos lo hacen bien. Otros lo hacen como quien repara un reloj con cinta adhesiva.<\/p>\n<h3>M\u00f3dulos que pueden afectar los correos<\/h3>\n<ul>\n<li>M\u00f3dulos de pago: cambian estados de pedido y disparan confirmaciones.<\/li>\n<li>M\u00f3dulos de email marketing: capturan eventos o modifican plantillas.<\/li>\n<li>M\u00f3dulos SMTP de terceros: reemplazan el env\u00edo nativo.<\/li>\n<li>M\u00f3dulos de facturaci\u00f3n: adjuntan PDF o modifican emails de pedido.<\/li>\n<li>M\u00f3dulos de atenci\u00f3n al cliente: alteran formularios de contacto.<\/li>\n<li>Conectores externos: ERP, marketplaces, log\u00edstica, CRM.<\/li>\n<\/ul>\n<h3>C\u00f3mo aislar un conflicto<\/h3>\n<ol>\n<li>Activa el modo mantenimiento si vas a probar en producci\u00f3n, o mejor usa staging.<\/li>\n<li>Revisa m\u00f3dulos instalados o actualizados justo antes del fallo.<\/li>\n<li>Desactiva temporalmente m\u00f3dulos relacionados con email, pago o pedido.<\/li>\n<li>Limpia cach\u00e9 desde el back office.<\/li>\n<li>Si tienes overrides, revisa especialmente clases relacionadas con <strong>Mail<\/strong>, <strong>OrderHistory<\/strong> y estados de pedido.<\/li>\n<li>Consulta logs despu\u00e9s de cada cambio, no diez cambios despu\u00e9s.<\/li>\n<\/ol>\n<p>En PrestaShop, los overrides pueden ser \u00fatiles, pero tambi\u00e9n son c\u00e1psulas del tiempo: c\u00f3digo escrito para una versi\u00f3n concreta que sigue ejecut\u00e1ndose a\u00f1os despu\u00e9s, solemne y desactualizado, como un funcionario imperial en una oficina con fibra \u00f3ptica.<\/p>\n<h2>Correos que se env\u00edan pero no llegan: entregabilidad, spam y reputaci\u00f3n<\/h2>\n<p>Este es el territorio m\u00e1s traicionero. PrestaShop puede enviar correctamente y, aun as\u00ed, el cliente no recibe el correo en bandeja de entrada. No es magia negra; es entregabilidad. Los grandes proveedores analizan reputaci\u00f3n de IP, dominio, autenticaci\u00f3n, contenido, enlaces, historial de quejas y comportamiento de usuarios. El email moderno se parece menos a una carta y m\u00e1s a una entrevista de seguridad en un aeropuerto.<\/p>\n<h3>Factores que da\u00f1an la entregabilidad<\/h3>\n<ul>\n<li>Dominio sin SPF, DKIM o DMARC.<\/li>\n<li>Remitente distinto al dominio autenticado.<\/li>\n<li>IP compartida con mala reputaci\u00f3n.<\/li>\n<li>Muchos rebotes a direcciones inexistentes.<\/li>\n<li>Clientes marcando emails como spam.<\/li>\n<li>Contenido con demasiadas may\u00fasculas, signos de exclamaci\u00f3n o enlaces acortados.<\/li>\n<li>Adjuntos pesados o sospechosos.<\/li>\n<li>Plantillas HTML mal formadas o sin versi\u00f3n texto.<\/li>\n<li>Enviar campa\u00f1as promocionales desde el mismo canal que los emails transaccionales.<\/li>\n<\/ul>\n<h3>Buenas pr\u00e1cticas para emails transaccionales de PrestaShop<\/h3>\n<ul>\n<li>Usa un remitente reconocible: <strong>pedidos@tudominio.com<\/strong>.<\/li>\n<li>No cambies de remitente constantemente.<\/li>\n<li>Incluye nombre comercial claro en el campo \u201cDe\u201d.<\/li>\n<li>Mant\u00e9n plantillas limpias, ligeras y con enlaces al dominio correcto.<\/li>\n<li>No uses acortadores de URL en confirmaciones de pedido.<\/li>\n<li>Asegura que el dominio en enlaces coincide con la tienda.<\/li>\n<li>Configura SPF, DKIM y DMARC.<\/li>\n<li>Monitorea rebotes en el proveedor SMTP.<\/li>\n<li>Separa marketing de transaccional.<\/li>\n<\/ul>\n<p>    <strong>Prueba pr\u00e1ctica:<\/strong> env\u00eda un correo transaccional a una cuenta Gmail, abre el mensaje, pulsa \u201cMostrar original\u201d y revisa si SPF, DKIM y DMARC aparecen como <strong>PASS<\/strong>. Si alguno falla, ah\u00ed tienes una pista luminosa. No siempre la \u00fanica, pero s\u00ed una buena.<\/p>\n<h2>Problemas espec\u00edficos con Gmail, Outlook, Microsoft 365 y Yahoo<\/h2>\n<p>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\u00eda desde un dominio mal autenticado, con IP nueva o con una plantilla dudosa, puede caer en spam o ser rechazada.<\/p>\n<h3>Gmail<\/h3>\n<ul>\n<li>Exige autenticaci\u00f3n s\u00f3lida para remitentes con volumen.<\/li>\n<li>Valora DKIM y DMARC alineados.<\/li>\n<li>Penaliza dominios con alta tasa de quejas.<\/li>\n<li>Puede clasificar como spam mensajes con enlaces inconsistentes o contenido agresivo.<\/li>\n<\/ul>\n<h3>Outlook y Microsoft 365<\/h3>\n<ul>\n<li>Suelen ser estrictos con reputaci\u00f3n de IP.<\/li>\n<li>Algunos rangos de hosting compartido tienen peor aceptaci\u00f3n.<\/li>\n<li>Microsoft puede bloquear temporalmente IPs con historial problem\u00e1tico.<\/li>\n<li>Conviene revisar registros SPF y DKIM con especial cuidado.<\/li>\n<\/ul>\n<h3>Yahoo<\/h3>\n<ul>\n<li>Aplica controles fuertes de autenticaci\u00f3n.<\/li>\n<li>Observa la tasa de spam reportada por usuarios.<\/li>\n<li>Tiende a favorecer remitentes consistentes y bien configurados.<\/li>\n<\/ul>\n<p>Si tus correos llegan a dominios corporativos pero no a Gmail, o al rev\u00e9s, no asumas que PrestaShop fall\u00f3. Puede ser una pol\u00edtica del receptor. El correo electr\u00f3nico es una frontera con m\u00faltiples guardias, y cada guardia tiene su propio humor.<\/p>\n<h2>Errores despu\u00e9s de actualizar PrestaShop o cambiar PHP<\/h2>\n<p>Actualizar PrestaShop o PHP mejora seguridad y rendimiento, pero tambi\u00e9n puede exponer m\u00f3dulos 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\u00f3dulo usa c\u00f3digo no compatible. La modernidad entra por la puerta con casco brillante; detr\u00e1s vienen los avisos de deprecaci\u00f3n.<\/p>\n<h3>Qu\u00e9 revisar tras una actualizaci\u00f3n<\/h3>\n<ul>\n<li>Compatibilidad de m\u00f3dulos SMTP o email.<\/li>\n<li>Overrides de clases relacionadas con correo.<\/li>\n<li>Errores PHP en logs.<\/li>\n<li>Permisos de carpetas tras despliegue.<\/li>\n<li>Plantillas del tema frente a nuevas plantillas del n\u00facleo.<\/li>\n<li>Cach\u00e9 de Symfony\/PrestaShop, seg\u00fan versi\u00f3n.<\/li>\n<\/ul>\n<p>Si el fallo empez\u00f3 justo despu\u00e9s de una actualizaci\u00f3n, no pierdas tiempo mirando DNS durante tres horas. Mira primero el cambio reciente. En soporte t\u00e9cnico, la cronolog\u00eda suele ser m\u00e1s honesta que la intuici\u00f3n.<\/p>\n<h2>Seguridad: no conviertas tu tienda en una m\u00e1quina de spam<\/h2>\n<p>Un formulario de contacto mal protegido, una cuenta SMTP con contrase\u00f1a d\u00e9bil o un m\u00f3dulo vulnerable pueden convertir tu PrestaShop en un emisor de spam. Entonces los correos leg\u00edtimos empiezan a fallar porque tu dominio o servidor queda marcado. Es la paradoja amarga: el sistema que deb\u00eda hablar con tus clientes acaba gritando basura al mundo.<\/p>\n<h3>Medidas b\u00e1sicas de protecci\u00f3n<\/h3>\n<ul>\n<li>Usa contrase\u00f1as robustas para cuentas SMTP.<\/li>\n<li>Activa autenticaci\u00f3n de dos factores donde el proveedor lo permita.<\/li>\n<li>Utiliza claves de aplicaci\u00f3n en Gmail o servicios similares.<\/li>\n<li>Mant\u00e9n PrestaShop, m\u00f3dulos y tema actualizados.<\/li>\n<li>Protege formularios con reCAPTCHA o soluciones antispam adecuadas.<\/li>\n<li>Limita env\u00edos desde formularios p\u00fablicos.<\/li>\n<li>Revisa usuarios administradores y permisos.<\/li>\n<li>Escanea malware si aparecen env\u00edos desconocidos.<\/li>\n<\/ul>\n<p>Si tu proveedor SMTP muestra miles de env\u00edos que no reconoces, det\u00e9n la cuenta, cambia credenciales y audita la instalaci\u00f3n. No sigas probando. Un grifo roto no se arregla observando c\u00f3mo inunda el sal\u00f3n.<\/p>\n<h2>Gu\u00eda paso a paso para solucionar el problema<\/h2>\n<p>Ahora, el procedimiento ordenado. Sin \u00e9pica innecesaria. Sin disparar a todas las sombras.<\/p>\n<h3>Paso 1: Confirma el alcance del fallo<\/h3>\n<ul>\n<li>\u00bfNo se env\u00eda ning\u00fan correo?<\/li>\n<li>\u00bfSolo fallan pedidos?<\/li>\n<li>\u00bfSolo falla el formulario de contacto?<\/li>\n<li>\u00bfSe env\u00edan pero llegan a spam?<\/li>\n<li>\u00bfFalla con ciertos dominios como Gmail u Outlook?<\/li>\n<\/ul>\n<h3>Paso 2: Prueba el env\u00edo desde PrestaShop<\/h3>\n<p>Usa el correo de prueba del back office. Guarda el error exacto si aparece. No lo resumas como \u201csale algo rojo\u201d; copia el mensaje completo.<\/p>\n<h3>Paso 3: Cambia a SMTP autenticado<\/h3>\n<p>Si est\u00e1s usando PHP mail(), configura SMTP. Usa datos oficiales del proveedor. Verifica puerto y cifrado:<\/p>\n<ul>\n<li>587 + TLS\/STARTTLS<\/li>\n<li>465 + SSL<\/li>\n<\/ul>\n<h3>Paso 4: Alinea el remitente<\/h3>\n<p>El usuario SMTP y el remitente deber\u00edan pertenecer al mismo dominio o estar autorizados por el proveedor. Por ejemplo:<\/p>\n<ul>\n<li>Usuario SMTP: <strong>pedidos@tudominio.com<\/strong><\/li>\n<li>Remitente de la tienda: <strong>pedidos@tudominio.com<\/strong><\/li>\n<li>Nombre remitente: <strong>Nombre de tu tienda<\/strong><\/li>\n<\/ul>\n<h3>Paso 5: Configura SPF, DKIM y DMARC<\/h3>\n<p>Entra al panel DNS del dominio y a\u00f1ade los registros indicados por tu proveedor SMTP. Despu\u00e9s verifica con herramientas externas. No conf\u00edes solo en \u201cya lo puse\u201d; DNS tiene esa cortes\u00eda antigua de tardar un poco en ser verdad.<\/p>\n<h3>Paso 6: Revisa estados de pedido<\/h3>\n<p>Comprueba que los estados relevantes env\u00edan email y tienen plantilla. Haz una prueba cambiando manualmente el estado de un pedido de prueba.<\/p>\n<h3>Paso 7: Revisa plantillas por idioma<\/h3>\n<p>Si la tienda est\u00e1 en espa\u00f1ol, confirma que existan las plantillas en <strong>\/mails\/es\/<\/strong> o en la ruta equivalente del tema. Si tienes varios idiomas, prueba con clientes de cada idioma.<\/p>\n<h3>Paso 8: Mira logs<\/h3>\n<p>Consulta registros de PrestaShop, PHP, servidor y proveedor SMTP. Los errores de autenticaci\u00f3n, conexi\u00f3n o rechazo suelen aparecer all\u00ed antes que en la interfaz.<\/p>\n<h3>Paso 9: Descarta m\u00f3dulos conflictivos<\/h3>\n<p>Desactiva temporalmente m\u00f3dulos relacionados con correo, pagos o pedidos en un entorno seguro. Limpia cach\u00e9 y prueba de nuevo.<\/p>\n<h3>Paso 10: Consulta al hosting con datos concretos<\/h3>\n<p>Env\u00eda al soporte:<\/p>\n<ul>\n<li>Hora exacta de la prueba.<\/li>\n<li>Direcci\u00f3n remitente y destinataria.<\/li>\n<li>Servidor SMTP y puerto usado.<\/li>\n<li>Error registrado.<\/li>\n<li>Versi\u00f3n de PHP y PrestaShop.<\/li>\n<\/ul>\n<p>Un ticket preciso recibe mejores respuestas. El soporte no es or\u00e1culo; aunque algunos t\u00e9cnicos, en noches largas, casi lo parezcan.<\/p>\n<h2 id=\"checklist\">Checklist final para recuperar los emails de tu PrestaShop \u2705<\/h2>\n<table>\n<thead>\n<tr>\n<th>Revisi\u00f3n<\/th>\n<th>Estado<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>El email de prueba de PrestaShop funciona<\/td>\n<td>\u2610<\/td>\n<\/tr>\n<tr>\n<td>SMTP configurado con host, usuario, contrase\u00f1a, puerto y cifrado correctos<\/td>\n<td>\u2610<\/td>\n<\/tr>\n<tr>\n<td>El remitente pertenece al dominio de la tienda<\/td>\n<td>\u2610<\/td>\n<\/tr>\n<tr>\n<td>SPF configurado con el proveedor SMTP autorizado<\/td>\n<td>\u2610<\/td>\n<\/tr>\n<tr>\n<td>DKIM activo y validando correctamente<\/td>\n<td>\u2610<\/td>\n<\/tr>\n<tr>\n<td>DMARC creado al menos con pol\u00edtica inicial p=none<\/td>\n<td>\u2610<\/td>\n<\/tr>\n<tr>\n<td>Estados de pedido con \u201cEnviar email al cliente\u201d activado<\/td>\n<td>\u2610<\/td>\n<\/tr>\n<tr>\n<td>Plantillas disponibles en el idioma correcto<\/td>\n<td>\u2610<\/td>\n<\/tr>\n<tr>\n<td>Logs revisados despu\u00e9s de cada prueba<\/td>\n<td>\u2610<\/td>\n<\/tr>\n<tr>\n<td>M\u00f3dulos de pago y correo actualizados<\/td>\n<td>\u2610<\/td>\n<\/tr>\n<tr>\n<td>Hosting confirma que no bloquea el puerto SMTP usado<\/td>\n<td>\u2610<\/td>\n<\/tr>\n<tr>\n<td>Correos probados en Gmail, Outlook y dominio corporativo<\/td>\n<td>\u2610<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Preguntas frecuentes sobre correos en PrestaShop<\/h2>\n<h3>\u00bfPor qu\u00e9 el email de prueba funciona pero los clientes no reciben confirmaciones de pedido?<\/h3>\n<p>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\u00f3dulo de pago y logs. Tambi\u00e9n verifica si el correo llega a spam o si el proveedor SMTP registra rebotes.<\/p>\n<h3>\u00bfEs mejor usar SMTP que PHP mail()?<\/h3>\n<p>S\u00ed, para una tienda profesional casi siempre es mejor SMTP autenticado. Ofrece m\u00e1s control, mejor entregabilidad, registros de env\u00edo y compatibilidad con SPF, DKIM y DMARC. PHP mail() puede funcionar, pero suele ser menos fiable y m\u00e1s opaco.<\/p>\n<h3>\u00bfPuedo usar Gmail como SMTP en PrestaShop?<\/h3>\n<p>Se puede, pero no siempre es lo ideal para una tienda. Gmail puede requerir claves de aplicaci\u00f3n, autenticaci\u00f3n adicional y tiene l\u00edmites de env\u00edo. Para comercio electr\u00f3nico serio conviene usar un correo del dominio o un proveedor transaccional especializado.<\/p>\n<h3>\u00bfPor qu\u00e9 mis correos llegan a spam?<\/h3>\n<p>Las causas m\u00e1s comunes son ausencia de SPF\/DKIM\/DMARC, mala reputaci\u00f3n de IP o dominio, remitente no alineado, contenido sospechoso, enlaces acortados, exceso de im\u00e1genes o historial de quejas. PrestaShop puede enviar bien y aun as\u00ed sufrir problemas de entregabilidad.<\/p>\n<h3>\u00bfD\u00f3nde est\u00e1n las plantillas de email en PrestaShop?<\/h3>\n<p>Suelen estar en carpetas como <strong>\/mails\/<\/strong> o dentro del tema en <strong>\/themes\/tu_tema\/mails\/<\/strong>, organizadas por idioma. La ubicaci\u00f3n exacta depende de la versi\u00f3n y del tema. Revisa tambi\u00e9n las traducciones desde el back office.<\/p>\n<h3>\u00bfQu\u00e9 hago si el hosting bloquea SMTP?<\/h3>\n<p>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\u00e1s adecuado para comercio electr\u00f3nico.<\/p>\n<h2>Cuando el correo vuelve, vuelve algo m\u00e1s que un mensaje<\/h2>\n<p>Arreglar los emails de PrestaShop no es solo resolver una incidencia t\u00e9cnica. Es restaurar el hilo de conversaci\u00f3n entre la tienda y el cliente. Un pedido sin confirmaci\u00f3n parece una habitaci\u00f3n sin luz: quiz\u00e1 todo est\u00e9 en su sitio, pero nadie se siente tranquilo. En cambio, un correo puntual \u2014sobrio, claro, autenticado\u2014 funciona como una mano que se extiende desde la maquinaria invisible del ecommerce y dice: \u201chemos recibido tu pedido, todo va bien\u201d.<\/p>\n<p>La soluci\u00f3n rara vez est\u00e1 en un \u00fanico bot\u00f3n 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\u00f3dulo con demasiada memoria del pasado. Pero con un m\u00e9todo ordenado, el problema deja de ser niebla. Se vuelve mapa.<\/p>\n<p>Y esa es la peque\u00f1a victoria: que la tienda, por fin, vuelva a hablar. Que los correos salgan limpios, atraviesen filtros y lleguen a destino como golondrinas con br\u00fajula. Que el cliente compre, reciba su confirmaci\u00f3n y no tenga que preguntarse si acaba de pagar en una tienda o en un agujero negro con logotipo. \u2709\ufe0f\ud83d\ude80<\/p>\n<\/article>\n<p><\/main><\/p>\n","protected":false},"excerpt":{"rendered":"<p>\u00bfPor qu\u00e9 mi tienda PrestaShop no env\u00eda correos a los clientes y c\u00f3mo solucionarlo? Una<\/p>\n","protected":false},"author":1,"featured_media":3684,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","_seopress_news_disabled":"","_seopress_video_disabled":"","_seopress_video":[],"_seopress_pro_schemas_manual":[],"_seopress_pro_rich_snippets_disable_all":"","_seopress_pro_rich_snippets_disable":[],"_seopress_pro_schemas":[],"footnotes":""},"categories":[2],"tags":[],"class_list":["post-3685","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mantenimiento"],"_links":{"self":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3685","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/comments?post=3685"}],"version-history":[{"count":1,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3685\/revisions"}],"predecessor-version":[{"id":3686,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3685\/revisions\/3686"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/media\/3684"}],"wp:attachment":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/media?parent=3685"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/categories?post=3685"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/tags?post=3685"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}