Sus correos seguían desapareciendo. Trasladamos el correo de la tienda a Google Workspace, y los detalles fueron decisivos

La queja llegó como suelen llegar estas quejas: sin muchos detalles. Algunos clientes no recibían nuestras respuestas. Con quienes usaban Gmail no había problema. De vez en cuando, algún mensaje rebotaba como no entregado. Y un proveedor, un mayorista al que la tienda compra productos, podía escribir a la tienda sin problemas, pero la tienda no conseguía responderle.

Se trata de una pequeña tienda especializada de cuyo mantenimiento nos encargamos. Un único buzón de empresa compartido con años de historial, varias personas que lo consultan desde sus ordenadores y teléfonos, y una tienda online que envía las confirmaciones de pedido desde esa misma dirección. Nadie allí quiere tener que pensar en el correo. Quieren que llegue.

Este es el relato de cómo lo solucionamos, sin datos que identifiquen al negocio, con los pasos que seguimos, los errores que evitamos y las comprobaciones posteriores que recomendamos para cualquier migración de este tipo. La versión corta: trasladamos el buzón a Google Workspace y dejamos la web en su alojamiento de siempre; solo cambiamos su configuración de correo. El valor está en la versión larga, porque la mayor parte del trabajo se concentró en detalles que necesitaron atención adicional: el cambio de DNS, decenas de miles de mensajes antiguos, la carpeta Enviados y las notificaciones de la propia tienda.

Todo pasaba las comprobaciones, pero el correo seguía desapareciendo

Lo primero que se comprueba es la autenticación, así que nosotros también empezamos por ahí. SPF pasaba. DKIM pasaba. DMARC pasaba, con la política p=none, que pide a los destinatarios que no tomen ninguna medida cuando falle DMARC. Sobre el papel, el dominio estaba bien configurado, y los síntomas llevaban meses repitiéndose a pesar de superar esas comprobaciones.

La respuesta estaba una capa más allá. Todo lo que tenía la tienda (el DNS del dominio, la web y el buzón) estaba en un mismo proveedor de alojamiento compartido. El correo saliente no partía de un servidor propio de la tienda. Pasaba por el relay de salida compartido del proveedor, el mismo pequeño grupo de servidores por el que envían muchos otros clientes. Y la dirección del relay que transportaba los mensajes de la tienda figuraba en una lista pública de bloqueo de spam.

El patrón de entrega encajaba con esa inclusión en la lista: los destinatarios que consultan estas listas rechazan o envían a spam el correo procedente de una dirección incluida, por bien firmado que esté, mientras que Gmail da más peso a sus propios datos de reputación. Nunca llegamos a ver el mensaje de rechazo del mayorista, pero su sistema se comportaba exactamente como un filtro que utiliza esa lista.

La autenticación nunca fue el problema. Lo era la reputación del relay compartido.

Si quieres hacer el mismo diagnóstico en tu dominio, estos comandos te permiten avanzar bastante. La dirección IP se obtiene de la línea Received: que el servidor receptor añadió a un mensaje que hayas enviado a una dirección tuya de Gmail (ábrelo y selecciona Mostrar original (Show original)).

# ¿Quién recibe tu correo y qué dicen SPF y DMARC?
dig +short MX example-shop.com
dig +short TXT example-shop.com | grep -i spf
dig +short TXT _dmarc.example-shop.com

# ¿Está en una lista de bloqueo el servidor que envió tu mensaje?
# Solo un ejemplo: invierte la IP real de envío, 203.0.113.25 pasa a ser 25.113.0.203
dig 25.113.0.203.bl.spamcop.net A +noall +comments +answer
# estado NOERROR con 127.0.0.2 = incluido; estado NXDOMAIN = no incluido en este momento;
# SERVFAIL, REFUSED o tiempo de espera agotado = sin respuesta, prueba la consulta web de la propia lista

Una advertencia práctica: algunas listas de bloqueo, entre ellas Spamhaus, rechazan las consultas que llegan a través de grandes resolutores DNS públicos y devuelven un código de error. Además, una consulta comprueba una lista en un momento concreto, no la capacidad de entrega de tu correo en su conjunto.

Por qué trasladamos el correo, y solo el correo

