Guías Guía

Conseguir que los correos de su tienda lleguen

Por qué los emails de PrestaShop llegan a spam y cómo lo resuelven SMTP, SPF/DKIM/DMARC y el email transaccional, con los ajustes de correo en PS 8/9.

Las confirmaciones de pedido acaban en spam: la queja sobre correo número uno que recibimos

Un cliente paga. El registro de correo de PrestaShop dice "enviado". El correo de confirmación nunca llega, o cae en la pestaña Promociones, o se queda en la carpeta de spam durante seis horas. El cliente entra en pánico, abre una devolución de cargo, deja una reseña de una estrella y escribe a soporte preguntando "¿me han cobrado el dinero?". Hemos visto esto suceder en más tiendas de las que podemos contar y, en 2026, sigue siendo el problema de correo más habitual en PrestaShop.

La solución rara vez está dentro de PrestaShop. La entregabilidad la decide el servidor de correo receptor (Gmail, Outlook, Yahoo) y lo que deciden depende de cómo se autentique, de qué reputación tenga su IP de envío y de si su DNS dice la verdad sobre quién está autorizado a enviar en nombre de su dominio. El trabajo de PrestaShop consiste únicamente en entregar el mensaje de forma limpia.

La función mail() de PHP es puro teatro

Una instalación nueva de PrestaShop envía mediante la función mail() de PHP. Esta es la opción predeterminada, y es la peor que se nos ocurre para una tienda en producción:

  • Sin autenticación. El mensaje llega sin prueba alguna de que usted lo haya autorizado. Gmail y Outlook tratan el correo no autenticado como culpable hasta que se demuestre lo contrario.
  • IP compartida, reputación compartida. En el alojamiento compartido su correo sale desde la misma IP que otros 200 sitios. Uno de ellos envía spam y todos lo sufren.
  • Sin firma DKIM. mail() no firma nada de forma criptográfica. No hay nada que el destinatario pueda verificar.
  • Encabezados mínimos. Los filtros de spam lo puntúan como sospechoso antes siquiera de mirar el cuerpo.
Si su tienda todavía usa mail(), pasar a un SMTP real es el único cambio que solucionará más problemas de entregabilidad que todos los demás pasos de esta página juntos. Hágalo primero.

Qué hace realmente que un mensaje se marque como spam

  • Discrepancia en la dirección de origen. Enviar desde noreply@yourstore.com mientras su DNS no tiene ningún registro SPF que autorice a la IP de su servidor a hacerlo.
  • Plantillas cargadas de imágenes. Las plantillas predeterminadas de PrestaShop son muy ricas en imágenes. Una mala proporción entre imagen y texto es de por sí una señal de spam.
  • Falta la parte de texto plano. PrestaShop envía en formato multiparte de forma predeterminada, pero las plantillas personalizadas y los módulos de traducción pueden romper sin avisar la alternativa de texto plano.
  • Enlaces rotos. Los filtros de spam resuelven las URL de su mensaje. Si su tienda está en modo mantenimiento, tiene una cadena SSL defectuosa o devuelve errores 500, su correo queda marcado.
  • Basura de codificación. Las tiendas con diacríticos polacos, checos, alemanes o franceses producen mojibake en cuanto una parte de la cadena deja de ser UTF-8.

Configuración del correo de PrestaShop por versión

Configuración del correo en el panel de administración de PrestaShop 8.

La elección entre sendmail y SMTP, el formato del correo, el interruptor de registro y la firma DKIM. Si sus confirmaciones de pedido acaban en spam, este es el punto de partida.

Página de configuración de Correo electrónico del panel de administración de PrestaShop 8 que muestra la elección entre sendmail y SMTP, la configuración DKIM y el registro de correo

La página de ajustes se ha mantenido más o menos en el mismo lugar. La biblioteca subyacente cambió por completo en PS 9.

PrestaShop 1.6 y 1.7

