Configuración del correo electrónico en PrestaShop: SMTP, Gmail y correo transaccional

Última revisión: junio de 2026, refleja las reglas de autenticación para remitentes masivos de Gmail/Yahoo que entraron en vigor en 2024. Los límites y precios de los proveedores cambian, así que confirma las cifras actuales con cada proveedor. Rutas del back office verificadas en PrestaShop 1.7, 8.x y 9.x.

"Mis clientes no reciben los correos de confirmación de pedido." Es una de las consultas de soporte más habituales que abre cualquier comerciante con una tienda PrestaShop, y casi nunca se debe a un error de PrestaShop. El correo electrónico parece la parte más sencilla de gestionar una tienda: la plataforma envía una confirmación en cuanto se realiza un pedido. Pero el recorrido que hace ese mensaje desde tu servidor hasta la bandeja de entrada del cliente pasa por restricciones del alojamiento, registros de autenticación y filtros antispam que pueden fallar en silencio. El pedido entra, el cobro se realiza y el cliente no recibe nada. Entonces te escribe o, peor aún, asume que la compra no ha funcionado y disputa el cargo. Esta guía trata específicamente de cómo conseguir una entrega fiable de correos desde PrestaShop: los ajustes exactos del back office, las decisiones importantes al elegir proveedor SMTP, los registros DNS que evitan que acabes en spam y cómo comprobar que todo funciona antes de que sea un cliente real quien descubra que no.

Los dos métodos de correo que te ofrece PrestaShop, y por qué uno de ellos te engaña

Abre Parámetros avanzados → Correo electrónico en tu back office y verás que PrestaShop ofrece dos formas de enviar correo: la función PHP integrada mail() y "Establecer mis propios parámetros SMTP". La opción PHP mail() entrega tu mensaje al agente de correo local que viva en tu servidor web (Sendmail o Postfix). Sobre el papel funciona. En la práctica, en el alojamiento compartido y gestionado donde funcionan la mayoría de las tiendas PrestaShop, es la causa principal de "mis correos han desaparecido":

• Los proveedores de hosting la desactivan. Muchos proveedores apagan mail() por completo para frenar el abuso de spam desde sitios comprometidos. PrestaShop puede ver solo una entrega local correcta; los fallos de entrega finales suelen aparecer únicamente en los registros del servidor o del proveedor, no en el back office.
• A menudo no incluye una autenticación adecuada. PHP mail() no autentica por sí misma, así que, salvo que tu servidor/MTA y tus DNS estén configurados a propósito, un mensaje enviado de esta forma suele carecer de una alineación correcta de SPF, DKIM o DMARC, y Gmail, Outlook y Yahoo modernos tratan por defecto como spam el correo no autenticado de un remitente masivo. (Gmail y Yahoo endurecieron formalmente estas reglas para remitentes masivos en 2024.)
• No te da información real sobre la entrega. La función devuelve true o false en la entrega al servidor local, no en la entrega final. "True" te dice que el servidor aceptó el mensaje, pero nada sobre si llegó a una bandeja de entrada, rebotó o fue filtrado.
• Hereda la reputación de una IP compartida. En un hosting compartido envías desde una IP que también usan decenas de otros sitios; si uno de ellos hace spam, tus confirmaciones de pedido pagan las consecuencias.

La conclusión práctica es breve: usa SMTP, siempre, apuntando a un servicio de correo real. El resto de esta guía explica cómo hacerlo correctamente.

Configuración SMTP en PrestaShop, campo por campo

En Parámetros avanzados → Correo electrónico, elige "Establecer mis propios parámetros SMTP" y se te pedirán los siguientes datos. Todos los proveedores de abajo rellenan estas mismas casillas; solo cambian los valores:

• Servidor SMTP, el nombre de host del proveedor (por ejemplo smtp.gmail.com).
• Nombre de usuario SMTP, normalmente la dirección completa del remitente, aunque algunos servicios usan un literal fijo (SendGrid quiere la palabra apikey).
• Contraseña SMTP, la contraseña del buzón, una contraseña específica de aplicación o una clave de API, según el proveedor.
• Cifrado, TLS (puerto 587) o SSL (puerto 465). Nunca elijas "Desactivado"; eso envía tus credenciales sin cifrar por internet.
• Puerto SMTP, 587 para TLS (el valor moderno por defecto) o 465 para SSL.

¿Qué ganas exactamente cuando configuras bien estos campos? Una conexión que se autentica como remitente legítimo, que es la condición previa para todo lo que viene después: firma DKIM, llegada a la bandeja de entrada y un panel del proveedor que sí te dice qué ha pasado con cada mensaje. Estos son los tres niveles de proveedor en los que suelen acabar la mayoría de tiendas PrestaShop.