El correo y el alojamiento web son servicios independientes que suelen venderse juntos. Trasladar una web es un proyecto con riesgo de interrupciones, cachés que hay que volver a llenar y una docena de elementos que coordinar. Trasladar el correo supone un cambio de DNS y una importación. La web de la tienda funcionaba, así que la dejamos en su alojamiento y resolvimos el problema que realmente estaba causando perjuicios.

Valoramos cuatro opciones:

Recomendaríamos cualquiera de los dos grandes servicios. Elegimos Workspace por una razón sencilla: las personas que utilizan el buzón ya conocían Gmail, y cuanto menos tenga que aprender un equipo pequeño, antes se acostumbra al cambio.

También mantuvimos el buzón de empresa como un usuario independiente de Workspace, en lugar de integrarlo en la cuenta personal de alguien. Una dirección de empresa que vive dentro del Gmail personal de una persona es difícil de traspasar, de auditar y de recuperar cuando esa persona se marcha. Si varias personas necesitan acceder con sus propias credenciales en lugar de compartir unas, la delegación de Gmail permite trabajar en el buzón compartido desde cuentas personales. Hemos tratado la cuestión de los accesos en qué ocurre cuando un empleado se va y sus accesos se quedan.

Antes de tocar el DNS: la preparación

El cambio en sí lleva unos minutos. La preparación decide si esos minutos transcurren sin novedad o con sobresaltos.

• Guarda una copia de toda la zona DNS. Expórtala o anota cada registro para poder restaurar los registros anteriores exactamente como estaban. Ten en cuenta que volver atrás solo cambia el destino del correo nuevo: lo que se haya entregado a Google mientras tanto se queda allí.
• Haz una lista de todas las direcciones que reciben correo. Buzones, alias, reenvíos, grupos, reglas catch-all. Cuando el registro MX apunte a Google, todas deben existir también allí; de lo contrario, su correo rebotará. Esta tienda tenía un único buzón y nada más, así que la lista era corta.
• Haz una lista de todo lo que envía correo con tu dominio. Clientes de correo de ordenadores y teléfonos, la tienda online (confirmaciones de pedido, formulario de contacto, restablecimientos de contraseña), herramientas de facturación, cuentas en marketplaces. Todo debe seguir funcionando después del cambio.
• Reduce el TTL del registro MX a 300 segundos un día antes. El MX de la tienda tenía un TTL de cuatro horas, lo que permitía a otros servidores de correo recordar el destino anterior durante cuatro horas después del cambio.
• Añade el registro TXT de verificación de Google y termina de activar Gmail en la consola de administración (Admin console). El registro de verificación convive con tu registro SPF. Un dominio puede tener muchos registros TXT, pero solo uno de ellos puede ser un registro SPF.
• Activa la verificación en dos pasos para el administrador de Workspace y el usuario del buzón, y guarda los códigos de seguridad en un lugar seguro antes de que empiece a circular el correo.

El cambio, registro a registro

Estos son los cambios, con los nombres de la tienda sustituidos por valores de ejemplo.

En el registro SPF, conserva todos los mecanismos que tus remitentes activos sigan necesitando y añade junto a ellos el include de Google; un solo registro SPF por nombre y no más de diez consultas DNS en total al contar todos los includes.

Hay dos detalles que merecen un párrafo propio. Primero, la clave DKIM supera los 255 caracteres que admite una sola cadena de texto DNS. Aun así, debe ser un único registro TXT: algunos paneles DNS la dividen automáticamente en varias cadenas entre comillas dentro de ese registro; otros requieren que lo hagas tú. Compara el valor publicado con el de la consola de administración carácter por carácter y después pulsa «Start authentication» en «Apps > Google Workspace > Gmail > Authenticate email». En una cuenta de Workspace recién creada, Google puede tardar un día o más en permitirte generar la clave.

Segundo, no te fíes de tu propio resolutor para dar por hecho que el cambio ha funcionado. Consulta directamente cada servidor DNS autoritativo:

# Pregunta a cada servidor DNS del dominio qué MX devuelve en este momento
for ns in $(dig +short NS example-shop.com.); do
  printf '%s\n' "$ns"
  dig @"$ns" example-shop.com. MX +norecurse +noall +comments +answer