Parámetros avanzados → Correo electrónico. Elija "Configurar mis propios parámetros SMTP" e introduzca el servidor, el puerto, el cifrado, el usuario y la contraseña. PS 1.6 utiliza la propia gestión SMTP de PHP; PS 1.7 incorporó Swift Mailer. Opciones de cifrado:

  • TLS (puerto 587): El estándar moderno. STARTTLS, la respuesta correcta en casi todos los casos.
  • SSL (puerto 465): TLS implícito más antiguo. Algunos alojamientos heredados todavía lo exigen.
  • Ninguno (puerto 25): Sin cifrar. No lo haga.

PrestaShop 8.x

La misma pantalla, la misma interfaz. PS 8 incluye la última versión de Swift Mailer con un mejor informe de errores: cuando SMTP falla, usted obtiene una línea útil en var/logs/ en lugar de una caída silenciosa.

PrestaShop 9: Symfony Mailer

PS 9 jubila Swift Mailer (lleva años descontinuado en su origen) y lo sustituye por Symfony Mailer. La interfaz de administración parece idéntica, pero todo lo que hay debajo ha cambiado:

  • Configuración basada en DSN. Internamente el transporte es un URI: smtp://user:password@server:port.
  • Detección automática de TLS. El puerto 587 negociará STARTTLS automáticamente. El desplegable de "cifrado" a veces se comporta de forma diferente tras una actualización de 8 → 9; vuelva a probarlo.
  • Validación más estricta. A Symfony Mailer le importa que el remitente del sobre coincida con el encabezado From, y valida correctamente los certificados TLS.
  • Rotura de módulos. Cualquier módulo que importe Swift_Message o Swift_SmtpTransport deja de funcionar en PS 9 hasta que se actualice.
# Ejemplos de DSN interno de PS 9 (configurados a través de la interfaz de administración)
smtp://user:password@mail.example.com:587      # STARTTLS
smtps://user:password@mail.example.com:465     # TLS implícito
smtp://your%40gmail.com:app-pass@smtp.gmail.com:587  # Gmail
native://default                                # mail() de PHP (no recomendado)
Vuelva a probar siempre el correo después de cualquier actualización de 8 → 9. Hemos visto certificados autofirmados, puertos no estándar y servidores SMTP implementados de forma laxa dejar de funcionar en el momento en que Symfony Mailer toma el control.

El botón "enviar correo de prueba"

Todas las versiones lo tienen. Es útil, pero confirma una sola cosa: que su tienda puede abrir una conexión SMTP. No confirma que el mensaje haya llegado a una bandeja de entrada. Envíe pedidos de prueba reales a una dirección de Gmail, a una de Outlook y a una de su propio dominio: esas tres cubren aproximadamente el 90% de lo que utilizan sus clientes.

Autenticación del dominio: SPF, DKIM, DMARC

SPF, DKIM y DMARC son tres registros DNS que, en conjunto, demuestran que su correo es legítimo. Gmail y Yahoo hicieron obligatorios SPF y DKIM para los remitentes masivos en febrero de 2024. Nosotros los tratamos como obligatorios para todo remitente, sin excepción.

SPF (Sender Policy Framework)

Un único registro TXT en su dominio que nombra las IP y los servicios autorizados a enviar en su nombre.

# Básico: permite el alojamiento + Google
v=spf1 include:_spf.google.com include:your-hosting-provider.com ~all

# OVH
v=spf1 include:mx.ovh.com ~all

# Hostinger
v=spf1 include:_spf.hostinger.com ~all

# Con Mailgun
v=spf1 include:mailgun.org include:_spf.google.com ~all

Dónde se tuerce esto:

  • Dos registros SPF. Solo un registro TXT por dominio es SPF válido. Dos registros se anulan entre sí. Combine los servicios en un único registro con varias directivas include:.
  • Demasiadas consultas. SPF permite 10 consultas DNS en total. Cada include: cuenta, y los includes anidados también cuentan. Pase el suyo por un validador antes de publicarlo.
  • +all en lugar de ~all. +all le dice al mundo que cualquiera puede enviar en su nombre, que es justo lo contrario de la idea. Empiece con ~all (softfail) y endurézcalo a -all cuando tenga confianza.
  • Los subdominios no se heredan. El SPF para shop.example.com necesita su propio registro. El dominio principal no lo cubre.