SMTP de Gmail, correcto para una tienda pequeña, con un techo claro

Gmail suele ser la primera opción porque el comerciante ya tiene la cuenta. La configuración:

Para generar la contraseña de aplicación: en tu cuenta de Google ve a Seguridad → Verificación en 2 pasos → Contraseñas de aplicaciones, crea una para "Correo" / "Otro (nombre personalizado)" etiquetada como "PrestaShop" y pega la cadena de 16 caracteres en el campo de contraseña SMTP de PrestaShop. Primero debe estar activada la verificación en 2 pasos; de lo contrario, Google no mostrará la opción de contraseñas de aplicaciones.

El problema es el volumen. Una cuenta gratuita de Gmail tiene un límite aproximado de 500 destinatarios al día; Google Workspace lo eleva a unos 2.000. Cada pedido de PrestaShop suele disparar dos o tres correos: confirmación al cliente, notificación al administrador y una notificación posterior de envío. Por eso, una tienda con más de 100 pedidos diarios puede rozar el techo de Gmail gratuito y, cuando lo supera, el correo empieza a aplazarse o rechazarse sin una señal clara en el back office. Gmail sirve para empezar, no como destino final.

SMTP de Outlook / Microsoft 365

Microsoft ha ido restringiendo de forma progresiva la autenticación SMTP básica, así que en muchos inquilinos tendrás que activar explícitamente SMTP autenticado para el buzón en el centro de administración de Exchange antes de que PrestaShop pueda conectarse. Si la prueba de conexión falla en Microsoft 365 con credenciales que por lo demás son correctas, ese interruptor suele ser el motivo.

Servicios de correo transaccional, la respuesta cuando ya tienes volumen real

Por encima de unos cientos de mensajes al día, pasa a un servicio diseñado para envíos transaccionales: SendGrid, Mailgun, Brevo o Amazon SES. Te dan reputación de envío dedicada, gestión automática de rebotes y quejas, y un panel de entrega: justo lo que Gmail no puede ofrecer. SendGrid como ejemplo:

Los precios y los límites de los planes gratuitos cambian, así que consulta la página actual del proveedor en lugar de fiarte de una cifra en un artículo de blog. Pero la ventaja estructural no cambia: una IP de envío cuya reputación gestionáis activamente tú y el proveedor, datos de rebotes devueltos a tu panel y estado de entrega por mensaje. Para cualquier tienda en la que una confirmación de pedido perdida te cueste una consulta de soporte o una devolución de cargo, esa visibilidad es precisamente lo importante.

Autenticación del correo: SPF, DKIM y DMARC

Una configuración SMTP correcta saca el mensaje fuera. Tres registros DNS deciden si el servidor receptor confía lo suficiente como para ponerlo en la bandeja de entrada. Sin ellos, incluso un SMTP perfectamente configurado acaba en spam. Es la segunda queja más común sobre correo después de "no se envía nada" y, a diferencia de los ajustes de PrestaShop, estos registros viven en los DNS de tu dominio, no en el back office.

SPF, quién tiene permiso para enviar como tú

SPF (Sender Policy Framework) es un registro DNS TXT que lista los servidores autorizados a enviar correo para tu dominio. Un servidor receptor lo comprueba para confirmar que el mensaje procede de una fuente autorizada. Un registro típico para una tienda que envía a través de Google y SendGrid sería:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Incluye solo los servicios desde los que realmente envías; cada include adicional debilita ligeramente el registro, y SPF tiene un límite estricto de 10 consultas DNS antes de fallar por completo.

DKIM. Una firma que demuestra que nada se ha manipulado

DKIM (DomainKeys Identified Mail) añade una firma criptográfica a cada mensaje y demuestra que procede de tu dominio y que no se ha alterado en tránsito. Tu proveedor genera la clave; tú la publicas como registro TXT o CNAME. Para Google Workspace en un dominio personalizado, actívalo en Aplicaciones → Google Workspace → Gmail → Autenticar correo electrónico. Para SendGrid, usa Configuración → Autenticación de remitente → Autenticar tu dominio, que te entregará los registros CNAME que debes añadir a DNS.

DMARC, qué hacer con el correo que falla los dos primeros controles