done
# Busca el indicador "aa" (respuesta autoritativa) y el nuevo MX en cada bloque

Cuando lo hicimos, un servidor DNS respondió con Google en cuestión de segundos. Los otros tres siguieron devolviendo el MX anterior durante unos veinte minutos, con el mismo número de serie de la zona. Nunca supimos por qué. Si solo hubiéramos consultado nuestro propio resolutor, habríamos dado el trabajo por terminado sin detectar esos veinte minutos en los que el correo seguía la ruta anterior.

Un servidor de nombres respondió con Google en segundos. Los otros tres necesitaron unos veinte minutos.

Cuenta también con un periodo de entregas rezagadas. Los servidores de correo que consultaron el MX anterior antes del cambio, o que tenían mensajes en cola pendientes de reintento, pueden seguir entregando al buzón antiguo durante un tiempo. Por eso, mantén ambos buzones operativos durante la transición, vigila el antiguo y repite la importación hasta que deje de llegar correo allí. En paneles de alojamiento como cPanel, comprueba también la configuración de enrutamiento del correo del dominio: si la cuenta de alojamiento sigue considerando que gestiona el correo del dominio, los mensajes que la web envía a tu propia dirección pueden entregarse localmente en el buzón antiguo.

Trasladar 40.000 mensajes sin perder ninguno

El buzón antiguo contenía 39.840 mensajes en 27 carpetas, unos 13 GB en total, acumulados durante años: facturas de proveedores, pedidos de marketplaces, avisos de transportistas y conversaciones con clientes. Perder parte de ese historial no era una opción, y tampoco lo era pasar una semana con carpetas a medio importar.

Importar es la parte fácil. La comprobación final es lo que permite afirmar que no se perdió nada.

Empezamos con la migración de datos integrada de Google, que se conecta al servidor antiguo por IMAP y lo copia todo. Funciona, pero en este buzón presentó tres problemas:

• Velocidad. Unos 2.400 mensajes por hora, lo que para este buzón suponía más de dieciséis horas. Por lo que pudimos observar, obtenía un mensaje por sesión IMAP, y la herramienta no ofrece ningún ajuste de velocidad.
• Omisiones. Varias carpetas mostraban un aviso de «crawl failure» con un error interno de sincronización, y la recomendación era repetir la migración más adelante.
• Fechas incorrectas. Había 925 mensajes de un remitente cuyo sistema de correo genera una cabecera Date mal formada (segundos sin cero inicial y sin zona horaria, como 2 Apr 2024 18:36:4), y otros dos no tenían cabecera Date. La migración les asignó la hora de importación, de modo que mensajes de hacía años aparecían al principio de la bandeja de entrada como si hubieran llegado esa mañana.

Así que terminamos el trabajo con un importador propio, basado en la API de importación de Gmail, que controlábamos de principio a fin:

• Solo lectura en el origen. Abrimos el buzón antiguo en modo de solo lectura y recuperamos cada mensaje sin activar el indicador de «visto». No cambió nada en el servidor antiguo, así que seguía siendo una alternativa válida a la que volver.
• Omitir lo que ya había llegado. Comprobamos el Message-ID de cada mensaje frente a los que ya estaban en Gmail, para que el importador no copiara lo que la migración de Google ya había trasladado.
• Las carpetas se convierten en etiquetas. Una carpeta antigua como INBOX.Invoices pasó a ser la etiqueta Invoices en Gmail, de modo que el equipo encontró todo donde esperaba.
• Posibilidad de reanudar. Un archivo de estado registraba el progreso, así que una interrupción suponía continuar desde ese punto, nunca empezar de nuevo.
• La fecha del propio mensaje. Los mensajes con una cabecera Date válida se situaban cronológicamente según esa fecha, no según el día de la importación.

Otro detalle que se nota desde el primer día: las marcas. Las estrellas no se conservaron en la importación, y un equipo que lleva años usándolas como lista de tareas lo nota enseguida. Localizamos las copias en Gmail de los 530 mensajes marcados en el buzón antiguo y volvimos a añadirles la estrella.

La carpeta Enviados necesitaba su propio plan

Después de la propia entrega del correo, esto era lo que más le importaba al propietario de la tienda. Al trasladarse a Gmail, surgieron tres problemas distintos con Enviados.