DKIM

DKIM firma criptográficamente cada mensaje saliente. PrestaShop no firma DKIM: lo hace su relé SMTP, su proveedor de alojamiento o su servicio transaccional. Usted publica su clave pública en el DNS y ellos firman con la clave privada correspondiente.

  • Alojamiento compartido (cPanel/Plesk): Normalmente es un clic en cPanel → Email Deliverability.
  • Gmail / Google Workspace: Consola de administración → Gmail → Autenticar correo electrónico. Google le entrega un registro TXT.
  • Servicios transaccionales: Su asistente de verificación de dominio le indica exactamente qué publicar.
# Ejemplo de registro TXT de DKIM
# Nombre: default._domainkey.yourstore.com (el selector varía según el proveedor)
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

DMARC

DMARC une SPF y DKIM e indica al servidor receptor qué hacer cuando falla la autenticación.

# Fase 1: Solo supervisión
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourstore.com;

# Fase 2: Poner en cuarentena los fallos
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourstore.com;

# Fase 3: Rechazar los fallos (máxima protección)
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourstore.com;

La dirección rua recibe informes agregados en XML: una lista diaria de quién ha intentado enviar correo en nombre de su dominio. Los nuestros los pasamos por la supervisión DMARC gratuita de Postmark, porque leer XML en bruto no es manera de pasar la mañana del lunes.

Despliegue DMARC por fases. De dos a cuatro semanas en p=none mientras lee los informes e identifica a los remitentes legítimos que fallan. Endurézcalo a p=quarantine durante otras dos a cuatro semanas. Solo entonces pase a p=reject. Saltar directamente a reject el primer día bloquea correo cuya existencia desconocía: normalmente un CRM o un contable que envía facturas en su nombre.

SMTP en alojamiento compartido

La mayoría de las tiendas PrestaShop viven en alojamiento compartido. Cree un buzón dedicado (por ejemplo, orders@yourstore.com) y use esas credenciales en PrestaShop, nunca su bandeja de entrada personal.

Ajustes por proveedor

# cPanel genérico
Server: mail.yourstore.com | Port: 587 | Encryption: TLS

# OVH
Server: ssl0.ovh.net | Port: 587 | Encryption: TLS

# Hostinger
Server: smtp.hostinger.com | Port: 587 | Encryption: TLS

# SiteGround
Server: yourstore.com | Port: 465 | Encryption: SSL

# Bluehost
Server: mail.yourstore.com | Port: 465 | Encryption: SSL

SMTP de Gmail

Campos de configuración SMTP en PrestaShop 8.

Cuando se selecciona "Configurar mis propios parámetros SMTP", aparecen estos campos: servidor, puerto, usuario, contraseña, cifrado. Aquí es donde se apunta PrestaShop hacia Gmail, SendGrid, Mailgun o su propio servidor de correo.

Configuración SMTP de PrestaShop 8 que muestra los campos de servidor, puerto, usuario, contraseña y cifrado

Esto es lo que usamos nosotros mismos para mypresta.rocks: SMTP de Gmail con una contraseña de aplicación (Cuenta de Google → Seguridad → Verificación en dos pasos → Contraseñas de aplicaciones). Barato, fiable y sensato para una tienda de bajo volumen.

Server: smtp.gmail.com | Port: 587 | Encryption: TLS
Username: your@gmail.com | Password: (16-char App Password)

Límites: Gmail gratuito 500/día, Google Workspace 2000/día. Si envía en ráfagas demasiado rápidas, Google lo limitará temporalmente.

El SMTP de Gmail funciona bien para tiendas de menos de unos 30 pedidos al día. Por encima de eso empieza a chocar con el límite, y los clientes esperan hasta 24 horas su confirmación. Ese es el momento de pasar a un servicio transaccional de verdad.