DMARC une SPF y DKIM y les dice a los receptores cómo tratar los mensajes que fallan. Empieza en modo de supervisión para no romper nada:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Esto te informa de los fallos sin bloquear nada. Después de unas semanas con informes limpios, endurece la política a p=quarantine (enviar los fallos a spam) y, finalmente, a p=reject (bloquearlos). Pasar directamente a p=reject antes de confirmar que tu correo legítimo supera las comprobaciones es una forma habitual de que una tienda bloquee por accidente sus propias confirmaciones de pedido.

Configurar correctamente la dirección "De" (un asesino silencioso de la entregabilidad)

La dirección del remitente de PrestaShop se configura en Parámetros de la tienda → Contacto → Tiendas (y en el correo de contacto de cada tienda). Un fallo sutil, pero muy común: esa dirección "De" debe alinearse con el dominio que has autenticado para SMTP. Enviar como info@yourstore.com mientras te autenticas a través de smtp.gmail.com con una identidad @gmail.com crea una discrepancia de autenticación que SPF/DMARC marcará, y tu correo caerá en spam aunque cada ajuste individual "parezca" correcto. Mantén el dominio de envío, la identidad SMTP y los registros de autenticación apuntando todos al mismo lugar.

Demostrar que funciona, antes de que lo demuestre un cliente

No te fíes de una pantalla de configuración que dice "guardado". Prueba la ruta real de entrega:

• La prueba integrada de PrestaShop. En la página Parámetros avanzados → Correo electrónico hay un campo "Enviar un email de prueba": envíate uno a ti mismo y confirma que llega a la bandeja de entrada, no a spam.
• mail-tester.com. Envía un mensaje a la dirección que te muestra; puntúa SPF, DKIM, DMARC, el contenido y el estado en listas negras sobre 10. Apunta a 9+ antes de darlo por terminado.
• Prueba con varios proveedores. Envía por separado a Gmail, Outlook/Hotmail y Yahoo; sus reglas antispam difieren, y superar una no significa superar las tres.
• Lee las cabeceras. En un mensaje recibido en Gmail, entra en tres puntos → Mostrar original y busca SPF: PASS, DKIM: PASS y DMARC: PASS. Si alguno dice FAIL o NONE, corrige el registro DNS correspondiente antes de pasar a producción.

Correo transaccional frente a correo de marketing, mantenlos por separado

Esta guía trata sobre el correo transaccional: confirmaciones de pedido, avisos de envío, restablecimientos de contraseña; los mensajes que PrestaShop dispara automáticamente como resultado directo de una acción del cliente. Trátalos como un flujo distinto de los boletines y promociones de marketing, porque mezclarlos te cuesta caro:

• Contaminación de la reputación. Si tu boletín recibe quejas de spam y usa la misma IP o dominio que tus confirmaciones de pedido, arrastra también a esas confirmaciones.
• Reglas legales distintas. El correo transaccional no requiere enlace de baja (es necesario para completar la compra); el correo de marketing sí. Separarlos mantiene limpia la línea de cumplimiento.
• Picos de volumen. Un envío masivo de boletín a 50.000 destinatarios puede saturar una conexión SMTP compartida y retrasar la confirmación de pedido sensible al tiempo que el cliente está esperando.

Buena práctica: envía el correo transaccional de PrestaShop a través de tu servicio SMTP y gestiona los boletines desde una plataforma dedicada (Mailchimp, Brevo, Klaviyo). Si quieres conectar esos dos mundos, por ejemplo, enviar automáticamente un nuevo cliente de PrestaShop a tu lista de boletín, enlázalos con una capa de automatización en lugar de mezclar flujos de envío; explicamos la forma sin código de hacerlo en Zapier y Make para PrestaShop y, específicamente para disparadores de flujos de trabajo, en PrestaShop y Zapier sin escribir código.

La lista de diagnóstico para "no se envían los emails"

Estos son los casos que vemos con más frecuencia cuando los comerciantes nos piden revisar correos rotos en PrestaShop, aproximadamente en el orden en que merece la pena comprobarlos.

No se envía nada

• Lee primero el registro de correos. Cuando el registro está activado, Parámetros avanzados → Correo electrónico lista los mensajes que PrestaShop intentó enviar (destinatario, plantilla, asunto, hora). Si los mensajes aparecen registrados pero no llegan, PrestaShop los está generando y entregando, pero fallan más adelante (autenticación o spam). Si no aparece nada registrado, el envío falla antes de ese punto: vuelve a comprobar host SMTP, puerto y credenciales, y confirma que el propio registro esté activado.
• Vuelve a probar las credenciales directamente. Inicia sesión en el buzón o en la consola del proveedor con el mismo nombre de usuario y contraseña que pegaste en PrestaShop. Si tú no puedes, PrestaShop tampoco.
• Comprueba que el puerto no esté bloqueado por firewall. Algunos hosts bloquean el tráfico saliente por 587/465. Si la prueba de conexión agota el tiempo de espera, pide a tu proveedor de hosting que confirme que esos puertos están abiertos para tráfico saliente.