1. Gmail decidió qué contaba como enviado

En este buzón, todos los mensajes importados cuyo remitente era la propia dirección del buzón aparecieron en Enviados, y más tarde observamos lo mismo con las copias recibidas a través del relay. Tras la importación, eso incluía años de notificaciones automáticas de la tienda, porque las confirmaciones de pedido siempre se habían enviado desde la dirección de empresa. De pronto, Enviados contenía unos 1.950 mensajes que nadie había escrito, mezclados con las respuestas reales del equipo.

Identificamos los mensajes generados por la tienda por sus cabeceras de software de envío y sacamos los 1.959 de Enviados para colocarlos en las etiquetas que les correspondían, con el comando de movimiento de IMAP. En este buzón, mover un mensaje fuera de la carpeta Enviados eliminaba su etiqueta Enviados, justo lo que necesitábamos; primero lo probamos con un pequeño grupo. Enviados volvió a contener solo correo escrito por personas.

Gmail archivó las notificaciones de la tienda en Enviados. Moverlas devolvió al equipo una carpeta que podía usar.

2. El correo nuevo de la tienda volvería a llenarla

La forma más evidente de hacer que una tienda online envíe a través de Google es darle las credenciales del propio buzón en smtp.gmail.com. Funciona, y desde ese día todas las confirmaciones de pedido vuelven a aparecer en Enviados. En su lugar, la tienda envía a través del servicio de relay SMTP de Google (smtp-relay.gmail.com), que un administrador configura en la consola de administración, en «Apps > Google Workspace > Gmail > Routing»:

• «Allowed senders»: «Only addresses in my domains»
• «Require SMTP authentication»
• «Require TLS encryption»

«Comprehensive mail storage», un ajuste de administración situado en «Gmail > Compliance», estaba desactivado en esta cuenta, y los mensajes enviados por el relay no aparecían en Enviados del remitente. Activar ese ajuste guarda copias del correo enviado por el relay en los buzones de los usuarios; si tienes obligaciones de conservación, conviene revisar ese ajuste y Google Vault.

3. Pero el equipo sigue necesitando ver qué ha enviado la tienda

Tener Enviados limpio está muy bien hasta que un cliente llama y pregunta qué decía su confirmación. Por eso, con un pequeño fragmento de código a medida en la tienda, cada mensaje enviado correctamente genera ahora una copia a una dirección con sufijo «+» del buzón principal (office+shop@). La copia sale de otra dirección del dominio (shop@) que ni siquiera tiene buzón. Su nombre para mostrar incluye los destinatarios originales («Para: customer@...»), y su Reply-To apunta al cliente, de modo que al responder se utiliza el destinatario correcto.

Un filtro de Gmail con deliveredto:office+shop@example-shop.com omite la bandeja de entrada, marca la copia como leída y aplica una etiqueta llamada Enviados - tienda. ¿Por qué usar otra dirección como remitente? Por el punto 1: en este buzón, las copias procedentes de la propia dirección del buzón acababan en Enviados incluso cuando llegaban a través del relay. Las notificaciones que la tienda envía a su propio personal también salen de shop@, para que lleguen a la bandeja de entrada, donde alguien las leerá.

Hay una limitación que debes conocer: Gmail no permite colocar una etiqueta dentro de Enviados. Enviados - tienda aparece junto a él en la lista de etiquetas, algo que el propietario de la tienda aceptó cuando entendió el motivo.

Clientes de correo de escritorio

Unos pocos ajustes marcaron la diferencia entre «Thunderbird va lento desde el cambio» y un cliente que funciona bien:

• Sincroniza menos. Gmail muestra cada etiqueta como una carpeta IMAP, así que un mismo mensaje puede descargarse varias veces. En la configuración de Gmail, en Etiquetas (Labels), desmarca «Mostrar en IMAP» (Show in IMAP) para las carpetas que el equipo no utiliza en el ordenador, como Importantes. Ten cuidado con Todos: los mensajes archivados solo están ahí, así que, si el equipo archiva en Gmail, mantén Todos visible y limita las descargas del cliente para uso sin conexión.
• No dejes que el cliente guarde una segunda copia del correo enviado. En las cuentas que envían a través de Gmail, Gmail ya guarda todos los mensajes enviados. Comprueba que un mensaje de prueba aparece en Enviados y después desactiva la copia del propio cliente, que de lo contrario vuelve a subir cada mensaje.
• Retira la cuenta antigua del cliente. Elimínala después de la última pasada de importación o, al menos, cámbiale el nombre para que nadie responda desde el servidor antiguo por costumbre.