SMTP de Microsoft 365

Server: smtp.office365.com | Port: 587 | Encryption: TLS
Username: your@yourstore.com | Password: account or App Password

Límite: 10 000 destinatarios/día, 30 mensajes/minuto. Microsoft insiste cada vez más en OAuth en lugar de la autenticación SMTP básica; compruebe la política de su tenant antes de ponerlo en producción.

Servicios de correo transaccional

Cuando supera el SMTP del alojamiento, los servicios transaccionales le dan infraestructura dedicada de alta reputación, firma DKIM gestionada por ellos, procesamiento de rebotes y un panel que le dice qué le ha pasado realmente a cada mensaje.

Cuándo dar el salto

  • Está chocando con los límites de envío de su alojamiento.
  • El correo acaba en spam incluso con SPF, DKIM y DMARC todos en verde.
  • Necesita seguimiento de entrega y gestión de rebotes.
  • La reputación de su IP compartida lo está lastrando y no puede hacer nada al respecto.

Cuáles merece la pena usar

Mailgun: desde 15 $/mes por 10 000 correos. API sólida, analíticas útiles. SMTP en smtp.mailgun.org:587.

Postmark: desde 15 $/mes por 10 000 correos. La mejor tasa de bandeja de entrada que hemos medido. Separación tajante entre los flujos transaccional y de marketing, que es exactamente la arquitectura correcta. SMTP en smtp.postmarkapp.com:587, el Server API Token va tanto en el usuario como en la contraseña.

Amazon SES: 0,10 $ por cada 1000 correos. El más barato a escala por un orden de magnitud. Genere las credenciales SMTP dentro de la consola de SES (no sus claves de AWS IAM). Las cuentas nuevas empiezan en modo sandbox hasta que solicita el acceso de producción. Endpoint específico de región, por ejemplo email-smtp.eu-west-1.amazonaws.com:587.

SendGrid: nivel gratuito 100/día, de pago desde 19,95 $/mes. El usuario es literalmente la cadena apikey, la contraseña es su clave de API. SMTP en smtp.sendgrid.net:587. El nivel gratuito comparte IP con todos los demás del nivel gratuito, así que ahí la entregabilidad es mala: presupueste para la versión de pago.

Brevo: nivel gratuito 300/día, de pago desde 9 $/mes. Boletín y CRM integrados, con sede en la UE (cómodo para el RGPD). SMTP en smtp-relay.brevo.com:587. Tiene su propio plugin de PrestaShop por si lo quiere.

Nuestras opciones por defecto: Brevo si quiere tener los boletines en el mismo sitio. Postmark si lo que le importa es la tasa de bandeja de entrada transaccional. Amazon SES para gran volumen con presupuesto ajustado. Mailgun como el todoterreno seguro.

Cómo se conecta

Todos hablan SMTP estándar, sin necesidad de ningún módulo. Verifique el dominio, publique sus registros SPF y DKIM, genere las credenciales SMTP, péguelas en PrestaShop y pruebe.

Correo autoalojado

Puede ejecutar su propio servidor de correo. Nosotros lo hacemos: usamos Mailcow para parte de nuestra infraestructura. Le da control total, sin tarifas por correo, sin que un tercero lea los datos de sus clientes. El coste es un trabajo de administración de sistemas continuo y real, y sacar la reputación de cero lleva semanas.

Cuándo merece la pena

  • Privacidad. Los datos de correo de los clientes nunca salen de sus máquinas. Genuinamente útil para lecturas estrictas del RGPD.
  • Volumen. Pasados los 100 000 mensajes al mes, un VPS de 40 $ es más barato que cualquier servicio transaccional.
  • Control. Sus reglas, sus límites, sin suspensiones de cuenta por "infracciones de política" que decidió un robot.