El correo se envía, pero cae en spam

• SPF/DKIM ausentes o fallando. Verifica con mxtoolbox.com que ambos registros existen y pasan para tu dominio.
• Desajuste en la dirección De. Consulta la sección "De" anterior; es una de las causas de spam que más se pasan por alto.
• Contenido de plantilla con aspecto de spam. Lenguaje cargado de "gratis / descuento / actúa ahora" y una mala proporción entre texto e imagen en plantillas personalizadas activan filtros de contenido.

Fallos intermitentes

• Límite de tasa. Estás superando el límite diario de envío del proveedor; compara tu volumen real con el límite del plan y sube de plan o cambia de proveedor si ya se te ha quedado pequeño.
• Tiempos de espera de conexión. Un servidor SMTP lento puede superar el tiempo de espera de conexión por defecto de PrestaShop; aumentarlo (por ejemplo, de 5 a 20 segundos) suele resolver envíos inestables.

Enviado correctamente, pero el cliente dice que no ha recibido nada

Comprueba si la dirección del cliente tiene una errata, revisa el registro de rebotes de tu proveedor y pídele que mire en spam y añada tu dirección de envío a la lista de permitidos. "Enviado" en PrestaShop solo significa que el mensaje fue aceptado por el servidor SMTP; el panel del proveedor es donde ves si rebotó. Cuando hayas confirmado que la dirección es correcta y que la causa de entregabilidad está corregida, querrás reenviar esa confirmación concreta en lugar de dejar al cliente sin nada: nuestro módulo Resend Order Confirmation vuelve a lanzar la confirmación de pedido directamente desde la página del pedido, para que un fallo puntual de entrega no se convierta en reconstruir manualmente el correo.

Personalizar las plantillas de correo de PrestaShop

Las plantillas de correo de PrestaShop pueden vivir en varias ubicaciones mails/<language_code>/, directorios de correo del núcleo, del tema y de los módulos, según tu versión, tema y módulos instalados; cada tipo existe como archivo HTML y como respaldo TXT de texto plano. Las versiones más recientes (1.7/8/9) también te permiten editar el aspecto en Diseño → Tema de correo electrónico. Algunas reglas para que las plantillas personalizadas se rendericen bien en todas partes:

• Usa CSS en línea, muchos clientes de correo eliminan los bloques <style>.
• Maqueta con tablas; el renderizado de HTML en correo está prácticamente anclado en 2005.
• Mantén el ancho por debajo de 600px para móvil.
• Prueba en varios clientes (Gmail web, Outlook de escritorio, Apple Mail, móvil).
• Nunca borres los marcadores como {firstname}, {lastname} o {order_name}; PrestaShop los sustituye por datos reales en el momento del envío, y eliminarlos rompe la combinación.

Registro y monitorización real de la entrega

Cuando el registro de correo está activado, PrestaShop guarda cada intento de envío en su base de datos, visible en Parámetros avanzados → Correo electrónico, con el destinatario, la plantilla usada, el idioma, el asunto y la hora de envío. Pero recuerda qué significa una entrada en esa lista: PrestaShop entregó el mensaje al servidor SMTP. No es una prueba de entrega en bandeja de entrada, y el registro no incluye un estado entregado/rebotado por mensaje. Para esa verdad necesitas el panel de tu proveedor: SendGrid, Mailgun y Amazon SES informan por mensaje de entregados, rebotados, aplazados y tasas de queja. Échales un vistazo cada semana; una tasa de rebote que va subiendo es la señal temprana de que se está formando un problema de entregabilidad antes de que los clientes empiecen a notarlo.

Preguntas frecuentes

¿Por qué no se entregan mis correos de confirmación de pedido de PrestaShop?

La causa más común es usar PHP mail() en un hosting que la desactiva o que envía sin autenticación: Gmail, Outlook y Yahoo modernos mandan a la papelera o a spam el correo masivo no autenticado. Cambia a "Establecer mis propios parámetros SMTP" en Parámetros avanzados → Correo electrónico, apúntalo a un servicio de correo real y publica registros SPF, DKIM y DMARC. Después demuestra la ruta con una prueba antes de confiarle pedidos reales.

¿Qué puerto SMTP y qué cifrado debería usar?

