Los correos de tu tienda no llegan: SMTP, SPF, DKIM y DMARC explicados

«No me ha llegado la confirmación del pedido.» Si lo oyes a menudo, el problema no es el cliente. Los proveedores de correo (Gmail, Outlook, Yahoo y los demás) son cada vez más estrictos con los mensajes que reciben, y un correo que no demuestra bien de dónde viene acaba en spam o directamente rechazado. Para una tienda, eso son clientes inquietos, llamadas al servicio de atención y contraseñas que nadie puede recuperar.

Vamos a ver cómo envía los correos PrestaShop y qué hay que configurar para que lleguen.

Cómo envía correos PrestaShop

En Parámetros avanzados → Correo electrónico eliges cómo sale el correo:

• La función de correo de PHP del servidor. Es lo que viene por defecto y lo más cómodo, pero el correo sale desde el servidor web, que muchas veces no está autorizado a enviar en nombre de tu dominio. Es la causa más frecuente de correos en spam.
• Un servidor SMTP. La tienda se conecta con usuario y contraseña a un buzón real (el de tu proveedor de correo o un servicio de envío transaccional) y envía a través de él. Es lo recomendable.

En esa misma pantalla puedes enviar un correo de prueba. Úsalo después de cada cambio, y envíalo a buzones de varios proveedores.

Las tres comprobaciones que hace el destinatario

SPF: quién puede enviar en nombre de tu dominio

Es un registro TXT en el DNS de tu dominio que enumera los servidores autorizados a enviar correo con tu dominio en el remitente. Cuando llega un correo, el destinatario mira desde qué servidor viene y si está en esa lista.

Errores típicos:

• Tener dos registros SPF en el mismo dominio. Solo puede haber uno; si hay dos, la comprobación falla. Cuando añades un servicio nuevo, se amplía el registro existente, no se crea otro.
• No incluir todos los que envían: el servidor de la tienda, el proveedor de correo, la herramienta de boletines, el ERP que manda facturas.
• Pasarse del límite de consultas. SPF permite como máximo diez búsquedas DNS al evaluarse, y cada include cuenta (con los que lleve dentro). Con muchos servicios, se supera sin darse cuenta.

DKIM: la firma del mensaje

El servidor que envía firma cada correo con una clave privada, y publica la clave pública en el DNS de tu dominio. El destinatario comprueba la firma: si cuadra, el mensaje viene de quien dice y no se ha modificado por el camino.

Lo activa el proveedor que envía (tu servicio de correo o de envío transaccional), que te da el registro que hay que añadir al DNS. Si usas la función de correo de PHP del servidor web, normalmente no hay firma DKIM, o la hay con el dominio del hosting, no con el tuyo.

DMARC: qué hacer si falla, y que te lo cuenten

Es otro registro TXT, en _dmarc.tudominio, que dice a los destinatarios qué hacer con un correo que dice ser de tu dominio pero no pasa SPF o DKIM de forma alineada (es decir, con el mismo dominio del remitente visible). Tiene tres políticas:

• p=none: no hagas nada especial, solo infórmame.
• p=quarantine: trátalo como sospechoso (normalmente, a spam).
• p=reject: recházalo.

Y puede pedir informes a una dirección tuya, en los que los proveedores te cuentan qué correos con tu dominio han recibido y si pasaban las comprobaciones. Es la forma de descubrir servicios que envían en tu nombre y que habías olvidado, o a alguien que suplanta tu dominio.

Lo prudente es empezar con p=none, revisar los informes unas semanas hasta que todo lo legítimo pase, y endurecer después.

Por qué ahora importa más

Los grandes proveedores de correo han ido endureciendo los requisitos. Desde 2024, Gmail y Yahoo exigen a quienes envían grandes volúmenes tener SPF, DKIM y DMARC, y al resto, al menos una autenticación correcta. Aunque tu tienda no envíe miles de correos al día, si tu herramienta de boletines sí lo hace con tu dominio, el dominio entero queda afectado. Y sin autenticación, cada vez es más probable que un correo de pedido no llegue a la bandeja de entrada.

Otras causas de que no lleguen

• Reputación del servidor o de la IP: si comparte IP con otros que envían spam, todos pagan.
• Contenido: correos solo con una imagen, enlaces acortados, mucho texto en mayúsculas o asuntos agresivos. Los correos de pedido deben ser sobrios y tener versión en texto plano.
• Mezclar correos de pedido y promociones en el mismo envío y con el mismo remitente. Si los boletines generan quejas, arrastran a los transaccionales.
• Buzón lleno o dirección mal escrita del cliente. Ahí ayuda validar el correo en el registro y revisar los rebotes.
• Límites del SMTP: muchos buzones normales limitan cuántos correos se pueden enviar por hora o por día. En campañas fuertes, la tienda puede chocar con ese techo.

Cómo comprobarlo

1. Envía un correo de prueba desde la tienda a un buzón de Gmail y abre el mensaje original: verás si SPF, DKIM y DMARC aparecen como PASS y con qué dominio.
2. Consulta los registros TXT de tu dominio con cualquier herramienta de DNS y comprueba que hay un solo SPF y un DMARC.
3. Haz la lista de todo lo que envía correo con tu dominio y comprueba que cada uno firma con DKIM y está en el SPF.
4. Revisa los informes de DMARC durante unas semanas antes de pasar a quarantine o reject.

Cómo resolverlo en PrestaShop

La entrega depende del DNS y del servidor de correo; el contenido, de las plantillas. RKR Mail Editor incluye un editor visual de los correos de PrestaShop con el que editas el asunto, el HTML y la versión en texto plano de cada plantilla en cada idioma, y añade a los correos de pedido productos recomendados, un cupón único para la siguiente compra y banners por campaña, con un enlace de baja en cada correo que lleva bloques comerciales. Si lo que necesitas es configurar el SMTP de la tienda, revisar tu SPF, activar DKIM con tu proveedor o poner DMARC en marcha sin perder correos, con un bono de horas de soporte de Rekire lo revisamos y lo dejamos funcionando.