Cuándo no

  • Sin experiencia en administración de sistemas. Un servidor de correo mal configurado es peor que el alojamiento compartido: al menos la IP del alojamiento tiene algo de reputación.
  • IP nueva. Una IP de envío recién estrenada es invisible para los receptores. La reputación se construye a lo largo de semanas. Los servicios transaccionales le entregan reputación consolidada desde el primer día.
  • Sin registro PTR. Sin DNS inverso, la mayoría de los receptores rechazan su correo de plano.
  • Mantenimiento. Parches, certificados, supervisión de listas de bloqueo, revisión de registros: continuo, no opcional.

Lo que elegiríamos

Mailcow: Basado en Docker, con webmail, antispam, antivirus y autodescubrimiento, todo incluido. 4 GB+ de RAM. Esto es lo que usamos.

Mail-in-a-Box: Todo en uno sobre un host Ubuntu dedicado. Más sencillo, pero se apropia de la máquina.

iRedMail: Postfix + Dovecot tradicional. El más flexible, el más ligero, el más manual.

Envíe su propio correo de empresa a través de un servidor autoalojado nuevo durante tres meses antes de enrutar un solo pedido de cliente por él. Construya la reputación poco a poco. Mantenga un servicio transaccional conectado como respaldo durante todo ese tiempo.

Los tipos de correo que envía PrestaShop

Deben llegar a la bandeja de entrada de inmediato

  • Confirmación de pedido (order_conf). El que provoca devoluciones de cargo y malas reseñas cuando no llega. Protéjalo por encima de todos los demás.
  • Confirmación de pago (payment). Los clientes están nerviosos hasta que lo ven.
  • Restablecimiento de contraseña (password_query). Sensible al tiempo. Diez minutos tarde y el cliente ya ha desistido.
  • Creación de cuenta (account). La primera impresión de su tienda en la bandeja de entrada del cliente.

Deberían llegar con prontitud

  • Notificación de envío (shipping). Aquí vive el número de seguimiento.
  • Actualizaciones de estado del pedido (order_changed). En preparación, enviado, entregado.
  • Factura y reembolso. Crítico para el B2B, tranquilizador para todos.
Mantenga el correo transaccional y los boletines en dominios distintos. Los correos de pedido salen desde su dominio principal; los boletines, desde un subdominio como news@mail.yourstore.com. El día que un boletín provoque quejas de spam, no se llevará por delante sus confirmaciones de pedido.

Las plantillas viven en mails/{iso_code}/. Cada una tiene una versión HTML y una de texto plano. Conserve ambas: la falta de un .txt es de por sí una señal de spam, y hemos visto módulos de traducción eliminarlas en silencio durante la sincronización.

El alojamiento y el correo

Lo que el alojamiento compartido no puede arreglar

  • Reputación de IP compartida. Comparte una IP con cientos de otros sitios y no puede controlar lo que envían.
  • Topes de envío. Normalmente 100-500/hora, 500-5000/día. Una venta flash se lo come en minutos.
  • Sin IP dedicada. No se ofrece a este nivel de precio.
  • Control limitado del DNS. Los alojamientos baratos a veces no le dejan publicar un registro DKIM, TXT o PTR personalizado.
  • Puerto saliente 587 bloqueado. Sí, esto sigue ocurriendo, y le impide conectarse a cualquier servicio transaccional.

Lo que le da un VPS

  • Una IP dedicada con una reputación que es solo suya
  • Sin límites de envío artificiales
  • PTR (DNS inverso): innegociable para una entregabilidad seria
  • Control total del DNS, cualquier servidor de correo que quiera

Señales de alarma del alojamiento

  • "Correo ilimitado". No existe en el alojamiento compartido. Texto de marketing, nada más.
  • Sin compatibilidad con DKIM. Aléjese.
  • Puerto 587 bloqueado. No podrá usar ningún servicio transaccional.
  • IP en lista de bloqueo. Compruébelo en MXToolbox antes de contratar, no después.
La mejor jugada en alojamiento compartido es ignorar por completo el correo del alojamiento. Conecte un servicio transaccional a PrestaShop mediante SMTP. Su tienda envía a través de la reputación consolidada de ellos y el problema de la IP compartida deja de existir.