El correo de la tienda, en términos de PrestaShop

Sea cual sea la plataforma de tu tienda, los ajustes del relay significan lo mismo. En PrestaShop 1.7 y 8 se configuran en Parámetros avanzados > Dirección de correo electrónico (Advanced Parameters > E-mail), aunque los nombres pueden variar ligeramente entre versiones:

La dirección de correo de la tienda, configurada en Parámetros de la tienda (Shop Parameters), debe pertenecer a tu dominio o el relay la rechazará. Envía el correo de prueba desde esa misma página de configuración, ábrelo en Gmail, selecciona Mostrar original y busca tres resultados correctos: SPF, DKIM firmado con tu propio dominio y DMARC. La copia de archivo descrita antes no forma parte de estos ajustes: en esta tienda necesitó código a medida, y PrestaShop no lo hace de serie. Para una visión más amplia de la configuración de correo de PrestaShop, consulta nuestra guía sobre configuración del correo en PrestaShop: SMTP, Gmail y correo transaccional.

Después del cambio: cerrar las puertas antiguas

Una migración termina cuando ya nada depende del sistema antiguo y nadie puede utilizarlo por accidente. Esta es la lista de comprobaciones que seguimos después de un traslado como este:

• Restringe SPF cuando unos días tranquilos confirmen que ya nada envía a través del servidor antiguo: elimina el include del proveedor anterior.
• Conserva una exportación independiente del buzón antiguo antes de cancelar el servicio anterior y asígnale una contraseña larga y aleatoria para que nadie siga utilizándolo por costumbre.
• Revoca todas las credenciales temporales utilizadas para el traslado: contraseñas de aplicación para la importación, clientes de API y tokens del alojamiento.
• Asegúrate de que los informes DMARC llegan de verdad (el registro necesita una dirección para los informes), revísalos durante unas semanas y después cambia la política de p=none a quarantine.
• Valora usar Google Postmaster Tools para consultar las tasas de spam y la reputación en Gmail. Si envías poco correo, puede que apenas veas datos allí, así que sigue vigilando los rebotes y lo que te cuentan los destinatarios.
• Deja por escrito dónde está todo: el DNS, el administrador de Workspace, los ajustes del relay y los filtros. La próxima persona que tenga que tocarlo te lo agradecerá, aunque seas tú dentro de dos años.

El resultado

El correo de la tienda sale ahora por la infraestructura de Google, firmado con el dominio de la propia tienda. SPF, DKIM y DMARC pasan las comprobaciones, el mayorista vuelve a recibir las respuestas y cesaron las quejas por mensajes «no entregados». El único rebote de los primeros días tras el cambio fue un correo de confirmación de cuenta enviado a una dirección falsa que un bot había introducido en el formulario de registro, un rebote que sí interesa recibir.

La bandeja de entrada del equipo tiene el aspecto de siempre, con cada mensaje antiguo donde esperan encontrarlo. Enviados contiene lo que han escrito las personas. Las notificaciones de la tienda están en su propia etiqueta, a un clic cuando llama un cliente.

Y un último apunte, con sinceridad: el primer día, nuestros propios mensajes de prueba al buzón nuevo acabaron en Spam. Salían de un pequeño servidor nuestro con una autenticación impecable y muy poco historial de envío. No podemos ver los motivos de Gmail, pero ese historial escaso es la explicación más probable, y la lección es la misma que en toda esta historia: pasar la autenticación no equivale a ganarse la confianza.

Preguntas frecuentes

Fuentes

• Google: configurar registros MX para Google Workspace
• Google: enrutar mensajes salientes del relay SMTP por Google
• Google: límites de envío de Gmail en Google Workspace
• Google: configurar DKIM
• Google: almacenamiento total del correo
• API de Gmail: importar mensajes