El puerto 587 con TLS es el valor moderno por defecto y el que recomiendan la mayoría de proveedores; el puerto 465 con SSL es la alternativa antigua y sigue funcionando. Nunca elijas "Desactivado": eso envía tus credenciales sin cifrar. Si una prueba de conexión agota el tiempo de espera en cualquiera de los puertos, es posible que tu hosting esté bloqueando SMTP saliente y tendrás que pedirles que lo abran.

¿Puedo usar simplemente mi cuenta de Gmail para enviar los correos de la tienda?

Para una tienda pequeña, sí: usa smtp.gmail.com en el puerto 587/TLS con una contraseña de aplicación de 16 caracteres (no tu contraseña de acceso, y primero debe estar activada la verificación en 2 pasos). Pero una cuenta gratuita de Gmail tiene un límite aproximado de 500 destinatarios/día y Workspace ronda los 2.000. Como cada pedido dispara dos o tres correos, una tienda por encima de unos 100 pedidos/día tocará ese techo y el correo empezará a aplazarse en silencio. Gmail sirve para empezar, no como destino final: pasa a SendGrid, Mailgun, Brevo o Amazon SES cuando tengas volumen.

Mi correo se envía, pero cae en spam: ¿qué falla?

Casi siempre falta autenticación, la autenticación falla o hay un desajuste en la dirección De. Verifica que SPF y DKIM existen y pasan (mxtoolbox.com), y asegúrate de que el dominio de tu dirección "De" coincide con el dominio a través del que autenticas SMTP: enviar como info@yourstore.com mientras te autenticas con una identidad @gmail.com queda marcado por SPF/DMARC y cae en spam aunque cada ajuste "parezca" correcto.

Un cliente dice que nunca recibió su confirmación: ¿qué hago ahora?

Primero confirma que realmente ha habido un fallo: comprueba si la dirección tiene una errata y revisa el registro de rebotes de tu proveedor ("Enviado" en PrestaShop solo significa que el servidor SMTP lo aceptó, no que se entregara). Corrige la causa de entregabilidad de fondo y luego reenvía esa confirmación concreta en lugar de dejar al cliente sin nada: Resend Order Confirmation la vuelve a lanzar desde la página del pedido con un clic.

¿Las confirmaciones de pedido y mi boletín deberían pasar por el mismo servicio?

No: mantenlas por separado. Si tu boletín genera quejas de spam y comparte IP/dominio con tu correo transaccional, arrastra tus confirmaciones de pedido con él. Envía el correo transaccional mediante tu servicio SMTP y gestiona los boletines desde una plataforma dedicada (Mailchimp, Brevo, Klaviyo). Conecta ambos mundos con una capa de automatización si lo necesitas, en lugar de mezclar los flujos de envío.

Dónde encaja el correo en una tienda que empieza a superar el trabajo manual

Un correo transaccional fiable es la base, pero rara vez es el único punto donde una tienda en crecimiento pierde tiempo e información. El mismo evento de pedido que dispara una confirmación suele necesitar llegar también a tu sistema contable y, con el tiempo, a tu ERP; copiar esos datos a mano es exactamente el tipo de trabajo manual que se rompe cuando aumenta el volumen. Si ya tienes resueltos los correos de pedido, pero el resto de tu back office sigue funcionando con copiar y pegar, estos son los siguientes dominós:

• Contabilidad. Llevar automáticamente los datos de factura de cada pedido a Xero o QuickBooks, en lugar de volver a introducirlos a mano; consulta conectar PrestaShop con tu software contable.
• ERP. Cuando stock, pedidos y clientes deben mantenerse sincronizados con un sistema de back office, los patrones de integración que de verdad aguantan están explicados en patrones de integración entre PrestaShop y ERP, y las señales de que ha llegado el momento en cuando tu tienda supera el trabajo manual.
• Conexión sin código. Para integraciones más ligeras, enviar un nuevo cliente a una lista, publicar un pedido en una herramienta, consulta Zapier y Make para PrestaShop.

La entregabilidad del correo no es vistosa, y precisamente por eso se descuida hasta que un cliente que nunca recibió su confirmación abre una disputa. Lleva SMTP a un proveedor real, publica tus registros SPF, DKIM y DMARC, alinea tu dirección "De" y demuestra toda la ruta con una prueba antes de confiarle pedidos reales. Para módulos que amplían las capacidades de gestión e integración de una tienda PrestaShop, construidos para sobrevivir a las actualizaciones de versión de PrestaShop y PHP en lugar de romperse en la siguiente, explora el catálogo en mypresta.rocks.