Qué cambió en PrestaShop 8 y 9

PS 8: el último Swift Mailer

El último Swift Mailer 6.x estable, con mejor negociación TLS, registros de errores más útiles en var/logs/ y los metadatos del mensaje saliente registrados en ps_mail. Prueba por CLI desde la consola: php bin/console prestashop:mail:test recipient@example.com.

PS 9: Symfony Mailer

Sustitución completa del transporte. Aspectos clave que conviene saber:

  • Distingue smtp:// (STARTTLS, puerto 587) de smtps:// (TLS implícito, puerto 465). Los dos ya no son intercambiables.
  • Más estricto con que el remitente del sobre coincida con el encabezado From: algunos relés SMTP que funcionaban en PS 8 dejan de aceptar correo.
  • Validación más estricta de los certificados TLS. Los certificados autofirmados que iban tirando en PS 8 fallarán.
  • Los módulos que importaban Swift_Message o Swift_SmtpTransport se rompen en PS 9 hasta que el desarrollador los actualiza.
# Correo de PS 9 mediante variables de entorno (avanzado)
# .env.local: anula los ajustes del panel de administración
MAILER_DSN=smtp://user:password@smtp.example.com:587
MAILER_DSN=smtp://user%40gmail.com:app-pass@smtp.gmail.com:587
# Los caracteres especiales deben codificarse en URL: @ = %40, : = %3A

Solo para desarrollo local, con un certificado autofirmado:

# Desactivar la verificación TLS (NUNCA en producción)
MAILER_DSN=smtp://user:pass@host:587?verify_peer=0

Pruebas y supervisión

Antes de lanzar

mail-tester.com: envíe un correo de prueba a la dirección que le dan y obtenga una puntuación sobre 10 con los problemas línea por línea. Aspire a 9+. Gratuito para 3 pruebas/día. Comprueba SPF, DKIM, DMARC, listas de bloqueo, calidad del HTML, encabezados y accesibilidad de los enlaces.

MXToolbox: diagnósticos de DNS. Registros MX, validez del SPF y recuento de consultas, resolución de DKIM, política DMARC, estado en listas de bloqueo. Guárdelo en marcadores.

Una vez en producción

Google Postmaster Tools: tasa de spam, reputación de la IP, reputación del dominio, éxito de la autenticación, todo desde la propia perspectiva de Gmail. Gratuito, requiere que verifique el dominio.

Lea los encabezados. En Gmail: abra el mensaje → tres puntos → "Mostrar original". Lo que quiere ver es:

SPF: PASS with IP 1.2.3.4
DKIM: PASS (signature verified)
DMARC: PASS

La cadencia que seguimos: un repaso semanal de ps_mail en busca de fallos y un vistazo a los informes DMARC. Una comprobación mensual con mail-tester y un barrido de listas de bloqueo. Volver a verificar el DNS tras cada cambio. Probar el correo tras cada actualización del núcleo de PrestaShop: los scripts de actualización han reescrito app/config/parameters.php en nuestras tiendas más de una vez.

Problemas habituales y qué mirar primero

"El correo de prueba funciona pero los clientes no reciben los correos de pedido"

  • Error de Smarty en la plantilla. Una variable rota en la plantilla del pedido mata el envío en silencio. Revise var/logs/.
  • Falta la plantilla del idioma. No hay mails/{lang_iso}/order_conf.html para el idioma del cliente y PrestaShop no envía nada.
  • Tiempo de espera de SMTP agotado. Un pedido de 30 líneas con imágenes puede tardar lo suficiente en renderizarse como para que los servidores SMTP lentos corten la conexión.
  • Rechazo de la dirección de origen. Algunos relés se niegan a enviar a menos que el From coincida con el usuario autenticado.

Limitación de tasa

¿Importa 200 pedidos o envía un boletín a mil clientes? Su servidor SMTP acepta el primer lote y rechaza el resto. Espacie los envíos, compruebe los topes del proveedor o pase a un servicio transaccional que ponga los mensajes en cola por usted.

Problemas de codificación (diacríticos en PL, CZ, DE, FR)

  • Línea de asunto distorsionada. Su instalación debe ser UTF-8 de principio a fin. Los asuntos se codifican según el RFC 2047.
  • Cuerpo distorsionado. Los archivos de plantilla de correo deben ser UTF-8 sin BOM. A Notepad en Windows le gusta guardar como ANSI: use VS Code.
  • Discrepancia en la base de datos. Las tablas deberían ser utf8mb4. Confírmelo con SHOW CREATE TABLE ps_product_lang;

Correo bloqueado tras una migración de servidor

  • El SPF sigue apuntando a la IP antigua
  • Discrepancia de clave DKIM porque el nuevo host generó un nuevo par de claves
  • La nueva IP tiene reputación cero: caliéntela gradualmente a lo largo de dos semanas
  • Puerto 587 bloqueado en el nuevo host
  • Propagación del DNS: déjele de 24 a 48 horas tras cambiar los registros

Los mensajes del formulario de contacto no llegan

Algunos módulos ponen el correo del cliente como dirección de origen en el formulario de contacto. Eso falla el SPF al instante: su servidor no está autorizado a enviar en nombre de customer@gmail.com. El From debería ser siempre el dominio de su tienda, con el cliente en Reply-To. Hemos arreglado esto en más módulos de formulario de contacto de los que querríamos contar.

Lista de verificación de entregabilidad

Paso 1: cimientos

  • ☐ Desactivar la función mail() de PHP y pasar a un SMTP real
  • ☐ Crear un buzón de envío dedicado (por ejemplo, orders@yourstore.com)
  • ☐ Envío de prueba a Gmail y Outlook: ambos deben llegar a la bandeja de entrada

Paso 2: autenticación del DNS

  • ☐ Publicar un registro SPF: verifíquelo en MXToolbox, por debajo de 10 consultas
  • ☐ Habilitar DKIM y publicar la clave pública
  • ☐ Añadir un registro DMARC en p=none con informes rua
  • ☐ Abrir un mensaje entregado y confirmar que SPF, DKIM y DMARC muestran todos PASS

Paso 3: calidad

  • ☐ Puntuar 9+ en mail-tester.com
  • ☐ La IP de envío no figura en ninguna lista de bloqueo
  • ☐ Existen plantillas para cada idioma, tanto en HTML como en texto plano

Paso 4: prueba del mundo real

  • ☐ Hacer un pedido de prueba: la confirmación llega a la bandeja de entrada en segundos
  • ☐ Recorrerlo por cada estado del pedido: llega cada correo de estado
  • ☐ Probar el restablecimiento de contraseña, la creación de cuenta y el formulario de contacto

Paso 5: supervisión

  • ☐ Registrarse en Google Postmaster Tools
  • ☐ Configurar el procesamiento de los informes DMARC
  • ☐ Pasar DMARC a p=quarantine tras 2-4 semanas y luego a p=reject
  • ☐ Comprobación mensual de entregabilidad en el calendario

Paso 6: avanzado

  • ☐ Pasar a un servicio transaccional en cuanto alcance los límites del alojamiento
  • ☐ Separar lo transaccional y lo de marketing en dominios distintos
  • ☐ Registro PTR configurado si está en VPS/dedicado
  • ☐ Gestión de rebotes conectada

Cada capa (SMTP, SPF, DKIM, DMARC, plantillas limpias, una IP de envío con buena reputación) se apila sobre las anteriores. Sáltese una y toda la estructura se debilita. Recorra la lista de verificación en orden, vuelva a probar tras cada cambio y sus confirmaciones de pedido llegarán a la bandeja de entrada donde corresponde. Para diagnósticos más amplios, consulte nuestra guía de resolución de problemas.

Lecturas relacionadas

Módulos relacionados

Preguntas relacionadas

Volver arriba