Blog de Guanacos Tech

¿Cuándo se va a actualizar solo tu clúster de GKE? Lee el calendario de lanzamientos y mueve la fecha

Guanacos Tech — Wed, 30 Sep 2026 12:00:00 +0000

Pregúntale a un equipo pequeño cuándo se va a actualizar solo su clúster de Kubernetes y escucharás una de dos respuestas: "no se actualiza" o "ni idea". Las dos se equivocan igual. GKE publica las fechas. Están en una página que casi nadie abre, y son la diferencia entre un upgrade que cae un domingo tranquilo y uno que cae mientras tu cliente más importante está pagando.

Esto es lo que hacemos la primera semana en el clúster de un cliente: encontrar la fecha, decidir si es una buena fecha y moverla si no lo es. Este es el orden.

Dónde publica GKE el calendario y cómo leerlo

La página se llama GKE release schedule. Es una tabla con una fila por versión menor de Kubernetes y una columna por canal de lanzamiento: Rapid, Regular, Stable y Extended. Para cada versión y canal da la fecha en que la versión queda disponible para clústeres nuevos y la fecha en que GKE empieza a actualizar automáticamente los clústeres existentes. Consultado el 30 de septiembre de 2026.

Hay dos cosas de esa tabla que importan más que los números que tiene. La documentación dice que las fechas son predicciones de mejor esfuerzo, y que la disponibilidad y las fechas de actualización pueden retrasarse según la calificación y la estabilidad de cada versión, así que tómalas como una ventana y no como una cita. Y la separación entre canales es lo que en realidad estás eligiendo:

Rapid toma una versión menor entre una y dos semanas después de que llega a disponibilidad general en el Kubernetes de código abierto, y apunta a actualizar automáticamente uno o dos meses después.
Regular queda en medio, y es el punto de referencia del reloj de soporte que viene abajo: el soporte de una versión menor se cuenta desde el día en que queda disponible en Regular.
Stable recibe una versión tres o cuatro meses después de Regular, y apunta a actualizar automáticamente unos dos meses después. Prioriza estabilidad sobre funciones nuevas.
Extended coincide con Regular en disponibilidad y mantiene soportada la versión menor por más tiempo.

Hay un segundo canal de información que vale la pena guardar: las notas de lanzamiento por canal. Cada una o dos semanas GKE marca versiones de parche concretas como deprecadas dentro de un canal. Las notas de lanzamiento de Google Cloud del 23 de septiembre de 2026 traen la redacción habitual para varias de ellas: una versión deprecada se retira en 90 días, o al final del soporte si eso ocurre antes. Es decir que incluso dentro de un canal, quedarse en una versión de parche exacta es un estado temporal con un reloj de 90 días encima.

El reloj que decide todo: soporte estándar y después extendido

La página de versionado y soporte de GKE plantea el soporte por versión menor, contado desde el día en que la versión queda disponible en el canal Regular. Hay alrededor de 14 meses de soporte estándar, durante los cuales la versión recibe funciones nuevas, correcciones de seguridad y correcciones de errores. Después la versión entra en soporte extendido, que agrega unos 10 meses más de parches de seguridad y está disponible para clústeres inscritos en el canal Extended. Hasta unos 24 meses en total. Consultado el 30 de septiembre de 2026.

La frase que les leemos en voz alta a los clientes es la del final de ese ciclo: cuando termina el soporte extendido, GKE actualiza los clústeres que siguen en la versión menor ya sin soporte, sin importar si hay problemas que bloqueen el cambio. Lo opcional no es el upgrade. Lo opcional es cuándo.

En qué versión están tus clústeres hoy

Antes de tocar cualquier ajuste, levanta el inventario. Un comando por proyecto:

gcloud container clusters list \
  --format="table(name, location, currentMasterVersion, releaseChannel.channel)"

Si la columna del canal sale vacía, el clúster está en No channel, la configuración que la documentación de canales de lanzamiento de Google marca como deprecada y que se retira el 14 de junio de 2027, fecha después de la cual GKE inscribe en el canal Stable los clústeres que queden (consultado el 30 de septiembre de 2026). Escribimos sobre esa fecha límite y el trabajo que obliga a hacer en nuestro artículo sobre el plazo de junio de 2027. Para hoy lo importante es más acotado: un clúster fuera de un canal solo puede usar la versión más tosca de los controles que siguen.

Después lee la política de mantenimiento de cada clúster:

gcloud container clusters describe CLUSTER_NAME \
  --location=LOCATION \
  --format="value(maintenancePolicy)"

Que no devuelva nada es lo más común, y eso ya es el hallazgo. Sin ventana de mantenimiento, GKE puede iniciar una actualización automática a la hora que le convenga.

Ventanas y exclusiones de mantenimiento: los dos ajustes que deciden cuándo

Una ventana de mantenimiento es un bloque de tiempo recurrente que GKE tiene permitido usar. Fuera de esa ventana, GKE no inicia una actualización automática. Ese es el ajuste que saca el upgrade del martes al mediodía para siempre, y se configura en minutos con gcloud container clusters update o desde la configuración del clúster en la consola.

Una exclusión de mantenimiento es la otra mitad: un rango de fechas puntual en el que no quieres que pase nada, por ejemplo la semana de un lanzamiento o el cierre de año. Las exclusiones tienen alcances, y el alcance que puedes usar depende de si el clúster está inscrito en un canal:

No upgrades bloquea todo, plano de control y nodos. Para un clúster fuera de un canal es el único alcance disponible, y tiene un tope de 30 días. Para un clúster en un canal la documentación permite hasta 90 días y recomienda mantenerlo bajo 30.
No minor upgrades deja pasar parches y actualizaciones de nodos, y retiene la versión menor. Solo con canal.
No minor or node upgrades retiene las dos cosas y deja pasar parches. Solo con canal.

Los dos alcances más finos se pueden configurar para correr hasta el fin de soporte de la versión menor del clúster, y se pueden dejar siguiendo esa fecha en lugar de una que tú escribas, así nadie tiene que acordarse de renovarlas. Un clúster admite hasta 20 exclusiones. Revisa los límites vigentes en la página de exclusiones de mantenimiento antes de planear un congelamiento largo.

Una advertencia que le damos a todo cliente: bloquear las actualizaciones menores y de nodos no elimina el trabajo, te lo pasa a ti. La redacción de Google dice que si usas ese alcance tienes que hacer esas actualizaciones por tu cuenta, o GKE va a actualizar el clúster al final del soporte de la versión menor. Un congelamiento sin plan de upgrade detrás es una caída aplazada con fecha.

gcloud container clusters update CLUSTER_NAME \
  --location=LOCATION \
  --add-maintenance-exclusion-name=cierre-de-ano \
  --add-maintenance-exclusion-start=2026-12-15T00:00:00 \
  --add-maintenance-exclusion-end=2027-01-05T23:59:59 \
  --add-maintenance-exclusion-scope=no_upgrades

Cambiar de canal sin un upgrade sorpresa

Cambiar el canal es una sola bandera:

gcloud container clusters update CLUSTER_NAME \
  --location=LOCATION \
  --release-channel=regular

La bandera es fácil. La dirección es donde los equipos se golpean. Moverse hacia un canal más rápido puede dejar al clúster en la fila para una versión que nadie probó, porque el objetivo de actualización automática del canal de destino ya puede estar adelante de donde está el clúster hoy. Moverse hacia un canal más lento es la dirección más segura, y no devuelve el clúster hacia atrás, porque GKE no baja de versión un clúster para que coincida con el canal. Así que primero lee la tabla del canal de destino y busca dónde cae tu versión menor actual. Si el objetivo de ese canal está dos versiones menores adelante, lo que tienes es una migración y no un cambio de configuración.

Nuestro orden en los proyectos de clientes siempre es el mismo: primero la ventana de mantenimiento, después el cambio de canal. Hecho así, el primer upgrade después del cambio cae dentro de una ventana que alguien eligió.

Qué dejamos configurado primero en el clúster de un cliente

Inventario de todos los clústeres de todos los proyectos, con versión y canal, en una tabla legible para quien no es ingeniero.
La fecha de fin de soporte estándar de cada clúster, tomada de la página de versionado, para que "estamos bien" se convierta en una fecha.
Una ventana de mantenimiento en las horas realmente tranquilas del negocio, en la zona horaria del negocio y no en la de la región del clúster.
El canal elegido por carga de trabajo y no por empresa: Rapid para un clúster de staging, donde un upgrade roto es información útil, Regular o Stable para todo lo que toca un cliente.
Calificar la siguiente versión menor en un clúster de preproducción antes de la fecha de actualización automática de producción, no después.
Agregar PodDisruptionBudgets y suficiente capacidad de surge para que un nodo se vacíe limpio, porque una buena ventana solo sirve si la carga sobrevive a que la muevan.
Mandar las notificaciones de actualización a un lugar donde una persona las lea, y poner las siguientes dos fechas de actualización automática en el calendario de operaciones.

Notas de costo y riesgo

Las ventanas, las exclusiones y el cambio de canal no cuestan nada. Tres cosas alrededor sí. El soporte extendido se cobra distinto del soporte estándar, así que si estás considerando el canal Extended para retener una versión más tiempo, revisa la página de precios de GKE vigente el día que decidas: esa cifra la verificamos por cliente en lugar de repetirla desde un artículo. Los upgrades con surge agregan nodos mientras dura la actualización, una cuenta chica y corta. Y calificar una versión en preproducción cuesta unos días de un clúster, la línea más barata frente a un upgrade de producción que falla.

El riesgo que de verdad muerde es más silencioso que una caída: un clúster que llega a semanas del fin de soporte mientras todos asumen que son problema de alguien más. Ninguna notificación vuelve eso seguro. Una fecha en un calendario compartido sí.

Cómo ayuda Guanacos Tech

Lo hacemos como un trabajo cerrado: el inventario de clústeres, las fechas de soporte, las ventanas de mantenimiento, la decisión de canal por carga de trabajo, una corrida de calificación en preproducción y un runbook de una página para que el siguiente upgrade sea una entrada de calendario y no un incidente. Somos una consultoría independiente y nuestros ingenieros tienen certificaciones de Google, así que recibes el razonamiento detrás de cada ajuste junto con el ajuste.

Si tienes un clúster al que nadie entra desde hace un año, ese es el punto de partida normal y no es para avergonzarse. Mira lo que hacemos en consultoría de Google Cloud. Una llamada de 30 minutos alcanza para decirte a qué fecha va tu clúster y si hay que moverla.

Fuentes

Google Workspace o el correo que vino con tu hosting: la comparación honesta para una pyme

Guanacos Tech — Wed, 30 Sep 2026 12:00:00 +0000

La llamada casi siempre empieza igual. El cliente manda una factura, el comprador dice que nunca llegó, y el mensaje aparece en la carpeta de correo no deseado con tres días de retraso. El buzón venía gratis con el plan de hosting, lo configuró hace años quien hizo el sitio web, y nadie lo ha revisado desde entonces.

Esa es la decisión real de la mayoría de las pymes. No Google Workspace contra Microsoft 365, que es una elección deliberada, sino Google Workspace contra los buzones que vinieron incluidos con el hosting y no cuestan nada extra. Gratis es un argumento fuerte. Esto es lo que revisamos antes de recomendarle a un cliente que se cambie, y cuándo le decimos que no vale la pena.

Qué incluye de verdad cada opción

El correo del hosting significa que tus buzones viven en el mismo servidor que tu sitio web, administrados desde cPanel o el panel propio de tu proveedor. Tienes un buzón por dirección, webmail, acceso IMAP y POP, y un servidor de salida compartido. El almacenamiento sale de la cuota de disco del plan, y administrar es llenar un formulario en un panel.

Google Workspace es una plataforma de correo aparte. Tus registros MX apuntan a Google y no a tu hosting, el correo nunca toca el servidor web, y cada persona tiene un buzón de Gmail más Drive, Calendar, Meet y Docs. La administración pasa por la consola de administrador: usuarios, grupos, alias, políticas de seguridad, registros de auditoría.

Las listas de funciones son fáciles de comparar y casi nunca son lo que decide. Cuatro cosas sí deciden: si tu correo llega, qué pasa con la información cuando alguien se va, cuánto te costaría un robo de cuenta, y la factura a doce meses. En ese orden.

Reputación compartida: el problema que no ves hasta que rebota

Este es el que nos trae clientes, y es estructural, no un error de configuración que puedas ordenar.

En hosting compartido, el servidor de salida es el mismo para todos los sitios de esa máquina, y los proveedores que reciben juzgan la IP que envía. Si otra cuenta del mismo servidor compra una lista o la hackean y empieza a enviar, la reputación de esa IP se cae y tus facturas van a spam junto con su spam. Tú no hiciste nada y no tienes ninguna palanca que mover.

Los proveedores de hosting lo saben, y por eso publican límites de envío. Hostinger, por poner uno cuyos límites son públicos, documenta topes por día, por hora y por mensaje en el correo de cPanel, y aparte advierte que el correo enviado con la función mail() de PHP está limitado a 100 mensajes al día y 10 por minuto, y recomienda usar SMTP autenticado (consultado el 30 de septiembre de 2026). Esos topes protegen la IP compartida. También son el techo de tus confirmaciones de pedido.

La otra mitad del problema es la autenticación. Las guías para remitentes de Gmail exigen que todo el que envía publique SPF o DKIM para su dominio, que la IP que envía tenga DNS directo e inverso válidos, y que se use TLS. Para el correo que va a cuentas personales de Gmail, el dominio del encabezado From: tiene que alinear con el dominio de SPF o con el de DKIM. Quien envía en volumen además tiene que mantener la tasa de spam de Postmaster Tools por debajo de 0.30%, y los mensajes de marketing necesitan cancelación de suscripción en un clic.

Nada de eso es imposible con el correo del hosting: la firma DKIM suele estar en el panel, y SPF es un registro TXT que puedes escribir tú. Pero estás autenticando un remitente cuya reputación compartes con desconocidos, y una empresa que crece acaba topándose con un límite que no puede subir. Con Workspace, SPF es un solo include y Google firma con DKIM en cuanto lo activas:

; SPF, si Google Workspace es tu único remitente
example.com.   TXT   "v=spf1 include:_spf.google.com ~all"

; MX, un solo registro
example.com.   MX    1 smtp.google.com.

Lee la documentación de SPF de Google antes de editar nada: un registro admite como máximo diez consultas include:, y los registros de hosting ya suelen venir cargados.

De cualquier forma, revisa qué publica tu dominio hoy. Un SPF ausente, un DKIM sin firmar o un include viejo del hosting vale la pena arreglarlo en la plataforma en la que termines.

Almacenamiento, respaldo y el día que alguien se va

Los buzones del hosting se comen el disco del plan. Eso funciona hasta que deja de funcionar: un buzón de ventas con diez años de adjuntos llena la cuota, el sitio empieza a dar errores, y la solución es borrar correo viejo o pagar un plan más grande. Los respaldos son los que tome tu proveedor de toda la cuenta, en su calendario.

El almacenamiento de Workspace es agrupado para toda la organización, no fijo por buzón. Business Starter incluye 30 GB por usuario, Business Standard 2 TB, y Business Plus y Enterprise Plus 5 TB, todo salido de un total compartido. Lo útil es justamente que sea agrupado: una persona con un buzón enorme no deja a nadie más sin espacio.

La salida de la empresa es donde la diferencia incomoda. En el correo del hosting, borrar un buzón borra el correo, y no hay entrega de relevo integrada. En Workspace, borrar un usuario es un proceso guiado: un superadministrador puede transferir los archivos de Drive y Docs de quien se va y los datos de su calendario principal a otra cuenta, y la cuenta queda suspendida hasta que la transferencia termina. Google también documenta que la dirección borrada se retira de la organización veinte días después, que es tu ventana para restaurar una cuenta que borraste con prisa.

Cuando una sola persona lleva la relación con los clientes, esto no es un detalle administrativo. Es si te quedas con el historial el día que renuncia.

Seguridad: verificación en dos pasos, dispositivos, recuperación

Los buzones del hosting suelen estar protegidos por una contraseña en un panel. Algunos proveedores ofrecen un segundo factor sobre la cuenta de hosting, muchos menos por buzón, y casi ninguno te da forma de exigirlo. Si un vendedor reutiliza una contraseña que después aparece en una filtración, te enteras cuando tus clientes reciben facturas con los datos bancarios de otra persona.

En Workspace, la verificación en dos pasos es una política que impones, no un ajuste que esperas que la gente encuentre. La consola de administrador te permite activarla para toda la organización o para una unidad organizativa, y puedes exigir llaves de seguridad o claves de acceso en concreto. La recomendación de Google es exigir llaves de seguridad en todas las unidades organizativas, con la advertencia de que en el modo de solo llave de seguridad los usuarios no pueden generar sus propios códigos de respaldo, así que un administrador tiene que entregarlos. Ese detalle importa: exigir sin un plan para los bloqueos crea otra emergencia.

También tienes lo que solo existe cuando el correo es una plataforma administrada: registros de auditoría de quién inició sesión y desde dónde, la posibilidad de cerrar la sesión de un dispositivo robado, y restablecer contraseñas sin depender de un ticket de soporte.

El costo real a doce meses

El correo del hosting parece gratis porque viene incluido. No es gratis, es sin precio: lo estás pagando dentro del plan de hosting, y la cuota de disco es el presupuesto.

Workspace es una suscripción por usuario, y el número que importa es el total a doce meses de las licencias que realmente necesitas, no el precio mensual del titular. Dos cosas lo mueven. Primero, el plan de pago: la documentación de facturación de Google es explícita en que el plan Anual o de Plazo Fijo tiene el precio por usuario más bajo pero te compromete a una cantidad mínima de licencias que no puedes reducir hasta la renovación, mientras que el plan Flexible se cobra mes a mes por los usuarios que tengas, a prorrata, y te deja quitar cuentas cuando quieras. Con personal de temporada, el Flexible casi siempre gana aunque el precio unitario sea mayor. Segundo, la cantidad de licencias, que es donde se equivocan casi todas las cotizaciones.

Nosotros leemos la cifra vigente en la página de precios de Google al momento de cotizar, en vez de repetir una de memoria, porque los precios de lista y las promociones cambian. Lo que sí te podemos decir es cómo contar licencias:

Los alias son gratis. Google documenta hasta 30 alias de correo por usuario sin costo extra, así que quien necesita ventas@ y ana@ necesita una licencia y un alias, no dos licencias.
Las direcciones compartidas son grupos, no usuarios. Un alias es de una sola persona, así que info@, soporte@ y facturacion@ deben ser grupos de Google que entregan a varias personas sin costo de licencia.
No todos necesitan la misma edición. Si dos personas necesitan más almacenamiento y grabación de reuniones y el resto solo correo, no tiene que estar toda la empresa en el mismo plan.
Cuenta lo que queda fuera de la suscripción. La migración, un día de capacitación y el trabajo de DNS son reales y de una sola vez. Cotízalos aparte.

Nuestras propias tarifas están en cómo trabajamos. Una empresa de doce personas suele necesitar ocho licencias, y contar bien cambia esta comparación más que la elección del plan.

Cuándo el correo del hosting sí alcanza

Convencemos a clientes de no migrar más seguido de lo que imaginas. El correo del hosting aguanta cuando se cumple todo esto:

Dos o tres buzones, poco volumen, sobre todo respuestas y no campañas de salida.
Nada automatizado envía en nombre del dominio: ni confirmaciones de pedido de la tienda, ni CRM, ni sistema de facturación, ni boletín.
Los buzones no son el registro de nada que alguien vaya a necesitar leer después.
Tu proveedor te da DKIM en el panel y ya publicaste SPF y DMARC bien.
Nadie depende de calendarios ni archivos compartidos, que es la mitad de Workspace que esta comparación ignora.

Un estudio de dos personas que factura a mano está bien. Una firma de diez cuyo sistema contable le escribe a los clientes, no. Ahí suele estar la línea.

Cómo migramos cuando un cliente decide cambiarse

El orden importa más que la herramienta. Hacerlo en desorden es lo que produce las historias de correo perdido.

Primero el inventario. Cada buzón, reenvío, alias y autorespuesta, más todo lo que envía usando el dominio: el formulario de contacto, el sistema de facturación, el CRM, la impresora.
Crea los usuarios como los vas a pagar. Las personas como usuarios con licencia, las direcciones compartidas como grupos, las secundarias como alias.
Copia el correo con el sistema viejo todavía en vivo. La migración va por IMAP mientras el correo del hosting sigue entregando, así nada queda en el aire durante el corte.
Baja el TTL de los MX dos días antes, no la mañana del corte.
Cambia los registros MX y autentica el mismo día. SPF actualizado para el nuevo remitente, DKIM activado y publicado, DMARC en p=none con reportes que vayan a algún lugar que leas.
Reapunta todo lo que siga enviando por el servidor viejo. Este es el paso que se salta la gente, y por eso las confirmaciones de pedido fallan una semana después de una migración por lo demás limpia.
Vigila los reportes DMARC dos semanas antes de endurecer la política.

El procedimiento completo, con la copia por IMAP y la hora del corte, está en nuestra guía para migrar el correo de cPanel a Google Workspace.

Cómo ayuda Guanacos Tech

Hacemos esta comparación como auditoría o como primer paso de una migración, y toma cerca de una hora: qué publica tu dominio, desde dónde sale el correo en realidad, cuántas licencias necesitarías de verdad, y si los buzones guardan algo que no puedas perder. A veces la respuesta es que tu correo del hosting está bien y lo que hay que arreglar es el registro SPF. Te lo decimos.

Nuestros consultores de Google Workspace recorren tu dominio contigo en una llamada de 30 minutos y te dicen qué cambiaríamos, en qué orden, antes de que alguien toque el DNS.

Fuentes

Cambiar los registros MX a Google Workspace sin perder ni un correo

Guanacos Tech — Tue, 29 Sep 2026 12:00:00 +0000

El cambio de MX es el momento en que los clientes se quedan callados en la llamada. Casi todo lo demás en una migración se puede deshacer en una tarde. Esto se siente como desconectar el teléfono de la empresa, y la pregunta siempre es la misma: ¿qué pasa con los correos que lleguen mientras se hace el cambio?

La respuesta honesta es que no tiene que perderse nada, y cuando algo se pierde casi nunca es culpa del registro. Es culpa de una cuenta que todavía no existía, de un buzón viejo que se apagó demasiado pronto, o de una autenticación de envío que nadie actualizó. Este es el orden que seguimos con un cliente, y lo que revisamos en cada paso.

Qué controla de verdad el registro MX

Un registro MX responde una sola pregunta para todos los servidores de correo del mundo: cuando alguien escribe a tu dominio, ¿qué servidor debe recibir ese mensaje? Eso es todo. No mueve el correo que ya está en tus buzones viejos, no decide quién puede enviar en nombre de tu dominio y no tiene nada que ver con tu sitio web.

Esa diferencia importa porque las dos mitades del correo se rompen por motivos distintos. Lo que entra sigue el MX. Lo que sale se juzga con SPF, DKIM y DMARC, que viven en registros DNS completamente aparte. Hemos visto cortes perfectos del lado de la recepción mientras todas las facturas que la empresa envió esa semana caían en spam, porque el SPF seguía listando solo al hosting anterior.

Y algo que conviene decir claro: el DNS no se cambia, se vence. Cada servidor que consultó tu dominio hace poco se queda con la respuesta anterior durante el tiempo que permita el TTL del registro, así que por un rato el correo llega a dos lugares. Planifica el traslape en vez de intentar evitarlo.

Baja el TTL primero, días antes de tocar algo

El TTL, o tiempo de vida, es la cantidad de segundos que otros servidores pueden seguir usando una copia en caché de tu registro antes de volver a consultarlo. La guía de DNS de Google lo dice sin rodeos: un registro con TTL de 86400 segundos significa que los cambios tardan hasta 24 horas en aplicarse, y recomienda un valor de 3600 para que los servidores consulten cada hora.

Hay un detalle que a mucha gente le cuesta un día entero. Un TTL más corto empieza a valer solo después de que venza el periodo anterior. Si tu MX está en 86400 y lo bajas a 3600 una hora antes del corte, el resto de internet todavía tiene derecho a la respuesta vieja por un día más. Por eso bajar el TTL es un paso propio, hecho con al menos un periodo completo de anticipación. Para un registro de 24 horas, lo bajamos dos días antes.

Antes de planificar la ventana, mira qué tienes:

dig +noall +answer MX ejemplo.com
dig +nocmd +noall +answer TXT ejemplo.com | grep spf1

El número de la segunda columna en la respuesta MX es el TTL que queda, en segundos. Ese número, y no el calendario, define con cuánta antelación empiezas.

Los valores que Google publica hoy

La página de configuración de Google ahora muestra un solo registro MX que apunta a smtp.google.com, y los registradores suelen pedirlo con prioridad 1. Las cuentas que empezaron antes de 2023 tienen el conjunto anterior de valores que comienzan con aspmx; Google indica que esos valores antiguos siguen siendo compatibles y que no hace falta cambiarlos si tu correo funciona. En una migración no reescribimos un registro antiguo que ya funciona. Un cambio riesgoso a la vez es suficiente. Consultado en la página de ayuda de Google Workspace sobre configuración de MX el 29 de septiembre de 2026.

; así se ve una configuración actual de un solo registro
ejemplo.com.    3600    IN    MX    1 smtp.google.com.

Dos detalles causan la mayoría de los hilos de soporte. Los formatos de cada registrador son distintos: unos exigen el punto final, otros quieren la prioridad y el host en un mismo campo como 1 smtp.google.com, y otros agregan tu dominio al valor de forma automática, así que terminas con smtp.google.com.ejemplo.com. Y los MX viejos tienen que irse. Las instrucciones de Google dicen que elimines cualquier otro registro MX, porque el correo puede no funcionar bien si quedan registros incorrectos. Un registro olvidado con prioridad 10 apuntando al hosting anterior es la forma más común de terminar con la mitad del correo en un buzón que nadie lee.

Crea las cuentas antes de tocar el DNS

Este es el paso que de verdad pierde mensajes, y no es un paso de DNS. La guía de Google para evitar problemas al cambiar los MX pide crear las cuentas de usuario en la consola de administración primero, junto con los grupos y los alias que use tu dominio.

Digamos que un despacho contable de 12 personas tiene diez buzones, dos direcciones compartidas para clientes, una dirección desde la que envía el sistema de facturación y un alias impreso en una tarjeta antigua. Si facturacion@ existe en el servidor viejo pero no en Workspace, el correo a esa dirección empieza a rebotar en el minuto en que cambia el registro, y un rebote no se recupera. Armamos el inventario con la lista de cuentas del servidor anterior y con un mes de logs, no de memoria, porque las direcciones que la gente olvida son justo las que usan las máquinas.

Entrega dual y entrega dividida: las dos redes de seguridad

No tienes que elegir entre el sistema viejo y el nuevo en una sola noche. Google admite dos arreglos para el traslape, los dos configurados en la consola de administración en Aplicaciones, luego Google Workspace, luego Gmail, luego Enrutamiento.

La entrega dual deja una copia de cada mensaje entrante en los dos sistemas. Cualquiera de los dos puede ser el principal: Google recomienda Gmail como principal, y señala que puedes mantener el servidor anterior como principal durante un piloto o una migración, y pasar a Gmail solo cuando termine el piloto. Lo usamos cuando un equipo quiere una semana leyendo correo en los dos lados antes de comprometerse.

La entrega dividida enruta los mensajes entrantes a dos sistemas distintos según los destinatarios que nombres, lo que le sirve a una empresa que se mueve por departamentos. La documentación de Google aclara que los cambios de enrutamiento pueden tardar hasta 24 horas, aunque normalmente aplican más rápido, así que cuéntalo en el plan en vez de probar cinco minutos después de guardar.

Para una pyme que mueve a todos de una vez, ninguna de las dos es indispensable. Para un cambio por fases, o para un buzón compartido del que depende el negocio, el traslape es un seguro barato.

La hora del corte, en orden

El consejo de Google es programar el cambio cuando tu volumen de correo sea bajo, una noche o un fin de semana. Nosotros agregamos una regla: elige una hora en la que la gente que puede responder preguntas todavía esté despierta.

Confirma que todas las direcciones del inventario existen en Workspace, incluidos grupos y alias.
Confirma que el lado del envío está listo: el SPF autoriza a Google, la clave DKIM está publicada y activada, y el registro DMARC existe.
Confirma que los buzones viejos siguen aceptando correo y que lo harán por lo menos una semana más.
Publica el registro MX de Google y borra todos los demás registros MX del dominio.
Vuelve a leer el registro desde fuera de tu red con dig, no desde la pantalla de confirmación del registrador.
Envía una prueba desde una dirección externa y responde desde el buzón nuevo hacia algo externo.
Vigila los dos sistemas el resto de la noche. El viejo va a seguir recibiendo un rato, y eso es lo esperado, no una falla.

El correo que todavía llega al hosting anterior

Google es explícito: los registros MX nuevos pueden tardar hasta 72 horas en ser reconocidos, y hasta que se actualicen en todo el mundo vas a seguir recibiendo tráfico en tu servidor anterior. Tómalo como una semana de prudencia y no como una cuenta regresiva de tres días, porque un dominio que resuelve bien en todas partes el día dos suele tener un remitente terco el día cinco.

Dos cosas evitan que ese correo se pierda. La primera, deja los buzones viejos aceptando y, si el hosting lo permite, reenviando a las direcciones nuevas. Nadie debe cancelar el plan de hosting anterior el día del corte, y lo dejamos por escrito antes de arrancar el proyecto. La segunda, trae el historial como se debe. El servicio de migración de datos y la herramienta de importación de Google jalan el correo por IMAP desde la consola de administración, en Datos, luego Importación y exportación de datos, con un archivo que mapea direcciones de origen y destino; la documentación indica un límite de 100 usuarios IMAP por importación y que hay que entrar como superadministrador. La importación va después del corte, y luego una segunda pasada para lo que haya caído en el servidor anterior durante el traslape.

Autentica de nuevo y prueba con un correo real

La recepción ya es Google. El envío también tiene que decirlo, y aquí es donde un cambio de MX impecable igual produce una semana de correos en spam.

Si Google Workspace es lo único que envía por tu dominio, Google documenta el registro como v=spf1 include:_spf.google.com ~all, donde ~all pide a los receptores tratar como sospechoso a cualquier remitente no listado. La mayoría de las pymes no es tan simple: la tienda, el CRM, el sistema de facturación y la mesa de ayuda también envían, y cada uno que agregas gasta parte del presupuesto de 10 consultas que permite SPF.

; Google más un remitente externo, como ejemplo
v=spf1 include:_spf.google.com include:sendgrid.net ~all

El DKIM hay que generarlo y activarlo en la consola de administración, no dejarlo al comportamiento por defecto. Google recomienda el prefijo de selector google y una clave de 2048 bits, dice que bajes a 1024 solo si tu proveedor de DNS no acepta el valor largo, y señala que la autenticación puede tardar hasta 48 horas en empezar a funcionar. La consola puede seguir mostrando un aviso de que actualices el DNS hasta 48 horas después de que la clave ya esté bien, lo cual conviene saber antes de que alguien empiece a cambiar cosas que estaban correctas.

Después, revísalo del lado del receptor y no del tuyo. Los requisitos para remitentes de Gmail establecen que todos los remitentes deben configurar SPF o DKIM, y que quienes envían 5,000 mensajes o más al día a Gmail deben tener SPF, DKIM y DMARC. Postmaster Tools tiene una vista de autenticación con el porcentaje de tu correo que pasa cada verificación, que es el único número que zanja una discusión sobre si la migración afectó la entregabilidad.

Cómo ayuda Guanacos Tech

Hacemos los cortes de MX como una hora agendada con un orden de operaciones por escrito, porque las fallas aquí vienen de la secuencia y no de la dificultad: una dirección que no existía, un registro borrado antes de tiempo, un sistema de envío que nadie inventarió. Nuestra página de consultores de migración a Google Workspace explica el alcance con el que trabajamos, incluida la semana de traslape y las verificaciones de autenticación posteriores. Lleva tu registro MX actual y la lista de todo lo que envía correo como tu dominio a una llamada de 30 minutos, y saldrás con la hora del corte, los riesgos propios de tu caso y lo que debes mantener encendido hasta que el último remitente se ponga al día.

Fuentes

Tu correo cae en la pestaña Promociones de Gmail: qué influye de verdad y qué es folclore

Guanacos Tech — Tue, 29 Sep 2026 12:00:00 +0000

Cada cierto tiempo un cliente nos reenvía la misma captura: su propio boletín, sentado en la pestaña Promociones de su propio Gmail. Debajo siempre está la misma pregunta: "¿se rompió algo?"

Casi nunca se rompió nada. Promociones es parte de la bandeja de entrada, no es la carpeta de spam. La mayoría de los consejos que circulan para escaparse de ahí son folclore que se repitió tanto que terminó sonando a documentación. Esto es lo que las fuentes primarias sí respaldan, lo que no, y el orden en que lo revisamos en una cuenta de cliente.

Promociones no es spam, y la diferencia decide qué vas a arreglar

Gmail clasifica el correo entrante en categorías: Principal, Promociones, Redes sociales, Notificaciones y Foros. La página de ayuda de Google sobre categorías describe esa clasificación como automática, y le indica al usuario que mueva el mensaje cuando cae en el lugar equivocado para que Gmail aprenda su preferencia. Todas esas categorías son la bandeja de entrada. El mensaje se entregó. Se puede buscar, en la mayoría de configuraciones genera notificación, y cuenta como entrega en bandeja bajo cualquier definición razonable.

La carpeta de spam es un resultado distinto, producido por señales distintas: fallos de autenticación, tasa de quejas, reputación del dominio y de la IP. La distinción no es académica. Decide qué semana de trabajo sigue. Hemos visto a una empresa pequeña reescribir todos sus asuntos durante un mes cuando su problema real era un remitente externo sin firmar, y hemos visto a otra pagar un servicio de "calentamiento" para correo que se estaba entregando perfectamente bien en una pestaña que al dueño no le gustaba.

Así que primero define qué problema tienes. Si el correo llega y lo encuentras bajo Promociones, tienes una pregunta de clasificación y este es el texto correcto. Si nunca llega, si cae en Spam o si te están rebotando mensajes, empieza por la guía del error 550 5.7.1 y la reputación.

Qué dice Google que decide la categoría

Google no publica el clasificador, y quien te diga que lo tiene descifrado te está vendiendo algo. Lo que sí afirma la documentación de ayuda es más acotado y más útil: la clasificación es automática, y cuando una persona mueve un mensaje a otra categoría, Gmail usa esa decisión para clasificar el correo de ese remitente para esa persona en adelante. La misma página explica cómo apagar las categorías por completo o crear un filtro que asigne una.

Léelo con calma y llegas a lo que casi todo el consejo sobre Promociones prefiere no decir. La categoría es una propiedad de la relación entre un remitente y un destinatario, no una propiedad de tu mensaje. Dos personas en la misma lista pueden recibir un mensaje idéntico byte por byte y verlo en pestañas distintas, y los dos resultados son correctos. Cualquier herramienta o agencia que prometa "llevar tus correos a Principal" está prometiendo algo que ningún remitente controla.

Lo que un remitente sí controla es que el correo se describa con honestidad: autenticación que pruebe el dominio, una lista de gente que lo pidió, una baja que funcione al primer clic, y contenido que gane aperturas y respuestas. Todo eso vale la pena en cualquier pestaña, porque son las mismas señales que te mantienen fuera de Spam.

Cinco afirmaciones que no aguantan una revisión de fuentes

Aparecen en casi toda conversación que tenemos sobre la pestaña Promociones. Ninguna tiene una fuente primaria detrás, y dos son abiertamente dañinas.

"Quita el enlace de baja y llegarás a Principal." Las directrices para remitentes de Google exigen que los mensajes de marketing y de suscripción incluyan un enlace de baja claramente visible en el cuerpo y que admitan la baja con un clic. Quitarlo no te compra Principal. Te deja del lado equivocado de un requisito publicado y empuja a la gente al botón de spam, que es la única señal que de verdad te hace daño.
"Una sola imagen, sin enlaces, y estás a salvo." Ninguna fuente primaria relaciona la pestaña con la cantidad de imágenes o de enlaces. Lo que sí logra un correo de una sola imagen es romperse para quien usa lector de pantalla y convertirse en un rectángulo en blanco para quien tiene las imágenes desactivadas. Estarías cambiando una pérdida medible de accesibilidad por una suposición que nadie puede medir.
"Evita la palabra gratis." Los disparadores por palabra son herencia de los filtros por palabras clave de hace veinte años. Nada en la documentación actual de Google describe un vocabulario prohibido, y escribir esquivando una lista de palabras empeora el texto de una forma que tus lectores notan.
"Pídele a toda tu lista que te arrastre a Principal." Esta es media verdad, y por eso sobrevive. Mover un mensaje sí le enseña a Gmail la preferencia de ese destinatario, y Google lo documenta. Funciona para la persona que lo hace. Como campaña convierte a una tasa que no justifica el esfuerzo, y no hace nada por los suscriptores que consigas el mes entrante.
"El texto plano siempre llega a Principal." Hay mucho correo masivo en texto plano viviendo en Promociones, y mucho correo transaccional con diseño viviendo en Principal. El formato no es la palanca.

Anotaciones: diseñar para la pestaña en vez de pelearse con ella

Existe una forma documentada de hacer que un mensaje promocional rinda más dentro de la pestaña Promociones, y viene de Google. La documentación para desarrolladores de Gmail sobre anotaciones describe un marcado, en JSON-LD o microdatos dentro del mensaje, que permite a Gmail mostrar una imagen de vista previa, una oferta con su código de descuento y su fecha de vencimiento, y el logo del remitente junto al asunto.

Fíjate en lo que eso es y lo que no es. Es Google publicando una interfaz para la pestaña Promociones, lo cual es una declaración bastante directa de que esa pestaña es un lugar donde vale la pena diseñar y no un destierro. No es una salida. Para una tienda o un restaurante que manda ofertas de verdad, una semana invertida en anotaciones y en una oferta más clara rinde más que un año persiguiendo Principal.

La autenticación es el piso, no la palanca

Desde el 1 de febrero de 2024, Google exige a quienes envían más de 5,000 mensajes diarios a cuentas de Gmail que autentiquen con SPF y DKIM, publiquen un registro DMARC para el dominio remitente, tengan DNS directo e inverso válidos en la IP de envío, transmitan sobre TLS y mantengan la tasa de spam que reporta Postmaster Tools por debajo del 0.30%. Las directrices agregan que conviene quedarse bajo el 0.10% y no dejar nunca que llegue al 0.30%.

Nada de eso es un control de la pestaña Promociones, y queremos ser honestos con eso. Es el piso. Si estás por debajo, vas a tener un problema de entrega lo bastante grande como para tapar por completo la pregunta de la pestaña. Si todavía no tienes registro DMARC, el que empieza a recoger evidencia sin cambiar cómo se entrega nada se ve así:

_dmarc.ejemplo.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com"

Una política p=none le pide a los receptores que reporten lo que ven y que no cambien nada. Dos semanas de esos reportes te van a mostrar todos los sistemas que envían como tu dominio, incluida la herramienta de facturación y el CRM que nadie mencionó en la reunión inicial. Ese inventario es el entregable de verdad.

Baja con un clic, como la describe el estándar

El correo de marketing y de suscripción necesita estas dos cabeceras, en cada mensaje:

List-Unsubscribe: , 
List-Unsubscribe-Post: List-Unsubscribe=One-Click

El RFC 8058 define ese par. La segunda cabecera es la señal de que a esa URL se le puede hacer POST sin riesgo, y existe porque el software de correo a veces abre las URL que encuentra en las cabeceras y terminaba dando de baja a la gente por accidente. El remitente tiene que levantar un endpoint que acepte un POST HTTP en esa dirección y no puede responderlo con una redirección, porque los POST redirigidos nunca funcionaron de forma confiable entre clientes. La indicación de Google es atender la solicitud dentro de 48 horas y mantener además el enlace visible en el cuerpo.

Esto pertenece a un texto sobre pestañas por una razón. La alternativa a una baja que funciona al primer clic es el botón de spam, y el botón de spam es la señal que te mueve de una pestaña que no te gusta a una carpeta que nadie lee.

Medir en lugar de adivinar

Postmaster Tools reporta tasa de spam, reputación de dominio y de IP, resultados de autenticación y errores de entrega para el correo que mandas a cuentas personales de Gmail. No reporta la pestaña, y ninguna fuente oficial lo hace. Si un panel dice mostrarte tu reparto entre Principal y Promociones, pregunta de dónde sale el número. Casi siempre son un puñado de cuentas semilla, y una cuenta semilla no tiene historial con tu dominio, que es justamente el dato que decide la categoría para un suscriptor real.

Los instrumentos que sí te dicen algo son los que ya tienes. Mide apertura y respuesta por segmento y no por la lista completa, porque un cambio de pestaña aparece como un escalón hacia abajo en un grupo y no en otro. Vigila la tasa de spam en Postmaster Tools como alerta temprana. Si quieres ayuda para leer esas gráficas, escribimos una guía de los paneles de Postmaster Tools.

Qué revisamos en una cuenta de cliente, en orden

Cuál es el problema de verdad. Entregado en Promociones, o no entregado. Cinco minutos con un envío de prueba y las cabeceras crudas lo resuelven, y eso cambia todo lo que sigue.
Cada fuente de envío, autenticada. SPF y DKIM pasando y alineados para la plataforma de boletines, la herramienta de facturación, el CRM, la tienda y la mesa de ayuda. Aquí está la mayoría de los hallazgos.
DMARC en p=none con reportes llegando a donde alguien los lea. Dos semanas de datos antes de cambiar cualquier política.
El camino de la baja, de punta a punta. Las dos cabeceras presentes, el endpoint de POST respondiendo de verdad, el enlace visible en el cuerpo y la lista de supresión respetada dentro de 48 horas.
La lista misma. Cómo se consiguieron las direcciones, cuándo abrió algo por última vez el segmento dormido, y si una lista comprada está envenenando en silencio un dominio que costó años construir.
Segmentación y frecuencia. Mandar menos correo a quien lo quiere le gana a mandar más a todos, en cada métrica que Gmail puede ver.
Anotaciones, al final. Solo cuando el correo ya está autenticado, es deseado y es medible, y solo si de verdad es promocional.

Fíjate que Promociones nunca aparece como objetivo. Si el trabajo de arriba está hecho, la pestaña se acomoda sola para los destinatarios a quienes les importa, y los que no, tampoco iban a convertir desde Principal.

Cómo ayuda Guanacos Tech

Hacemos este trabajo para pequeñas y medianas empresas en Norteamérica y Latinoamérica, en inglés y en español, y casi siempre empieza igual: una captura, una preocupación, y una hora de evidencia que convierte la preocupación en una lista corta. Si el correo de verdad se está filtrando y no solo clasificando, eso es consultoría de entregabilidad de correo y lo arreglamos a nivel de DNS y de remitentes. Si está clasificado en Promociones y los fundamentos están bien, te lo decimos en vez de venderte un mes de trabajo, y te mostramos la evidencia. Agenda una llamada de 30 minutos y trae la captura y un mensaje rebotado si tienes uno.

Fuentes

Correo empresarial con dominio propio: cómo lo montamos para que funcione desde el primer día

Guanacos Tech — Mon, 28 Sep 2026 12:00:00 +0000

Imagina una firma contable de doce personas que lleva seis años enviando desde info@sudominio.com. El buzón vino incluido con el hosting, nadie recuerda quién lo configuró y este trimestre dos clientes juraron que el correo con la factura nunca llegó. Sí llegó. Cayó en spam, dos veces, y para cuando alguien revisó, la carpeta ya estaba vacía.

Así se ve casi siempre el trabajo de correo empresarial que recibimos. El dominio está bien. La empresa está bien. El correo se configuró una vez, rápido, por quien estaba más cerca del panel del hosting, y después nadie lo volvió a mirar. Este es el orden en que lo montamos desde cero, y el mismo orden en que lo rehacemos cuando heredamos algo que funciona a medias.

Por qué el correo incluido con el hosting sale caro

El hosting compartido incluye correo porque incluirlo es barato, no porque el proveedor sea bueno entregando mensajes. De ahí salen tres consecuencias, y las tres aparecen en proyectos reales.

Envías desde una dirección que no controlas. La IP de salida es del servidor y la compartes con todos los demás sitios alojados ahí. Tu reputación de envío es, en parte, el promedio de lo que hacen desconocidos con sus formularios de contacto.
Nadie es dueño de las cuentas. Cuando alguien se va, muchas veces no hay forma de suspender el buzón, transferirlo ni leer lo que tiene, salvo pedir la contraseña.
La autenticación queda a medias. El panel quizá publique un SPF por ti. Muy pocos firman el correo saliente con DKIM si no lo activas a mano, y casi ninguno publica DMARC.

Nada de eso es grave con cinco mensajes al día. Se vuelve caro la primera vez que una factura, una cotización o un restablecimiento de contraseña no llega.

Las opciones reales y en qué se diferencian

Para una pyme hay tres caminos que vale la pena considerar, y lo que los separa no son las tablas de funciones.

Dejar el correo en el panel del hosting. Lo más barato en la factura. Aceptas reputación compartida, pocas opciones de recuperación y autenticación manual.
Una plataforma de correo dedicada. Google Workspace, Microsoft 365 o Zoho Mail. Ganas una consola de administración, cuentas por usuario que puedes suspender y transferir, y firma DKIM que activas una sola vez.
Una plataforma más un remitente aparte para el correo de aplicaciones. Tu tienda, tu CRM y tu software de facturación también envían con tu dominio. Necesitan su propia autenticación, elijas la plataforma que elijas.

Evalúalas con cuatro preguntas. Quién es dueño de la reputación de envío. Si un administrador puede bloquear una cuenta en menos de un minuto. Si el correo se recupera cuando roban la laptop. Si puedes autorizar a un remitente externo sin romper lo demás. Las listas de funciones casi nunca responden ninguna.

Sobre el costo, compara los precios de lista con lo que te cuesta una hora sin que nadie pueda enviar. Google Workspace Business Starter aparece publicado en USD 8.40 por usuario al mes en el Plan Flexible, precio de lista consultado el 28 de septiembre de 2026 en la página de precios de Google Workspace, con 30 GB de almacenamiento agrupado por usuario; las ediciones Business se venden hasta para 300 usuarios. Nosotros no publicamos nuestras cifras aquí, y tampoco debería dártelas nadie que no haya visto tu dominio antes. Lo que cubre un proyecto está en cómo trabajamos.

Tu dominio: dónde está registrado y dónde vive de verdad su DNS

Este es el paso que más horas desperdicia, y no es técnico. Dónde compraste el dominio y desde dónde se responden sus registros DNS son dos lugares distintos, y muchas veces no son la misma empresa.

Antes de tocar nada, consultamos los nameservers del dominio y confirmamos qué panel responde por él. Editar un registro TXT en el registrador mientras los nameservers apuntan a otro proveedor de DNS produce un registro real, guardado e invisible para internet. Ahí se pierden tardes enteras.

Dos costumbres que conviene mantener. Baja el TTL de los registros de correo un día antes de cambiarlos, para que un error caduque en minutos y no en horas. Y anota los registros actuales antes de editarlos, porque la única marcha atrás confiable es la que puedes volver a pegar.

Usuarios, alias y grupos: qué necesita licencia y qué no

Una forma común de pagar de más es comprar una licencia por cada dirección que la empresa quiere que exista. Necesitas una licencia por cada persona que necesita buzón. Las direcciones salen más baratas que eso.

Usuarios. Uno por cada persona que inicia sesión y envía. Esto es lo que se paga.
Alias. Google Workspace permite agregar direcciones alternas a un usuario existente sin costo adicional, hasta 30 por usuario. Si facturación y ventas las atiende la misma persona, son alias, no cuentas.
Grupos. Una dirección compartida como info@ que responden varias personas es un grupo, no un buzón. Activada como Bandeja de entrada colaborativa, los miembros pueden tomar una conversación, asignarla a alguien más y marcarla como resuelta, que es lo que un equipo pequeño quería de una cuenta compartida desde el principio.

Define esto antes de migrar nada. Decidir después cuáles de las once direcciones eran personas de verdad es más lento que decidirlo antes.

Autentica el primer día, no después del primer reclamo

Los lineamientos para remitentes de Gmail, vigentes desde febrero de 2024, exigen que todo remitente autentique con SPF o DKIM, que el dominio o la IP de envío tengan DNS directo e inverso válidos, que se use una conexión TLS y que la tasa de spam reportada en Postmaster Tools se mantenga debajo de 0.30 por ciento. Quien envía más de 5,000 mensajes diarios a Gmail además debe publicar DMARC y soportar la baja con un clic en el correo de marketing. Un dominio nuevo que se salta esto no queda neutral, queda sin autenticar.

Cuatro registros DNS sostienen todo. Para un dominio nuevo en Google Workspace el enrutamiento es un solo registro MX; los dominios antiguos pueden seguir con el conjunto de cinco registros que Google usaba antes, y no hay prisa por cambiar uno que funciona.

; Enrutamiento de correo, configuraciones nuevas de Google Workspace
sudominio.com.            3600  IN  MX   1 smtp.google.com.

; SPF, un solo registro por dominio, máximo diez consultas DNS
sudominio.com.            3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

; DMARC, primero en modo monitoreo
_dmarc.sudominio.com.     3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@sudominio.com"

DKIM es el que no se copia de ninguna guía, porque la llave es tuya. En la consola de administración está en Apps, Google Workspace, Gmail, Autenticar correo electrónico: genera un registro nuevo, elige 2048 bits si tu proveedor de DNS los soporta, y deja el prefijo de selector google salvo que el dominio ya lo use. Hay dos detalles que agarran desprevenida a la gente. La documentación de Google indica que puede haber que esperar de 24 a 72 horas después de activar Gmail para que la llave aparezca en la consola, así que en un tenant recién creado esto no es tarea de la misma hora. Y si tu proveedor de DNS limita cada cadena TXT a 255 caracteres, una llave de 2048 bits hay que partirla en varias cadenas entre comillas dentro de un mismo valor, no en varios registros.

DMARC va al final, y sale con p=none. Google recomienda empezar ahí para leer quién envía con tu dominio antes de que algo se rechace, y esperar unas 48 horas después de tener SPF y DKIM en vivo antes de publicarlo. Nada de DMARC se configura en la consola de administración; es un registro DNS y solo eso. Subir a cuarentena y después a reject viene luego, cuando los reportes ya te muestran la lista completa de remitentes.

El registro SPF tiene un límite duro que conviene conocer antes de sumar el tercer remitente: diez consultas DNS, contadas entre todos los include. Workspace más un CRM más una plataforma de facturación llegan al tope más rápido de lo que esperas, y la falla es silenciosa. El conteo y las soluciones están en la guía de SPF con demasiadas consultas DNS.

Firmas, dispositivos y el día que alguien se va

Las partes que nadie planea son las que después entran como emergencia.

Verificación en dos pasos, obligatoria. La verificación en dos pasos opcional está apagada justo en las personas donde más la necesitas. Hazla obligatoria con una ventana corta de inscripción y una ruta de recuperación documentada para la cuenta del dueño.
Recuperación del administrador. Un superadministrador bloqueado fuera de la consola, sin teléfono de recuperación y sin un segundo admin, es una caída de varios días. Crea un segundo administrador el primer día.
Salida de personal por escrito. Suspender la cuenta, transferir los archivos, poner un reenvío a quien hereda la relación y después liberar la licencia. Borrar la cuenta primero pierde el correo.
Firmas definidas al centro. Once personas escribiendo su propia firma producen once versiones de la dirección de la empresa. Define la plantilla una vez a nivel de organización.

Si ya tienes correo en otro lado

Casi nadie empieza con un dominio vacío. La secuencia que mantiene a todos trabajando es la misma ya sea que el correo esté en cPanel, en una cuenta personal de Gmail o en un tenant viejo de Microsoft: primero crea usuarios y grupos en la plataforma nueva, luego copia el correo mientras el sistema viejo sigue recibiendo, y hasta el final cambia el registro MX. El corte es el último paso, no el primero.

Dos cosas para planificar alrededor. Puede seguir llegando correo al host viejo durante horas después del cambio, mientras caducan las cachés de DNS, así que deja los buzones antiguos accesibles en vez de borrarlos el mismo día. Y cada formulario, tienda y herramienta de facturación que envía con tu dominio necesita volver a autorizarse contra la plataforma nueva, porque el cambio de MX mueve el correo entrante y no hace absolutamente nada por el saliente. La secuencia completa para el punto de partida más común está en migrar el correo de cPanel a Google Workspace.

Cómo ayuda Guanacos Tech

Montamos el correo empresarial sobre el dominio del cliente de punta a punta: la elección de plataforma con las razones por escrito, usuarios, alias y grupos dimensionados para que no pagues por direcciones, los cuatro registros DNS publicados y verificados, y una primera lectura de los reportes DMARC dos semanas después para cazar al remitente que nadie mencionó. Si prefieres delegarlo en vez de aprenderte un panel de DNS, para eso están los consultores de Google Workspace. Con una llamada de 30 minutos nos alcanza para ver tu dominio y decirte qué falta de verdad.

Fuentes

Recibos que pasan SPF y aun así fallan DMARC: alineación en SendGrid, Mailgun y Amazon SES

Guanacos Tech — Mon, 28 Sep 2026 12:00:00 +0000

Una tienda en línea de diez personas con la que trabajaríamos normalmente tenía un reclamo que sonaba a nada. Las confirmaciones de pedido de la plataforma llegaban bien. Los restablecimientos de contraseña y los recibos de pago, enviados por el desarrollador a través de un proveedor transaccional, caían en la carpeta de spam de Gmail más o menos la mitad de las veces. Alguien ya había revisado el SPF, el SPF pasaba, y la conversación siguió hacia los asuntos y las imágenes.

Que el SPF pase no es la prueba. DMARC hace una segunda pregunta, y el correo transaccional es donde la respuesta suele salir mal. Además es invisible desde afuera: el registro se ve correcto, el panel del proveedor dice que el dominio está verificado, y el correo igual falla.

Por qué el correo transaccional falla DMARC aunque el SPF se vea bien

A DMARC no le importa que un mensaje haya pasado SPF. Le importa si el dominio que pasó es el dominio que ve quien lee. Eso es la alineación, y el RFC 7489 cabe en una frase: un mensaje pasa DMARC cuando el SPF pasa y su dominio se alinea con el encabezado From, o cuando el DKIM pasa y su dominio se alinea, o ambas. Basta con una de las dos.

Google dice lo mismo desde el lado del receptor. Sus lineamientos para remitentes exigen que quien envía más de 5,000 mensajes al día a cuentas de Gmail publique SPF, DKIM y un registro DMARC, y que el dominio del From se alinee con el dominio del SPF o con el del DKIM. Los dos mecanismos son obligatorios, una sola alineación alcanza, y el correo que falla puede ser rechazado con un error 5.7.26. Lineamientos consultados el 28 de septiembre de 2026.

Las plataformas de marketing suelen romper esto del lado del DKIM, que es lo que cubre la guía sobre alineación en Mailchimp, HubSpot y Klaviyo. Los proveedores transaccionales lo rompen en un lugar más específico: el sobre.

Remitente del sobre contra encabezado From

Todo mensaje lleva dos direcciones de remitente y la mayoría de la gente solo ve una.

El remitente del sobre, también llamado return path o MAIL FROM, es la dirección que el servidor entrega durante la conversación SMTP. Ahí llegan los rebotes. Nadie la lee. El SPF autentica esa.
El encabezado From es la dirección que va dentro del mensaje, la que ve quien lo recibe y la que querría falsificar alguien que hace phishing. DMARC protege esa.

Cuando las dos son tuyas, la alineación del SPF ocurre sola. Cuando un proveedor pone su propio dominio en el sobre y deja tu nombre en el From, el SPF pasa para el proveedor y no se alinea con nada. Al receptor le queda una sola oportunidad: el DKIM. Si el DKIM firma con el dominio del proveedor en la etiqueta d= en lugar del tuyo, DMARC falla, y el reporte que leas después mostrará un pass de SPF junto a un fail del mensaje.

La alineación tiene dos modos y el predeterminado es el permisivo. La alineación relajada, aspf=r y adkim=r, acepta cualquier subdominio del mismo dominio organizacional, así que mail.ejemplo.com se alinea con ejemplo.com. La estricta exige coincidencia exacta. Casi todas las soluciones de abajo funcionan porque el modo relajado es el predeterminado.

De aquí en adelante, todo se reduce a dos movimientos: que el dominio del sobre sea tuyo, o que el d= del DKIM sea tuyo.

SendGrid: la autenticación de dominio resuelve las dos, si la terminas

Con una API key basta para enviar por SendGrid. No basta para pasar DMARC. El paso que importa es la autenticación de dominio, antes llamada sender authentication, y consiste en registros CNAME que publicas en tu propio dominio en lugar de registros TXT que pegas a mano.

Con Automated Security activado, SendGrid genera tres CNAME: dos para DKIM y uno que crea un subdominio de marca usado para el return path. Los registros de DKIM usan los selectores s1 y s2, así que publicas algo con esta forma, tomando los valores de destino de tu propio panel porque llevan identificadores de tu cuenta:

s1._domainkey.ejemplo.com.   CNAME   s1.domainkey.uNNNNNN.wlNNN.sendgrid.net.
s2._domainkey.ejemplo.com.   CNAME   s2.domainkey.uNNNNNN.wlNNN.sendgrid.net.
emNNNN.ejemplo.com.          CNAME   uNNNNNN.wlNNN.sendgrid.net.

Dos selectores de DKIM en vez de uno es la forma en que SendGrid rota las llaves sin que tú intervengas. Una vez verificado, SendGrid firma tu correo con tu dominio en d=, así que el DKIM se alinea, y el subdominio de marca deja el return path dentro de tu dominio organizacional, con lo que el SPF también se alinea en modo relajado. Eso es un mensaje que pasa DMARC por los dos mecanismos, que es donde quieres tener un recibo.

Dos cosas salen mal en este paso, una y otra vez. La primera es un proveedor de DNS que no acepta guiones bajos en el nombre de un CNAME, algo común en paneles de hosting compartido antiguos. La respuesta de SendGrid es desactivar Automated Security en la configuración avanzada y publicar registros MX y TXT a mano, a cambio de encargarte tú de la rotación de llaves. La segunda es un proveedor que pone los registros detrás de su proxy por defecto, siendo Cloudflare el ejemplo habitual: un CNAME de autenticación proxeado resuelve al proxy y no a SendGrid, así que la verificación falla o deja de funcionar más adelante. Todos los registros de ese conjunto tienen que quedar en modo solo DNS.

Mailgun: el subdominio de envío hace casi todo el trabajo

Mailgun pide verificar un dominio antes de enviar, y la verificación existe por dos razones: comprobar que el nombre es tuyo y autorizar a los servidores de Mailgun a enviar como él. Su configuración documentada son dos registros TXT, uno de SPF y uno de DKIM, y su recomendación es usar un subdominio como mg.ejemplo.com en lugar del dominio raíz, lo que mantiene la reputación de envío de Mailgun separada del correo que tu equipo escribe a mano.

mg.ejemplo.com.                 TXT   "v=spf1 include:mailgun.org ~all"
mx._domainkey.mg.ejemplo.com.   TXT   "k=rsa; p=MIGfMA0GCSq..."

Ese subdominio es la razón por la que Mailgun suele ser el más sencillo de los tres. El correo sale con el remitente del sobre en tu dominio de envío y firmado con d=mg.ejemplo.com, y en alineación relajada los dos coinciden con un From en ejemplo.com. Publica el registro SPF en el subdominio, no en la raíz; un segundo registro SPF en la raíz no es una solución, es un error permanente, porque un dominio puede publicar exactamente uno.

Amazon SES: Easy DKIM sí alinea, el MAIL FROM por defecto no

SES es el que agarra desprevenida a gente cuidadosa, porque la configuración por defecto pasa SPF y falla DMARC al mismo tiempo.

Cuando envías por SES sin configurar un dominio MAIL FROM, el remitente del sobre es un subdominio de amazonses.com. Ese dominio publica un registro SPF válido que cubre la infraestructura de SES, así que la verificación de SPF pasa sin problema. Solo que pasa para Amazon. El dominio del sobre y tu dominio del From no coinciden, así que la alineación del SPF falla y DMARC solo puede satisfacerse por DKIM.

Easy DKIM sí lo satisface. SES publica registros CNAME que le permiten firmar con tu dominio, así que una identidad verificada con Easy DKIM activado se alinea por DKIM y pasa DMARC. Muchos remitentes pequeños se quedan ahí y les funciona. Es un punto único de falla, eso sí: un registro DKIM roto, un mensaje modificado por un reenvío, y no hay alineación de SPF debajo para atajarlo.

La solución es un dominio MAIL FROM personalizado, que siempre es un subdominio de la identidad que verificaste. AWS documenta dos registros sobre él: un MX para que la retroalimentación de rebotes llegue a SES, y un TXT que publica el SPF.

mail.ejemplo.com.   MX    10 feedback-smtp.us-east-1.amazonses.com.
mail.ejemplo.com.   TXT   "v=spf1 include:amazonses.com ~all"

Usa en el valor del MX la región desde la que realmente envías. Como el dominio MAIL FROM personalizado es un subdominio y no una coincidencia exacta, esto solo se alinea con la política de SPF relajada, que es la predeterminada; un registro DMARC con aspf=s tira abajo todo el arreglo. Configúralo en cada región y en cada cuenta desde la que envías, no solo en producción, o la primera factura enviada desde una cuenta de pruebas será la que falle.

Un dominio, tres remitentes, diez consultas

La mayoría de los dominios que auditamos no envían por un solo proveedor. Hay un Google Workspace para el personal, una plataforma de tienda para el correo de pedidos, un proveedor transaccional para los recibos y algo que nadie recuerda haber activado para el boletín mensual. Cada uno quiere un include: en el registro SPF, y el SPF permite diez consultas DNS por evaluación según el RFC 7208, sección 4.6.4. Si te pasas, el resultado es PermError, y la mayoría de los receptores lo tratan como si no hubiera SPF.

Los subdominios son la salida. Un proveedor transaccional en mail.ejemplo.com y una plataforma de marketing en news.ejemplo.com llevan cada uno su propio registro SPF con su propio presupuesto de consultas, mientras la raíz conserva solo los remitentes que de verdad la usan, y por la alineación relajada todos siguen cumpliendo DMARC para un From en ejemplo.com. Si ya estás en el límite, la guía sobre cómo bajar de 10 consultas DNS en SPF trae el método para contarlas.

Qué política corresponde a cada subdominio está en el artículo sobre subdominios en DMARC y la etiqueta sp.

Qué revisamos antes y después del cambio

Este es el orden en que trabajamos sobre el dominio de un cliente, y es aburrido a propósito.

Primero el inventario, después el DNS. Leemos dos semanas de reportes agregados de DMARC y listamos cada fuente que envía como el dominio. Cambiar registros antes de saber quién envía es la forma de que dejen de llegar las facturas.
Confirmamos que la política siga en p=none mientras dura el trabajo, con una dirección rua que alguien lea. Nada de lo de abajo es seguro de hacer bajo aplicación estricta.
Arreglamos un proveedor a la vez y enviamos un mensaje real después de cada uno, a un buzón en una plataforma distinta de la que usas todos los días.
Leemos las cabeceras de ese mensaje en lugar de confiar en un panel. La línea Authentication-Results nombra el dominio del SPF y el valor d= del DKIM, que es el único lugar donde la alineación se ve.
Esperamos un ciclo más de reportes antes de tocar la política y después subimos, cuarentena antes que reject, con la lista de remitentes externos revisada y no supuesta.

La falla que más vemos es el paso tres saltado: tres proveedores arreglados en una tarde, uno de ellos mal, y ninguna manera de saber cuál sin empezar de nuevo.

Cómo ayuda Guanacos Tech

Somos una consultoría independiente con ingenieros certificados por Google, y trabajamos con empresas pequeñas y medianas de Norteamérica y Latinoamérica, en inglés y español. El correo transaccional es una forma normal de que este trabajo empiece: recibos que se pierden, un desarrollador que es dueño de la API key y nadie que sea dueño de la zona DNS. Construimos el inventario de remitentes con tus propios reportes, arreglamos cada proveedor para que se alinee por los dos mecanismos donde el proveedor lo permita, mantenemos el registro SPF dentro de su presupuesto de consultas y después subimos la política hasta aplicación estricta con un calendario en vez de una esperanza.

Si prefieres mirar tú primero, el analizador de reportes DMARC y el diagnóstico de correo son gratis y no piden cuenta. Si prefieres delegarlo, aquí está nuestra consultoría de entregabilidad de correo y cómo trabajamos. Lleva a la llamada un recibo rebotado con sus cabeceras completas y normalmente podemos nombrar la causa en pantalla.

Documentación de proveedores de SendGrid, Mailgun y Amazon SES consultada el 28 de septiembre de 2026.

Fuentes

Las GPUs NVIDIA T4 y P4 pierden soporte el 1 de agosto de 2027: la migración que planificamos ya

Guanacos Tech — Fri, 25 Sep 2026 12:00:00 +0000

Imagina un estudio de video de veinte personas en Ciudad de Guatemala con dos VMs en Google Cloud con GPUs NVIDIA T4 conectadas. Una hace la transcodificación de cada noche. La otra es una estación de trabajo virtual con Windows a la que un editor entra desde su casa tres días por semana. Las dos las armó en 2021 un contratista que hace mucho dejó de trabajar con ellos. Ya nadie abre la consola de Cloud, porque nada está fallando.

Ese es justo el perfil al que más le duele un aviso de fin de soporte de GPU. Las máquinas siguen trabajando hasta el día en que dejan de hacerlo, y ese día ya está en el calendario.

Qué cambió y cuál es la fecha que importa

En las notas de versión de Google Cloud del 22 de septiembre de 2026, Compute Engine marcó como obsoletas las GPUs NVIDIA T4 (nvidia-tesla-t4 y nvidia-tesla-t4-vws) y las NVIDIA P4 (nvidia-tesla-p4 y nvidia-tesla-p4-vws), con fecha de fin de soporte.

La fecha de fin de soporte de las dos es el 1 de agosto de 2027. La propia página de fin de soporte de Google lo dice sin rodeos: hasta esa fecha, los recursos con GPUs T4 siguen funcionando con normalidad, y a partir del 1 de agosto de 2027 ya no vas a poder crear, iniciar ni acceder a ningún recurso de Google Cloud que use esas GPUs. La P4 lleva la misma fecha y la misma redacción.

Esto no es una vista previa ni un rumor. Está en las páginas publicadas de obsolescencia, y tiene un antecedente que ya ocurrió: la NVIDIA P100 llegó a fin de soporte el 15 de septiembre de 2026, diez días antes de que escribiéramos esto. Si todavía estabas en una P100, esa decisión ya la tomaron por ti.

La palabra que hay que tomar en serio es acceder. No se trata solo de prohibir máquinas nuevas. Una VM que existe pero que no se puede iniciar después de esa fecha es una máquina apagada con un disco conectado, y el disco se sigue facturando.

A quién le pega esto en una empresa pequeña o mediana

La T4 fue durante años el caballito de batalla del cómputo con GPU barato. Es tan accesible que los equipos chicos la pusieron en cosas que una empresa grande jamás aceleraría. En proyectos de clientes la encontramos en cinco lugares.

Inferencia sobre una VM N1. Una sola T4 conectada a una máquina de propósito general, corriendo un modelo de transcripción, un pipeline de OCR, un clasificador de imágenes o un servicio de recomendaciones.
Estaciones de trabajo virtuales. Las variantes -vws existen para CAD, edición de video y 3D entregados a un escritorio remoto. Compute Engine agrega sola la licencia de NVIDIA RTX Virtual Workstation cuando creas ese tipo de instancia, y por eso ese costo queda escondido dentro de la línea de la VM en la factura.
Node pools de GKE. Un pool fijado a aceleradores T4 dentro de un clúster que alguien configuró una sola vez.
Pipelines de Dataflow y trabajos de Managed Service for Apache Spark cuya configuración de workers nombra la T4 de forma explícita.
Configuraciones de Cloud Workstations y cargas de Gemini Enterprise Agent Platform que apuntan a la T4 como su acelerador.

El hilo común es que en todos esos lugares el modelo de GPU está escrito en un archivo de configuración, una plantilla o un recurso de Terraform, no lo elige una persona cada mañana. Nadie se va a dar cuenta de la obsolescencia mirando una pantalla. Alguien tiene que ir a leer la configuración.

Qué revisamos primero en un proyecto de cliente

Antes de proponer cualquier migración queremos la lista completa. La primera pasada es un comando por proyecto, del conjunto documentado de comandos comunes de Compute Engine:

gcloud compute instances list \
  --filter="guestAccelerators.acceleratorCount>0" \
  --format="table(name,zone,guestAccelerators.acceleratorType,guestAccelerators.acceleratorCount,disks.type)"

Córrelo en todos los proyectos de la organización, no solo en el que se llama producción. Las VMs con GPU tienen la costumbre de vivir en un proyecto bautizado como una prueba de concepto de hace tres años.

Después revisamos los lugares a los que ese comando no llega:

Plantillas de instancia y grupos de instancias administrados. Las VMs que están corriendo pueden estar bien mientras la plantilla que las recrea sigue nombrando una T4. Esa es la falla que te despierta a las 3 de la mañana después de un evento de autoescalado en agosto de 2027.
Node pools de GKE. Lista los pools y lee el acelerador de cada uno, incluidos los que están escalados a cero.
Plantillas de Dataflow y definiciones de trabajos de Spark que fijan un acelerador de worker.
Configuraciones de Cloud Workstations.
Código de infraestructura. Terraform, Deployment Manager, scripts de shell en un repo. Busca tesla-t4 y tesla-p4 en todos los repositorios, incluidos aquellos donde nadie ha hecho un commit en un año.
Descuentos por uso comprometido. Los compromisos vigentes de uno y de tres años sobre T4 siguen válidos hasta su fecha de vencimiento, pero ya no se pueden comprar ni renovar compromisos de tres años sobre T4. Cualquier compromiso que venza cerca de agosto de 2027 necesita una decisión ahora, no una renovación automática hacia un callejón sin salida.
Si la carga todavía necesita GPU. Varios de los pipelines que heredamos se aceleraron porque una T4 salía barata, no porque las matemáticas lo pidieran. Dos de cada tantas migraciones terminan siendo un borrado.

La mudanza, en el orden en que la hacemos

Los destinos que Google recomienda son la serie de máquinas G2 con GPUs NVIDIA L4 y la serie G4 con NVIDIA RTX PRO 6000. El detalle estructural importante, el que suele sorprender: no puedes cambiar una instancia existente en el lugar de un tipo de máquina N1 de propósito general a un tipo optimizado para aceleradores. No hay una edición que convierta una VM con T4 en una VM con L4. Se crea una instancia nueva y se mueven los datos.

Elige el destino y la zona. G2 y G4 no están en todas las zonas donde había T4. Revisa la página de ubicaciones de GPU para tu región antes de prometerle a alguien que la máquina se queda donde está. A veces la respuesta honesta es que la carga cambia de región, y eso trae consecuencias de latencia y de residencia de datos que conviene poner sobre la mesa temprano.
Rescata los datos de Local SSD. Si la instancia vieja usa discos Local SSD con algo que quieras conservar, copia su contenido a un volumen de Persistent Disk primero. Los datos de Local SSD no sobreviven la mudanza, y tampoco sobreviven a un apagado.
Crea la instancia nueva G2 o G4. Instala los controladores desde cero. Para una estación de trabajo virtual esto significa los controladores de NVIDIA RTX Virtual Workstation, no los estándar.
Mueve los volúmenes de Persistent Disk. Desconéctalos de la instancia vieja y conéctalos a la nueva.
Vuelve a probar la carga real antes de borrar nada. La T4 es Turing y la L4 es Ada Lovelace. Una imagen de contenedor con una versión de CUDA o de controlador fijada, un kernel compilado o un artefacto de modelo construido para una capacidad de cómputo específica pueden negarse a cargar. Ahí está el trabajo de verdad, y por eso no agendamos la migración para julio de 2027.
Actualiza todo lo que crea máquinas. Plantillas de instancia, node pools de GKE, configuración de workers de Dataflow, configuraciones de workstations, Terraform. Una VM migrada con una plantilla sin migrar no está migrada.
Borra las instancias viejas solo después de que un ciclo completo del negocio haya corrido limpio en las nuevas. Un cierre de mes es buena marca para la mayoría de nuestros clientes.

Notas de costo y de riesgo

No vamos a poner precios de GPU aquí, porque se mueven y una cifra vieja en un artículo es peor que ninguna cifra. Cotiza tu configuración específica en la calculadora de precios de Google Cloud el día que planifiques, y vuelve a revisarla antes de comprometerte.

Lo que sí te podemos decir es que cambia la forma de la factura. La T4 era un acelerador que conectabas a una máquina N1 que tú dimensionabas, así que CPU y GPU iban por separado. G2 y G4 son series optimizadas para aceleradores, con proporciones fijas de GPU a vCPU y memoria. Si tu caja con T4 era un CPU pequeño con una GPU, la máquina soportada más cercana puede darte más CPU del que pediste. Eso no es automáticamente más caro, porque la guía de Google dice que los clientes que pasan de T4 a L4 pueden ver de dos a cuatro veces mejor rendimiento, y un trabajo que termina en un tercio del tiempo en una máquina facturada por segundo puede salir más barato aun con una tarifa por hora más alta. Mide tu propia carga. No aceptes ni la versión optimista ni la pesimista sin una prueba.

Tres riesgos que señalamos en todos estos proyectos:

La máquina olvidada. Agosto de 2027 se siente lejos, y por eso mismo la estación de trabajo del editor va a seguir en una T4 en julio de 2027. Pon el inventario en un ticket con fecha, no en la cabeza de alguien.
La trampa del compromiso. Renovar un descuento sobre hardware con fecha publicada de fin de soporte amarra dinero a una máquina que vas a tener que dejar.
La plantilla silenciosa. El autoescalado y la reparación de nodos recrean máquinas desde plantillas. Una plantilla que nombra un acelerador retirado convierte un martes tranquilo en una caída.

Cómo ayuda Guanacos Tech

Esto lo hacemos como un trabajo acotado: inventariar cada GPU en cada proyecto, ligar cada una a una carga y a un responsable, probar el reemplazo con L4 o RTX PRO 6000 contra el trabajo real, y entregarte un plan de migración con fechas que caen bastante antes del límite y no encima de él. Si la respuesta honesta para una carga es que ya no necesita GPU, también lo decimos, y el ahorro es tuyo.

Si quieres un segundo par de ojos sobre un proyecto de Google Cloud que heredaste, así arranca nuestro trabajo de consultoría de Google Cloud. Agenda una llamada de 30 minutos y trae los IDs de tus proyectos.

Fuentes

Qué es DMARC y cómo configurarlo paso a paso, sin romper tu propio correo

Guanacos Tech — Fri, 25 Sep 2026 12:00:00 +0000

Una firma contable de doce personas nos escribe en la última semana del mes porque sus facturas dejaron de llegar. No todo su correo: los mensajes que la gente escribe a mano desde Gmail siguen entrando bien. Los que desaparecen son los que manda el sistema de facturación. Alguien en un foro les dijo que configuraran DMARC, pegaron un registro que encontraron en internet y por la tarde el CRM también se había quedado callado. Es una forma normal de llegar a este tema, y se arregla en una tarde cuando entiendes qué revisa DMARC de verdad.

DMARC no es un filtro de spam y no es un interruptor que haga que tu correo se entregue mejor. Es una instrucción pública tuya, del dueño del dominio, para cada servidor que reciba un mensaje que dice venir de ti. Dice dos cosas: así se distingue mi correo real del correo que solo dice ser mío, y esto quiero que hagas con el que no pase la prueba. Escrito, es una línea de DNS. Entendido, es la única parte de la autenticación de correo que te dice quién está enviando con tu dominio.

El problema que resuelve DMARC

Cualquiera puede escribir tu dominio en el campo De de un mensaje. No es una falla de un servidor en particular, es como funciona el formato, y por eso una factura falsa convincente que sale de tu propio dominio es un ataque tan barato. Dos mecanismos más antiguos cierran cada uno una parte del hueco.

SPF es una lista, publicada en tu DNS, de los servidores autorizados a enviar correo por tu dominio. DKIM es una firma que se agrega al mensaje mismo y se verifica contra una llave pública que publicas en tu DNS. Los dos sirven y los dos tienen el mismo punto ciego: ninguno está amarrado a la dirección que tu lector ve en el campo De. Un mensaje puede pasar SPF para un dominio completamente distinto y aun así mostrarle tu nombre a quien lo lee.

DMARC es la regla que conecta las dos, y además hace algo que casi ninguna otra parte del correo hace: te manda un reporte.

La alineación es todo el truco

Para pasar DMARC, un mensaje tiene que pasar SPF o DKIM, y el dominio que pasó tiene que coincidir con el dominio del campo De que ve tu lector. Google lo dice claro en su propia documentación: los mensajes salientes deben pasar SPF o DKIM, y en el correo directo el dominio del encabezado De debe estar alineado con el dominio de SPF o con el de DKIM. Pasar uno de los dos alcanza. No pasar ninguno de forma que coincida con tu dominio es una falla de DMARC, por limpio que se vea el resto del mensaje.

Hay dos niveles de exigencia para esa coincidencia. Relajado, que es el predeterminado, acepta la coincidencia a nivel del dominio organizacional, así que un mensaje firmado para correo.ejemplo.com se alinea con una dirección De en ejemplo.com. Estricto exige que los dominios sean idénticos. Vale repetir lo que dice la guía de solución de problemas de Google: la alineación estricta puede mandar a spam correo legítimo de subdominios asociados, y la relajada normalmente da protección suficiente contra la suplantación. Si no tienes una razón concreta, déjala relajada.

La alineación es también de dónde sale el problema de las facturas del primer párrafo. Digamos que el sistema de facturación envía como facturacion@ejemplo.com, pero sus servidores usan una ruta de retorno en el dominio del proveedor y firman con la llave DKIM del proveedor. SPF pasa. DKIM pasa. DMARC falla, porque ninguno de los dominios que pasaron es el tuyo. Un registro puesto en reject el primer día convierte ese detalle de autenticación en facturas que no llegan.

Tu primer registro: p=none y un lugar donde recibir los reportes

El orden importa más que la velocidad. La guía de Google es tener SPF y DKIM configurados, y funcionando desde al menos 48 horas antes, cuando activas DMARC. Si te lo saltas, el correo de tu dominio probablemente va a tener problemas de entrega, que es justo lo que querías evitar.

El registro es un solo registro DNS de tipo TXT en el host _dmarc de tu dominio. Las etiquetas v y p van primero; las demás pueden ir en cualquier orden.

Host:  _dmarc
Tipo:  TXT
Valor: v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com

Léelo en voz alta y es corto. p=none quiere decir: no cambies cómo tratas mi correo, solo cuéntame qué estás viendo. rua es la dirección donde llegan los reportes agregados diarios. Google recomienda que sea un grupo o un buzón dedicado y no la bandeja personal de alguien, y después de la primera semana de archivos XML vas a entender la recomendación. Los reportes se envían normalmente una vez al día, por cada receptor que vio tu correo.

Hay dos etiquetas más que vale conocer antes de que un consultor te las ofrezca. sp define una política aparte para los subdominios que existen, y np define una para los subdominios que no existen, que es como evitas que alguien invente facturas.ejemplo.com y envíe desde ahí. Cuando np no está, aplica la política de sp, y cuando tampoco está sp, aplica la de p. Las dos están definidas en el RFC 9989, la especificación vigente de DMARC.

Lee los reportes antes de endurecer nada

Este es el paso que la gente se salta, y es el único que hace seguro todo lo demás. Cada reporte agregado es un archivo XML de un receptor que cubre un día de tu correo: qué direcciones IP lo enviaron, cuántos mensajes, si SPF y DKIM pasaron, y si se alinearon con tu dominio. No lo lees por los números. Lo lees para armar la lista de todo lo que en este mundo envía correo con tu dominio.

En una pyme esa lista es más larga de lo que el dueño espera, y casi siempre es alguna versión de esto: Google Workspace o Microsoft 365 para las personas, el sistema de facturación o contabilidad, el CRM, la tienda en línea, la herramienta de boletines, el formulario de contacto del sitio, un escáner en una esquina de la oficina que manda PDF, y un servicio que nadie recuerda haber contratado. Revísala y pon cada remitente en uno de tres grupos.

Ya alineado. Nada que hacer. Casi todo tu correo de Workspace o Microsoft 365 cae aquí.
Tuyo, y fallando. Los que hay que arreglar, uno por uno, casi siempre activando la firma DKIM del proveedor para tu dominio o configurando una ruta de retorno propia. Este es el trabajo real de un proyecto de DMARC.
No es tuyo. Alguien enviando con tu dominio sin que debiera. Este grupo es el que justifica todo el ejercicio, y la razón por la que en algún momento vas a querer una política distinta de none.

Subir a quarantine y después a reject

El despliegue que recomienda Google es observar los reportes por lo menos una semana, confirmar que tu propio correo saliente está autenticando, luego pasar a quarantine para que el correo que falla caiga en la carpeta de spam donde el destinatario todavía puede encontrarlo, empezando con una parte pequeña de los mensajes y subiéndola con el tiempo hasta todos, y solo después pasar a reject.

Una corrección a las guías viejas, incluidas muchas que siguen en línea. Te dicen que hagas esa subida con una etiqueta pct en el registro. El RFC 9989, publicado en mayo de 2026, reemplazó al RFC 7489 como especificación de DMARC y quitó pct de la sintaxis del registro; el apéndice que cubre el cambio se titula "Removal of the 'pct' Tag". Lo que la especificación sí conserva para un despliegue prudente es la etiqueta t, una señal de que todavía no quieres que se aplique la política que declaraste, que no cambia nada de los reportes y no tiene efecto mientras la política sea none. La lectura práctica para un dominio pequeño: no armes tu plan alrededor de un porcentaje. Alinea todos los remitentes de tu lista, quédate en quarantine una semana cuando haya alguien atento a los reclamos, y después pasa a reject. La seguridad viene del inventario, no de la fracción.

También ayuda saber qué piden los receptores grandes, porque es menos de lo que se supone. Gmail exige a quienes envían más de 5,000 mensajes al día a cuentas de Gmail tener SPF, DKIM y DMARC configurados, y dice con claridad que la política de aplicación de DMARC puede estar en none. Las mismas guías piden que el encabezado De esté alineado con el dominio de SPF o de DKIM, una tasa de spam por debajo de 0.30% en Postmaster Tools, DNS directo e inverso válidos, y TLS en la conexión. Es decir, p=none cumple el requisito. Subes a reject para proteger tu propio dominio de que lo usen contra tus clientes, no para cumplirle a Gmail.

Los errores que más arreglamos

Casi toda configuración de DMARC rota que nos entregan es uno de estos seis.

Dos registros en _dmarc. Uno viejo de un intento anterior al lado del nuevo. DMARC espera exactamente un registro de política, y con dos publicados en la práctica no tienes ninguno.
Un rua que nadie puede leer. Un error de dedo en el mailto, o reportes que caen en un buzón que ningún humano abre. Entonces el dominio se queda en p=none dos años, lo que no protege nada y no le dice nada a nadie.
Alineación estricta copiada de un blog. Suena más segura y es el ajuste con más probabilidad de mandar a spam el correo de tus propios subdominios.
Saltar directo a p=reject. El registro es fácil de publicar y el daño es invisible para ti, porque los rebotes llegan a los sistemas que envían en tu nombre, no a tu bandeja.
Olvidar el subdominio desde el que envía la herramienta de marketing. Una política en el dominio raíz no arregla un remitente sin alinear en un subdominio, y sp existe justo para esto.
Esperar que DMARC sobreviva al reenvío. Cuando un mensaje se reenvía, SPF se rompe con frecuencia, porque el servidor que reenvía no está en tu lista. DKIM sobrevive mucho mejor al reenvío, que es una buena razón para asegurarte de que DKIM esté firmando antes de aplicar cualquier política.

Cómo ayuda Guanacos Tech

En un proyecto de entregabilidad, esto es casi todo el trabajo real: nombrar cada sistema que envía con el dominio, leer suficientes reportes para estar seguros de que la lista está completa, arreglar la alineación remitente por remitente, y quedarnos en los reportes lo suficiente para saber que el arreglo aguantó antes de subir la política. Nada de eso es ingenioso. Solo es ordenado, y el orden es lo que mantiene las facturas llegando. Si quieres hacerlo tú con el registro de arriba y una semana de reportes, es un resultado perfectamente bueno. Si los reportes te devolvieron nueve remitentes y dos que no puedes identificar, para eso está nuestra consultoría de entregabilidad de correo. Trae tu dominio y un mensaje que esté fallando a una llamada de 30 minutos y sales sabiendo qué remitentes son el problema y qué toma resolverlos.

Fuentes

Por qué el 2FA no detuvo este robo de cuenta de Google, y qué sí lo habría hecho

Guanacos Tech — Fri, 25 Sep 2026 12:00:00 +0000

Este mes investigamos el robo de una cuenta para un cliente. Nadie abrió un adjunto raro, ninguna computadora se infectó y la persona afectada es cuidadosa. Aun así, su cuenta de Google fue tomada, los atacantes la guardaron en silencio una semana y luego la usaron para enviar una "invitación" maliciosa a más de 1,400 de sus contactos. Lo contamos sin ningún nombre porque este mismo patrón está golpeando a pequeñas empresas en todas partes, y es fácil de frenar una vez que lo has visto.

Cómo empezó: el correo hackeado de una persona real

El correo llegó de un director de escuela con quien nuestro cliente había trabajado de verdad unas semanas antes. Su cuenta había sido hackeada y los atacantes la usaron para escribirle a todos sus contactos, en copia oculta. El mensaje era corto: "ha compartido un archivo contigo", un botón de "Leer documento" y su firma real.

Como salió de su buzón real, pasó todas las revisiones técnicas. SPF, DKIM y DMARC confirmaron que era suyo, y el filtro de spam no tenía motivo para detenerlo. Eso es lo que hace funcionar este tipo de phishing: llega de alguien que conoces, no de un desconocido.

La página de inicio de sesión falsa

El botón no llevaba a un sitio cualquiera. Abría una página alojada en un servicio legítimo de Google, así que la primera dirección parecía google.com. Esa página pedía "verificar tu identidad para ver el documento" y luego mandaba a una copia de la pantalla de inicio de sesión de Google en un dominio de los atacantes.

No era una copia burda. Era la página real de Google, pasando por el servidor de los atacantes en tiempo real. Los equipos de seguridad lo llaman un ataque de adversario en el medio. Todo lo que se escribe va primero al atacante y después a Google: la contraseña y luego la verificación por teléfono que Google pide. A los ocho minutos del clic, los atacantes ya habían iniciado sesión en su cuenta desde un servidor de hosting.

Por qué la verificación por teléfono no sirvió

Google sí pidió un segundo paso. Se completó a través de la misma página falsa, porque para la persona parecía parte normal del inicio de sesión. Los códigos por SMS, los códigos de una app y los avisos de "¿Eres tú?" se pueden reenviar así. La página no necesita romper nada. Solo reenvía lo que la persona hace.

Lo que los atacantes buscaban era el resultado: cuando Google acepta el inicio de sesión, le da al navegador una sesión, lo que te mantiene conectado. La página falsa se quedó con esa sesión para los atacantes. Desde ahí ya no necesitaban ni la contraseña ni el teléfono.

Hubo algo que no pudieron reenviar. Su primer movimiento fue intentar cambiar la verificación en dos pasos, seguramente para poner su propio teléfono y dejarla fuera. Ese paso pidió su llave de acceso (passkey), que solo funciona en el google.com real, y falló.

Una semana de silencio y luego el envío masivo

Google marcó ambas acciones como sospechosas y envió una alerta de seguridad esa misma mañana. La alerta se abrió, pero no se cambió la contraseña ni se cerraron las demás sesiones, así que los atacantes siguieron adentro. Durante siete días no hicieron nada visible.

Un lunes usaron la sesión robada desde otro servidor para enviar desde su cuenta una "invitación especial a una cena" a más de 1,400 contactos, en cinco mensajes. El enlace instalaba un programa de control remoto en la computadora de quien lo ejecutara. También escondieron los rebotes y las respuestas para que no se diera cuenta. Se detuvo cuando cambió su contraseña esa tarde.

La cadena se cerró sobre sí misma: algunos de esos 1,400 destinatarios trabajaban en la misma escuela de donde salió el primer correo. Cada buzón hackeado se convierte en el remitente de confianza de la siguiente ronda.

Qué lo habría detenido

Dos cosas habrían detenido este ataque por sí solas. Todo lo demás reduce el riesgo.

Llaves de acceso (passkeys) o llaves de seguridad para iniciar sesión. Verifican que el sitio sea realmente Google antes de responder, así que una página intermediaria no obtiene nada. Es lo que la agencia de ciberseguridad de Estados Unidos, CISA, llama MFA resistente al phishing. Google Workspace puede exigirlo a todos con la opción de verificación en dos pasos "Solo llave de seguridad", que acepta llaves de seguridad y passkeys.
Actuar ante la alerta el mismo día. Después de cualquier alerta de seguridad de Google: cambia la contraseña y cierra todas las sesiones (un administrador puede hacerlo por el usuario). Cambiar la contraseña fue justamente lo que terminó este ataque, una semana tarde.

Si las passkeys todavía no son opción, esto ayuda mucho:

Sesiones más cortas. En la Consola de administración, el control de sesiones de Google define cuánto dura una sesión web antes de pedir iniciar sesión otra vez. Una sesión robada que vence en un día sirve mucho menos que una que dura semanas.
Alertas que lleguen a un administrador. Envía las alertas de inicio de sesión sospechoso y de cambios en la verificación en dos pasos a quien puede actuar, no solo al usuario.
Un administrador de contraseñas. Solo completa tu contraseña de Google en el dominio real de Google. Si no la completa, tómalo como advertencia, no como falla.
Una regla del equipo para archivos compartidos. Si un correo te pide iniciar sesión para ver un archivo, aunque venga de alguien conocido, confírmalo antes por teléfono o mensaje.
Mira la barra de direcciones antes de iniciar sesión. La página de inicio de sesión de Google siempre está en accounts.google.com.

Si ya te pasó

Cambia la contraseña, cierra todas las sesiones y revisa qué pudo cambiar el atacante: correo y teléfono de recuperación, métodos de verificación en dos pasos, reenvío y filtros de correo, y aplicaciones conectadas. Luego revisa los registros de Gmail y de inicio de sesión en la Consola de administración para ver qué se envió y desde dónde, avisa a tus contactos y denuncia la página falsa y a su proveedor de hosting. Lo más probable es que tu computadora no esté infectada, pero vale la pena revisarla, porque algunas de estas campañas terminan instalando programas de control remoto.

Cómo ayuda Guanacos Tech

Investigamos robos de cuentas en Google Workspace desde los registros: cómo entraron, qué tocaron, quién recibió qué y si algún equipo se vio afectado. Después configuramos los controles de arriba, incluidas passkeys o llaves de seguridad sin dejar a nadie fuera, sesiones más cortas y alertas para el administrador, y le damos a tu equipo una guía de una página que sí van a leer.

Fuentes

Antes de poner DMARC en p=reject: la lista de remitentes externos

Guanacos Tech — Thu, 24 Sep 2026 12:00:00 +0000

Por qué p=reject falla en silencio con los remitentes que olvidaste

Imagina un despacho contable de 12 personas que termina lo que parece un despliegue de DMARC impecable. El correo de Workspace alinea, el boletín alinea, dos semanas de reportes se ven limpias y alguien pone la política en p=reject un viernes por la tarde. El lunes llama un cliente a preguntar dónde quedó su factura.

Nadie en el despacho vio un rebote. Un mensaje rechazado se rechaza en el servidor que lo recibe, y el aviso vuelve al remitente del sobre, que aquí es la plataforma de facturación, no una persona del despacho. El correo dejó de llegar en silencio, y la primera señal fue un cliente que pagó tarde.

Así falla la aplicación de la política. No rompe los remitentes que probaste. Rompe los que nadie anotó: la herramienta de facturación, el escáner del pasillo, los recordatorios del sistema de reservas, los avisos de envío de la tienda, la mesa de ayuda que responde como soporte@. Todos ponen tu dominio en el De y firman con el de otro, y mientras la política no tuvo dientes, los receptores los dejaron pasar.

Entonces el trabajo real antes de p=reject no es de DNS. Es un inventario. Esta es la lista que revisamos en el dominio de un cliente, en el orden en que la revisamos.

Arma el inventario de remitentes con los reportes agregados

Adivinar te da la lista de los remitentes que ya conocías. Los reportes agregados te dan la de verdad, incluida la herramienta que un área contrató el año pasado sin avisarle a nadie.

Deja la política en p=none con una dirección rua al menos dos semanas, y un mes completo si el negocio tiene ciclo mensual de facturación o planilla. Un remitente que dispara una vez al mes no aparece en una ventana de dos semanas, y ese suele ser justo el que duele.

Después lee los reportes y anota, para cada origen: de qué proveedor es la IP, si SPF pasó y alineó, si DKIM pasó y alineó, y cuántos mensajes fueron. La alineación es la columna que decide todo. El RFC 9989, publicado en mayo de 2026 como el reemplazo en vía de estándar del RFC 7489, mantiene la misma regla en el centro: SPF o DKIM tiene que pasar y coincidir con el dominio del De que se ve. Un proveedor cuyo SPF pasa con su propio dominio no aporta nada.

Y si leer XML crudo no es como quieres pasar la tarde, mejor pega un reporte.

Clasifica cada línea en tres grupos. Tuyo y alineado, que no necesita nada. Tuyo y sin alinear, que es el trabajo. Y lo que no es tuyo, un reenviador o alguien suplantándote, y ninguno debería detener el despliegue.

Qué configurar, categoría por categoría

Casi todo remitente sin alinear se arregla con uno de tres movimientos: que el proveedor firme DKIM con tu dominio, mover ese correo a un subdominio que le delegas, o hacer relay por tu propia plataforma de correo. Cuál aplica depende sobre todo de la categoría.

Plataformas de marketing y boletines

Son las más fáciles, porque toda plataforma seria soporta DKIM propio. Publica los registros CNAME que te da el proveedor, espera a que resuelvan y recién entonces activa la firma.

Hay un detalle que confunde a mucha gente. Varias plataformas, entre ellas Mailchimp y HubSpot, no te dejan mover el return path a tu dominio, así que SPF sigue marcando pase con el dominio de ellos y falla de alineación, para siempre. No pasa nada: solo un identificador tiene que alinear, y DKIM es el que tú controlas. No pegues el include: del proveedor en tu SPF pensando que arreglas esa columna, porque no puede alinear y te gasta una de tus diez consultas. Lo detallamos en por qué Mailchimp, HubSpot y Klaviyo fallan la alineación DMARC.

CRM y herramientas de ventas

Salesforce marca el patrón. Su documentación te hace crear una llave DKIM en Setup, eligiendo tamaño de llave RSA, con 2048 bits como recomendación, y un selector que identifica la llave. Lo que importa para DMARC es firmar con el dominio de tu De y no con el que trae el proveedor por defecto. Salesforce también documenta una opción de relay que enruta el correo saliente por tu propio servidor, Workspace o Microsoft 365 incluidos, que de paso resuelve la alineación de SPF porque el mensaje sí sale de tu plataforma.

Las herramientas que envían desde el buzón de cada persona con una conexión autorizada por lo general ya alinean, porque el mensaje de verdad sale de Workspace o de Exchange Online. Verifícalo en lugar de suponerlo.

Facturación, contabilidad y el resto del back office

Esta es la categoría que se rompe callada y la que cuesta dinero cuando se rompe. Facturas, estados de cuenta, avisos de planilla y recibos salen mensualmente, así que quedan sub representados en una ventana corta de reportes, y quien los recibe es un cliente que no va a llamar para avisar que la factura nunca llegó.

Se dan tres desenlaces comunes. La herramienta soporta DKIM propio, que es la respuesta limpia. Te deja poner tus credenciales SMTP, así que la apuntas a tu plataforma de correo y hereda tu autenticación. O no ofrece ninguna y envía como tú sin forma de firmar, y ahí lo honesto es cambiar la dirección del De: a un subdominio que le delegas a ese proveedor, o al dominio del proveedor con el nombre de tu empresa como display y un responder a que regresa contigo.

Tiendas, sistemas de reservas y sus apps de correo

Shopify representa bien a la categoría. Su centro de ayuda te hace agregar registros CNAME en tu proveedor de DNS para autenticar el dominio de envío, y pone dos condiciones sobre el propio registro DMARC: el dominio debe tener un solo registro TXT de DMARC, y no debe estar en alineación estricta, adkim=s o aspf=s. Si la verificación no pasa, Shopify reescribe el remitente visible a una dirección de su propio dominio, justo lo que querías evitar. Esos cambios de DNS pueden tardar hasta 48 horas.

Mesa de ayuda y buzones compartidos

Las mesas de ayuda responden como soporte@ u hola@ desde su propia infraestructura, así que necesitan el mismo tratamiento de DKIM que una plataforma de marketing. Lo que importa es la secuencia: agrega la dirección externa, publica los registros DKIM del proveedor, confirma que resuelven y solo entonces activa la firma en su consola. Al revés, el proveedor firma con una llave que no resuelve y el correo que antes pasaba empieza a fallar.

La impresora de la oficina y el sistema del negocio

La multifuncional del pasillo escanea a correo. También el panel de alarma, el software de respaldo, el punto de venta y aquel script que alguien escribió en 2021. Ninguno aparece en una lista de proveedores, todos usan tu dominio, y varios solo envían cuando algo anda mal, el peor momento para que el mensaje sea rechazado.

Para los que están en Google Workspace, Google documenta el envío desde una impresora, un escáner o una app mediante el servicio de relay SMTP, que pasa el mensaje por Google para que salga con tu firma DKIM en lugar de salir sin nada. Los dispositivos se autentican con credenciales o por dirección IP, la opción práctica para una impresora. Tu registro SPF necesita autorizar a Google, cosa que casi seguro ya hace:

ejemplo.com.  TXT  "v=spf1 include:_spf.google.com ~all"

En Microsoft 365 la trampa está un paso antes. La documentación de Microsoft es explícita en que la firma DKIM hay que configurarla para tu dominio propio, de modo que el dominio que firma alinee con el del De. Un tenant que nunca lo hizo firma con su dominio .onmicrosoft.com, y entonces el correo de Exchange Online pasa SPF, pasa DKIM y aun así falla DMARC. Si tus reportes muestran rangos de Microsoft fallando alineación mientras todo se ve configurado, casi siempre es por eso.

Cuando no hay forma de autenticar un dispositivo, dale su propio subdominio y deja limpio el dominio principal. Un escáner que envía como escaneos@avisos.ejemplo.com es un problema contenido. El mismo escáner como escaneos@ejemplo.com es razón para no aplicar la política.

Dos límites que muerden durante el inventario

Cada proveedor que agregas te tienta a pegar otro include: en SPF, y el registro tiene techo. El RFC 7208, sección 4.6.4, limita una evaluación de SPF a diez mecanismos que consultan DNS, y pasarse produce un PermError, que reprueba SPF para todos los mensajes sin importar de dónde vengan. Así que la regla de trabajo mientras recorres el inventario: DKIM es como alineas a un tercero, SPF es para los pocos sistemas que de verdad hacen relay de tu correo, y un include sale del registro la misma semana que sale el proveedor. Si ya estás sobre el límite, volver a bajar de diez consultas va antes que cualquier cambio de política.

Una semana en quarantine y después reject

Cuando cada línea esté alineada o movida a propósito fuera del dominio, aprieta en dos pasos y no en uno.

La perilla de porcentaje que quizá recuerdas de guías viejas ya no está. El RFC 9989 quitó la etiqueta pct y puso en su lugar una bandera simple de prueba, t=y, que reporta sin aplicar. Los registros que traen pct siguen siendo válidos, pero un porcentaje escalonado ya no es base para un despliegue. Escalona con el valor de la política.

_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@ejemplo.com; adkim=r; aspf=r"

Quarantine convierte una falla dura en una suave. Lo que se te haya pasado cae en la carpeta de spam en lugar de desaparecer, y quien lo recibe todavía puede encontrarlo y avisarte. Revisa los reportes a diario esos días, y si el negocio tiene corrida de facturación, agenda la semana para que caiga adentro.

Después pasa a aplicar:

_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@ejemplo.com; adkim=r; aspf=r"

Deja la dirección rua en el registro de forma permanente. El inventario es una foto, y alguien va a comprar una herramienta nueva en marzo. Si los subdominios entran en tu plan, la etiqueta sp decide qué les pasa, y eso tiene sus propias trampas.

Vale la pena saberlo antes de poner fecha: un dominio que envía más de 5,000 mensajes al día a Gmail ya tiene que publicar una política DMARC, mantener su tasa de quejas de spam por debajo del 0.3 por ciento y soportar la baja en un clic en el correo masivo, que Google aplica desde febrero de 2024. Llegar a p=reject va más allá de eso, y el inventario es lo que lo hace seguro y no valiente.

Cómo ayuda Guanacos Tech

Hacemos esto como un trabajo acotado para empresas pequeñas y medianas de Norteamérica y Latinoamérica, en inglés y en español: un mes de reportes agregados, el inventario de remitentes, la alineación arreglada proveedor por proveedor, una semana de quarantine y después los reportes vigilados durante las primeras semanas de aplicación, para que un remitente olvidado sea una llamada y no una factura perdida. La sorpresa casi nunca es alguien suplantando. Casi siempre es una herramienta que compró un área y nadie más conocía.

Empieza por tu cuenta si quieres: el analizador DMARC y el diagnóstico de correo son gratis y no piden cuenta. Y si prefieres delegarlo, nuestra página de consultoría de entregabilidad de correo explica cómo corre el trabajo, y con una llamada de 30 minutos leemos tu registro y te nombramos los remitentes que están entre tú y p=reject. Documentación de proveedores citada aquí consultada el 24 de septiembre de 2026.

Fuentes

¿Por qué mis correos llegan a spam? Diagnóstico de 10 minutos antes de pagarle a alguien

Guanacos Tech — Thu, 24 Sep 2026 12:00:00 +0000

Imagina una correduría de seguros de 14 personas que envía unos 300 correos al día: avisos de renovación, pólizas, alguna cotización. Nada cambia de su lado. Un cliente avisa que nunca le llegó la renovación y, una semana después, otro la encuentra en la carpeta de spam. Alguien en la oficina empieza a copiarse a su propio Gmail en cada envío para probar, lo cual no demuestra nada, porque el correo que te mandas a ti mismo casi siempre entra.

Esa llamada nos llega casi todas las semanas y abre con la misma frase: nuestros correos llegan a spam. Esa sola frase cubre al menos tres problemas distintos, y la solución de uno no hace nada por los otros dos. Antes de pagarle a alguien, a nosotros incluidos, puedes distinguirlos en unos diez minutos con herramientas gratuitas y un correo que de verdad haya sido filtrado. Este es el orden en el que trabajamos nosotros en una primera llamada.

Tres problemas distintos que por fuera se ven iguales

El filtrado es un veredicto, no una causa. Ese veredicto sale de tres entradas independientes, y saber cuál está fallando define todo lo que hagas después.

Autenticación. El servidor que recibe no puede comprobar que el mensaje salió de verdad de tu dominio. Es un problema de DNS. Es el más barato de arreglar y, con diferencia, el más común en empresas pequeñas.
Reputación. Tus registros están bien, pero el dominio o la máquina que envía por ti arrastra un historial: quejas, un salto de volumen, una IP de hosting compartido cargando el tráfico de otros. Ningún cambio en DNS limpia esto. Solo lo hacen el tiempo y un mejor comportamiento de envío.
Contenido e higiene de lista. La gente marca el correo como spam, la lista tiene direcciones que dejaron de existir hace años, o el envío masivo no trae una baja que funcione. Este se esconde detrás de los otros dos y sobrevive a ambos.

Las directrices para remitentes de Google fijan el piso para los tres. Se espera que todo remitente configure SPF o DKIM, que el dominio o la IP que envía tenga registros DNS directos e inversos válidos (PTR), que se transmita sobre TLS y que la tasa de spam que reporta Postmaster Tools se mantenga por debajo del 0.30%. Quien empuja más de 5,000 mensajes al día a cuentas de Gmail tiene que cumplir los tres, SPF y DKIM y DMARC, y ofrecer baja en un clic en el correo de marketing y de suscripción. Directrices consultadas el 24 de septiembre de 2026.

Por debajo de 5,000 al día no estás exento, simplemente te miden con menos reglas. El techo de 0.30% de quejas y el requisito de autenticación aplican para todos.

Minutos 1 a 3: mira qué publica tu dominio

Empieza por el DNS, porque es la única parte de esto donde una respuesta equivocada es inequívoca. Buscas tres registros. Un conjunto sano en una pyme se ve más o menos así:

ejemplo.com.                    TXT   "v=spf1 include:_spf.google.com ~all"
google._domainkey.ejemplo.com.  TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.ejemplo.com.             TXT   "v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com"

Cuatro fallas explican casi todo lo que encontramos en esta etapa.

Dos registros SPF. Uno se agregó para el hosting del sitio y otro para la plataforma de correo, con años de diferencia. Dos registros v=spf1 en el mismo nombre son un error permanente y el receptor deja de evaluar. Debe haber exactamente uno, con todos los remitentes adentro.
SPF pasado del límite de consultas. El RFC 7208, sección 4.6.4, limita cada evaluación a diez mecanismos que consultan DNS. Cada include que agregaste para un CRM, un sistema de facturación y una plataforma de boletines gasta parte de ese presupuesto, y varios se expanden internamente en más includes. Pasando de diez, el registro devuelve PermError y en la práctica deja de protegerte.
DKIM que no existe. En Google Workspace, la clave DKIM se genera en la consola de administración y después se publica como registro en el DNS. Muchos tenants completan la primera mitad y nunca hacen la segunda, así que nunca se firma nada.
Sin DMARC. Sin él no tienes reportes, o sea que no tienes la lista de quién envía con tu dominio, que es la lista de la que dependen todas las decisiones que vienen después.

Pasa tu dominio por la revisión de abajo antes de seguir leyendo. Toma unos segundos y te dice si los siguientes seis minutos van de autenticación o de otra cosa.

Minutos 4 a 6: lee un correo que sí haya sido filtrado

Registros que se ven correctos en el DNS pueden fallar igual en un mensaje real, y solo el mensaje te lo dice. Busca uno que haya caído en la carpeta de spam de alguien, de preferencia en Gmail. Pídele a esa persona que lo abra, use el menú de tres puntos y elija Mostrar original, y que te mande todo el texto. Google documenta esta ruta en su página sobre rastrear un mensaje con su encabezado completo.

En lo que te llegue, busca la línea que empieza con Authentication-Results. Ahí está el veredicto del receptor:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@mail.proveedorcrm.com ...) smtp.mailfrom=mail.proveedorcrm.com;
       dkim=pass header.i=@proveedorcrm.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ejemplo.com

Ese ejemplo es el hallazgo más frecuente en nuestras auditorías y explica por qué tanta gente concluye que sus registros están bien. SPF pasa. DKIM pasa. DMARC falla igual, porque DMARC no pregunta si SPF o DKIM pasaron para alguien. Pregunta si el dominio del From: visible coincide con el dominio que autenticó SPF o DKIM. La documentación de DMARC de Google llama a esto alineación, y es el paso que casi toda plataforma externa de envío deja mal hasta que lo configuras a propósito.

Así que lee esas líneas en este orden: primero dmarc=, luego header.from=, y después si smtp.mailfrom o el dominio d= de DKIM coinciden con él. Si prefieres no pelear con encabezados crudos, pégalos en nuestro analizador de cabeceras y te señala la parte que falla. Si sale dmarc=pass y aun así el correo fue filtrado, la autenticación no es tu problema y puedes dejar el DNS en paz.

Minutos 7 a 9: Postmaster Tools y qué significa un panel vacío

Google Postmaster Tools es la única vista que Google te da de cómo trata Gmail a tu dominio. Es gratis y cuesta un registro de verificación. Sus paneles reportan sobre el correo saliente hacia cuentas personales de Gmail, con tasa de spam, autenticación, errores de entrega, estado de cumplimiento y el feedback loop.

Dos límites importan antes de sacar conclusiones. El correo entregado al buzón de Google Workspace de un cliente no es lo que miden estas gráficas, y nada fuera de Google aparece, así que Outlook y los filtros corporativos siguen siendo invisibles aquí.

Y luego está el resultado que más confunde: sin datos. Google dice de forma explícita que la mayoría de los paneles muestran datos solo cuando hay un volumen diario considerable, del orden de cientos de mensajes, desde tus dominios de autenticación, y que puede retener datos en días de volumen bajo para proteger la privacidad de los usuarios. Algunos paneles necesitan que tu correo esté firmado con DKIM para mostrar algo.

Para la correduría de 14 personas con 300 correos al día, repartidos entre Gmail, Outlook y destinatarios corporativos, un panel vacío es el resultado esperado. No es un veredicto sobre tu dominio ni evidencia de un castigo. Si tienes volumen suficiente para ver números, la tasa de spam es la que hay que vigilar, por debajo del techo de 0.30% y ojalá muy por debajo. Nuestra guía para configurar Postmaster Tools recorre cada panel.

Si ya tienes reportes DMARC activos, este también es el momento de abrir las últimas dos semanas en nuestro analizador de reportes DMARC. Esos XML listan cada sistema que envía con tu dominio, incluidos los que nadie recordaba.

Minuto 10: decide qué es esto en realidad

Ya tienes tres respuestas. Ubícalas en uno de estos casos.

El DNS muestra un hueco y el encabezado muestra dmarc=fail. Es autenticación. Es un trabajo de DNS con un final claro, y un administrador competente lo termina en una tarde. Publica un solo registro SPF que cubra a todos los remitentes, firma con DKIM, publica DMARC en p=none con una dirección de reportes y lee reportes dos semanas antes de apretar nada.
Todo pasa, el correo sigue cayendo en spam y viene empeorando desde hace semanas. Es reputación o contenido. Revisa cambios de volumen, qué enviaste justo antes de que empezara y qué tan vieja es la lista. Nada en el DNS mueve esto.
Los mensajes son rechazados de plano, no filtrados. Es otro problema, y el texto del rebote lo nombra. Nuestro post sobre distinguir el 550 5.7.1 del 5.7.26 en Gmail lo resuelve en un minuto.

Dos señales de que conviene pedir ayuda en lugar de seguir solo. Primera: más de un puñado de sistemas distintos envían con tu dominio, un CRM, una plataforma de facturación electrónica, una mesa de ayuda, una herramienta de boletines, una tienda en línea, el escáner de la oficina. Cada uno necesita su propio trabajo de alineación, el orden importa, y el SPF se queda sin consultas mucho antes de que tú te quedes sin remitentes. Segunda: DMARC ya está en p=quarantine o p=reject y hay correo desapareciendo. Esa combinación trae fecha límite, porque cada día en modo estricto es un día de correo legítimo descartado en silencio.

Tres cosas que no debes hacer, y nos han llamado a deshacer las tres. No registres un dominio nuevo para escapar del problema, porque un dominio nuevo no tiene reputación alguna y el viejo se queda roto. No subas el volumen para probar que el correo funciona. No pagues una suscripción a un panel que reporta un puntaje de entregabilidad sin decirte qué registro cambiar, porque un puntaje no es un diagnóstico.

Cómo ayuda Guanacos Tech

La mayor parte de un proyecto de entregabilidad es la parte poco vistosa de la lista de arriba: nombrar cada sistema que envía con el dominio, arreglar la alineación remitente por remitente, mantener el SPF dentro de su presupuesto de consultas y quedarnos en los reportes DMARC lo suficiente para saber que el arreglo aguantó antes de subir la política. Si estos diez minutos te dijeron que es autenticación, es muy posible que lo termines tú, y ese es un buen resultado. Si te dijeron que hay nueve remitentes y un SPF que ya devuelve error, nuestra consultoría de entregabilidad de correo existe justo para eso. Lleva lo que encontraste, un correo rebotado y tu dominio a una llamada de 30 minutos y saldrás sabiendo cuál de los tres problemas tienes y qué cuesta resolverlo.

Fuentes

Error 550 de Gmail: ¿el tuyo es 5.7.1 (reputación) o 5.7.26 (autenticación)?

Guanacos Tech — Wed, 23 Sep 2026 12:00:00 +0000

Un mismo número, tres problemas distintos

Imagina un estudio de diseño de nueve personas que envía propuestas desde su propio dominio. Un lunes por la mañana nada llega a los clientes que usan Gmail, y la persona de administración te reenvía un mensaje devuelto con un 550 adentro. Ese número solo no dice casi nada: significa que Gmail rechazó el mensaje de forma definitiva y no lo va a reintentar. Lo útil es el código de estado que viene después, y la frase que Gmail le pegó a ese código.

Tres códigos explican casi todos los rechazos de Gmail que nos tocan. 5.7.1 es un veredicto de reputación. 5.7.26 es un veredicto de autenticación. 5.7.25 habla de la máquina que abrió la conexión, no de tu dominio. En el cliente de correo se ven igual, y detrás hay trabajos completamente distintos. Por eso lo primero que hacemos en estos casos es leer el rebote con calma, antes de que alguien abra el panel de DNS.

Lee el rebote: las tres líneas que importan

Pide el mensaje devuelto completo, no una captura de la primera línea. En Gmail el texto completo está detrás del enlace de detalles del error, o en Mostrar original. En Outlook está en el informe de entrega. Tres cosas definen todo lo que sigue.

El código de estado. Los dígitos justo después del 550: 5.7.1, 5.7.26 o 5.7.25. Gmail corta las explicaciones largas, así que verás el código repetido al inicio de cada línea como 550-5.7.26. Ese guion indica que la línea continúa, no que sea otro código.
La frase que Gmail le puso. Dos rechazos pueden compartir código y necesitar arreglos distintos. Es justo lo que pasa con 5.7.26. Copia la frase textual antes de que alguien la resuma.
Qué nombra esa frase. Un dominio, una dirección IP, o las dos. "The sending domain" y "the sending IP address" apuntan a responsables distintos, y muchas veces a empresas distintas.

Un rebote 5.7.26 del primer tipo se ve parecido a esto:

550-5.7.26 This mail is unauthenticated, which poses a security risk to
550-5.7.26 the sender and Gmail users, and has been blocked. The sender
550-5.7.26 must authenticate with at least one of SPF or DKIM.

Y un 5.7.1 se ve más bien así:

550-5.7.1 Gmail has detected that this message is likely suspicious
550-5.7.1 due to the very low reputation of the sending domain.

Los mismos tres dígitos adelante, dos proyectos sin relación atrás.

5.7.1 es reputación, 5.7.26 es autenticación, 5.7.25 es el servidor que envía

5.7.26, autenticación. Gmail no pudo ligar el mensaje con el dominio que aparece en el De. O no pasó nada, o lo que pasó corresponde a otro dominio distinto al que ve quien recibe. Es un problema de configuración y DNS, y es el más rápido de cerrar de los tres.
5.7.1, reputación. Gmail sí evaluó el mensaje y el historial del remitente no le gustó. Lee bien la frase: "very low reputation of the sending domain" habla de tu dominio; "very low reputation of the sending IP address" habla de la máquina o del grupo de IPs por donde sales, que en hosting barato compartes con desconocidos. Ninguno de los dos se arregla editando un registro.
5.7.25, el DNS del servidor que envía. La IP pública que se conectó no tiene DNS inverso utilizable. Las guías para remitentes de Google piden que la IP de envío tenga un registro PTR que resuelva a un nombre de host, y que ese nombre tenga un registro A o AAAA que resuelva de regreso a la misma IP. Solo quien es dueño de la IP puede publicarlo, y casi nunca eres tú.

Vale la pena separar desde ya las dos frases que comparten el código 5.7.26, porque te mandan a lugares distintos. La citada arriba, "must authenticate with at least one of SPF or DKIM", significa que no pasó nada. La otra, "Unauthenticated email from ejemplo.com is not accepted due to domain's DMARC policy", significa que tu propia política publicada le dijo a Gmail que rechazara el mensaje, porque lo que sí autenticó no estaba alineado con el dominio del De. La segunda versión aparece sobre todo en empresas que pasaron a p=reject antes de terminar el inventario de sistemas que envían con su dominio.

Si el tuyo es 5.7.26: primero autenticar, luego alinear

Hazlo en este orden. Cada paso se puede comprobar, y eso importa cuando hay tres personas adivinando al mismo tiempo.

Identifica qué sistema envió el mensaje. No "nuestro correo". El servidor de correo, el CRM, el sistema de facturación, el formulario del sitio, el escáner del pasillo. Cada uno autentica por su cuenta, y el que falló suele ser el que nadie recuerda haber activado.
Revisa con qué identidad tiene permiso de enviar. Si sale por tu proveedor de correo con un buzón real y su contraseña, normalmente ya está cubierto. Si se conecta a Gmail desde sus propios servidores, necesita un include de SPF que los nombre o su propia llave DKIM publicada en tu dominio.
Busca alineación, no solo un pase. Para mensajes que van directo a cuentas personales de Gmail, Google pide que el dominio organizacional del encabezado De coincida con el dominio de SPF o con el de DKIM. Con uno de los dos basta. Un proveedor que firma con su propio dominio y pasa SPF en su propia ruta de retorno igual puede producir un 5.7.26 en tu De, y su soporte te dirá que la autenticación está bien, porque desde donde ellos miran lo está.
Envía un mensaje real y lee los encabezados. Una herramienta de consulta te dice qué dice tu registro hoy. Los encabezados de un mensaje que Gmail aceptó te dicen qué hizo Gmail con él. Esa es la comprobación que cierra el caso.

El recorrido completo, con la variante de la política DMARC, está en nuestra guía de 5.7.26. Una advertencia antes de agregar un include: el RFC 7208 limita SPF a diez consultas DNS, y un proveedor más puede empujar un registro largo a PermError, que tumba la autenticación de todos los mensajes a la vez. Cuenta primero las consultas.

Si el tuyo es 5.7.1: reputación, y ningún registro lo resuelve

Este es el lento. Hay gente que pierde semanas tratándolo como problema de DNS, publicando un registro nuevo cada día y viendo que nada cambia. La reputación es un promedio de cómo reacciona la gente a tu correo, así que se mueve al ritmo de Gmail.

Define si es el dominio o la IP. El rebote lo dice. Si nombra la IP y sales por hosting compartido, estás cargando el comportamiento de otros, y el arreglo real es dejar de enviar por ahí.
Verifica el dominio en Postmaster Tools y léelo. Los paneles muestran reputación de dominio y de IP junto con tasas de autenticación y de errores de entrega para el dominio que verificaste. Es la única vista de lo que piensa Gmail que no es adivinanza. Nuestra guía de configuración explica para qué sirve cada panel.
Deja la autenticación impecable de todos modos. En un dominio que todavía falla SPF o DKIM la recuperación ni siquiera empieza. Autenticar es el piso, no el arreglo.
Corta lo que lo causó. Un salto de volumen, una lista comprada, un formulario sin confirmación, un buzón comprometido enviando de madrugada. Google pide mantener la tasa de spam reportada en Postmaster Tools por debajo de 0.1 por ciento y nunca llegar a 0.30 por ciento, guía que revisamos el 23 de septiembre de 2026. Las quejas a ese nivel no se promedian rápido.
Después reconstruye despacio. Volúmenes chicos hacia gente que responde, sostenidos durante semanas. No hay botón, y quien te ofrezca uno te está vendiendo algo.

La guía de 5.7.1 tiene el orden que seguimos en un caso de reputación en curso, incluido qué hacer cuando la IP no es tuya.

Si el tuyo es 5.7.25: el arreglo es de alguien más

El DNS inverso lo publica quien es dueño de la IP, así que el panel del registrador es el lugar equivocado. Si envías por Google Workspace, Microsoft 365 o una plataforma de correo normal, sus direcciones ya tienen PTR, y un 5.7.25 suele significar que hay algo más retransmitiendo: un servidor viejo de la oficina, un VPS con el formulario de contacto del sitio, un equipo con una configuración SMTP de otra década. Busca la IP en el rebote, averigua quién la opera y pídele un PTR que resuelva a un nombre de host cuyo registro A o AAAA apunte de regreso a la misma dirección. En un VPS eso es un ticket de soporte. En una máquina debajo de un escritorio suele ser razón suficiente para dejar de enviar directo y retransmitir por el proveedor de correo.

Qué hacer mientras el cambio se propaga

Las horas siguientes al cambio son donde se arruina el buen trabajo.

No sueltes la cola atorada de golpe. Unos cientos de reintentos contra un proveedor que te acaba de rechazar se leen exactamente como se ven.
Espera a que pase el TTL del registro antes de probar. Si el TTL era de cuatro horas, la respuesta que obtienes en cinco minutos es la vieja.
Prueba con un solo mensaje a una dirección de Gmail tuya y lee sus encabezados. Que llegue a tu bandeja no alcanza como prueba.
Llama a quien está esperando algo urgente. Una llamada corta gana contra una propuesta detenida en una cola.
No registres un dominio nuevo para escapar del problema. Un dominio recién creado no tiene reputación, uno parecido al tuyo genera más sospecha, y los dos dejan el original roto.

Cómo ayuda Guanacos Tech

Casi todos estos casos llegan con una sola frase: nuestro correo está rebotando. Una hora después suelen ser tres cosas distintas, y una de ellas venía fallando en silencio desde hace meses. Leemos el rebote, listamos cada sistema que envía con el dominio, arreglamos la autenticación remitente por remitente, comprobamos con mensajes reales y no con herramientas de consulta, y nos quedamos con los reportes DMARC el tiempo suficiente para saber que aguantó. Si ya tienes un rebote en la mano, nuestra consultoría de entregabilidad de correo empieza ahí. Lleva el mensaje devuelto a una llamada de 30 minutos y sales sabiendo cuál de los tres problemas tienes y qué va a costar cerrarlo.

Fuentes

Migrar de Microsoft 365 a Google Workspace: la lista que seguimos, en orden

Guanacos Tech — Wed, 23 Sep 2026 12:00:00 +0000

La semana siguiente a la mudanza es la que manda

Digamos que una distribuidora de 22 personas lleva años en Microsoft 365, desde que lo configuró alguien que ya no trabaja ahí. Decidir el cambio a Google Workspace toma una tarde. La mudanza también sale bien, durante una semana más o menos. Después empiezan las llamadas: la dirección de contabilidad que ya nadie puede abrir, y las notas de entrega del sistema de bodega que ahora caen en spam, porque nadie lo contó como remitente.

Nada de esto es difícil. Sale mal porque los pasos se hacen en el orden equivocado. Se copia el correo antes de ordenar las cuentas, o se cambia el registro MX antes de que alguien liste quién más manda correo con el dominio. Este es el orden que seguimos en una migración para una empresa pequeña o mediana, y lo que revisamos en cada paso.

Paso 1: decide qué se mueve y qué se queda

Antes de abrir cualquier herramienta armamos cuatro listas con el cliente en una sola página.

Buzones, separados en tres: personas reales, direcciones compartidas que abren varios, y direcciones que solo envían (alertas, facturas, avisos de formularios).
Calendarios y salas, incluyendo quién agenda en nombre de quién.
Archivos, separando el contenido personal de OneDrive de los sitios de SharePoint que el equipo de verdad usa. Siempre hay un sitio que nadie toca desde hace tres años.
Grupos y alias: listas de distribución, la dirección que reenvía a dos personas, la que reenvía a alguien que ya se fue.

Después va la lista más corta y más útil: lo que no se mueve. Correo archivado bajo una política de retención, un buzón atado a una aplicación del negocio que nadie va a tocar este trimestre, el historial de chat. Google publica una matriz de productos de migración que dice cuál de sus herramientas cubre cada origen y cada tipo de dato, y la respuesta cambia para correo, para archivos y para un Exchange viejo instalado en la oficina. La leemos al planificar.

Paso 2: primero las cuentas, después el DNS

Todas las cuentas de Workspace se crean antes de tocar los registros del dominio. La propia guía de Google para cambiar registros MX lo pone de primero: a la hora en que el correo empiece a llegar a Google, cualquier dirección sin cuenta detrás no tiene a dónde ir.

Tres detalles ahorran la mayor parte de los dolores de cabeza.

Que las direcciones coincidan exactamente. El servicio de migración de datos empareja usuarios entre las dos cuentas buscando direcciones parecidas. Cada dirección que no coincide se vuelve un emparejamiento manual, y con el tiempo, un buzón que alguien olvidó.
Decide en qué se convierte cada buzón compartido. Google tiene dos formas para esto y se comportan distinto. Un grupo de Google configurado como Bandeja de entrada colaborativa permite que un equipo reciba en una sola dirección y se asigne conversaciones. Una cuenta delegada es un buzón que otras personas abren desde su propio Gmail, y en una cuenta de trabajo admite una cantidad alta de delegados. Las colas de soporte y ventas normalmente piden el grupo. Una dirección con años de historia que responde casi siempre la misma persona normalmente pide delegación.
Resuelve los accesos de administración temprano. Conectar los dos entornos requiere un superadministrador del lado de Workspace y un administrador global del lado de Microsoft 365. En equipos pequeños esa segunda cuenta suele estar en manos de quien montó todo hace años, y recuperarla toma más tiempo que la migración.

Paso 3: el correo, el traslape y la hora del MX

Baja el TTL del registro MX por lo menos un día antes. Google recomienda 3600, una hora, suficientemente corto para que un error en el corte cueste una hora y no un día. El TTL actual manda sobre qué tan rápido surte efecto el cambio que hagas ahora, así que bajarlo va primero.

Copia los datos antes del corte, no después. El servicio de migración de datos copia el correo y el calendario de Exchange Online a las cuentas de Workspace, hasta con 250 usuarios a la vez, así que una empresa más grande lo corre por tandas. La gente sigue trabajando en Microsoft 365 mientras corre.

Durante el traslape hay dos arreglos que conviene distinguir. La entrega dual deja el registro MX apuntando al sistema viejo, que entrega en sus propios buzones y después reenvía todo a Google. La entrega dividida apunta el MX a Google, y Gmail enruta a ciertos destinatarios hacia el otro sistema. Google recomienda Gmail como servidor principal, y dejar el servidor anterior como principal solo durante un piloto o migración, para pasar a Gmail solo cuando todos estén listos.

El corte en sí es un registro. El valor de Workspace es un solo host, y algunos registradores esperan la prioridad y el destino en el mismo campo:

example.com.   3600   IN   MX   1 smtp.google.com.

Si el dominio se configuró en Workspace antes de 2023 puede seguir con los valores aspmx anteriores, y la posición de Google es que los registros que funcionan no necesitan cambiarse. Agenda el cambio para una noche o un fin de semana, cuando perder una hora cuesta menos. Google dice que los registros MX nuevos pueden tardar hasta 72 horas en reconocerse y da hasta 48 horas de propagación, así que nadie debería juzgarla por los primeros diez minutos. Cuando se asiente, corre una pasada delta para recoger el correo que llegó al sistema viejo durante el cambio.

Paso 4: autenticación mientras los dos sistemas todavía envían

Este es el paso que se salta, y el que produce las quejas de spam dos semanas después. Mientras las dos plataformas envían con el dominio, las dos tienen que estar autorizadas, y en cuanto una deja de enviar, sale.

SPF es un solo registro, una sola cadena v=spf1, con los dos includes adentro:

example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"

Google publica sus rangos de envío detrás de _spf.google.com y Microsoft publica los suyos detrás de spf.protection.outlook.com, porque ambos envían desde direcciones que cambian. Dos includes más un CRM más una plataforma de facturación es justo donde los dominios se pasan del límite: la evaluación de SPF se detiene a las diez consultas DNS y devuelve permerror, como exige el RFC 7208, y un permerror no es un pass. Cuéntalas antes del corte.

DKIM pide trabajo del lado de Google, porque no firma de entrada. La llave se genera en la consola de administración, dentro de la configuración de Gmail, se publica como registro TXT en el proveedor de DNS y después se activa la autenticación. Hay dos tiempos que importan. Después de activar Gmail para la organización, la llave no se puede generar durante 24 a 72 horas. Y una vez publicado el registro, la autenticación puede tardar hasta 48 horas en empezar a funcionar. Mete los dos en el calendario y no los descubras la mañana del corte. Deja los registros DKIM de Microsoft en su lugar mientras Microsoft siga enviando: usan selectores distintos y no chocan entre sí.

Deja DMARC en p=none mientras la lista de remitentes siga moviéndose, y lee los reportes. Endurecer la política la misma semana del corte significa que el único sistema que olvidaste empieza a fallar justo cuando nadie puede saber cuál cambio lo causó.

Al resultado le aplican dos conjuntos de reglas. Desde febrero de 2024, Google le pide a todo remitente, a cualquier volumen, SPF o DKIM y DNS directo e inverso válidos, y a quienes envían más de 5,000 mensajes diarios a cuentas de Gmail les pide SPF y DKIM juntos, un registro DMARC, alineación con el encabezado From y una tasa de spam por debajo de 0.30% en Postmaster Tools. Microsoft publica sus propios requisitos para remitentes de alto volumen hacia sus servicios de consumo, también trazados en 5,000 mensajes diarios desde el mismo dominio del From, con SPF, DKIM y DMARC en p=none o más estricto, y dice que el correo que no cumple se enruta primero a Correo no deseado. La mayoría de empresas de este tamaño está muy por debajo de esos umbrales. El primer nivel les aplica igual.

Paso 5: calendario, delegaciones y salas

Los datos de calendario viajan junto con el correo en la misma corrida de migración. Lo que no viaja es el cableado alrededor. Los permisos de delegación, la asistente que agenda para dos directores, los recursos de sala y sus reglas de reserva: todo eso se reconstruye en Workspace, y reconstruirlo a propósito es mejor que recrear un arreglo que creció por accidente durante seis años. Lo agendamos para el día siguiente al corte del correo, con las personas que de verdad lo usan.

Las invitaciones enviadas desde el sistema viejo antes del cambio pueden comportarse raro después, casi siempre las reuniones recurrentes con historia larga. Para una llamada fija con un cliente, cancelarla y volverla a crear desde Workspace es más rápido que depurarla.

Paso 6: archivos, con la forma decidida primero

El servicio de migración de datos copia el contenido de OneDrive a Mi unidad de cada usuario, y los sitios de SharePoint Online a Drive. Google Workspace Migrate cubre casos más pesados y otros orígenes, la segunda razón para leer la matriz de productos temprano.

La decisión que importa no es cuál herramienta usas, es si una carpeta le pertenece a una persona o a la empresa. El contenido que cae en Mi unidad de alguien se va con esa persona. El contenido que le pertenece al negocio va en una unidad compartida. Decidir eso antes de la copia cuesta una reunión. Decidirlo después cuesta una segunda migración. Los permisos y los enlaces tampoco sobreviven la copia sin cambios, y los accesos externos merecen una pasada de revisión, porque una migración es el único momento en que todos están dispuestos a mirar.

Paso 7: da de baja Microsoft 365 sin romper tus envíos

No canceles las licencias la misma semana. Consérvalas el tiempo suficiente para comprobar que ya nada depende de ellas, y después trabaja hacia atrás.

Encuentra todo sistema que envía con el dominio: el software contable, el CRM, el formulario de contacto del sitio, la impresora de la oficina, las alertas de un servidor que alguien todavía mantiene.
Pasa cada uno a Workspace o a su propia ruta autenticada, de uno en uno, y confirma cada uno con un mensaje real y no con una herramienta de consulta.
Quita el include de Microsoft del SPF solo cuando ya nada envíe por Microsoft. Lo mismo con sus registros DKIM.
Lee los reportes agregados de DMARC durante al menos dos semanas después de mover el último remitente. Son el único lugar donde un remitente olvidado se anuncia antes de que lo haga un cliente.
Exporta lo que haya que conservar por razones legales o contables antes de cerrar el entorno viejo, y anota dónde quedó.
Hasta entonces, y solo entonces, endurece la política DMARC.

Cómo ayuda Guanacos Tech

Esto lo corremos como un solo proyecto con un orden de operaciones escrito, porque aquí las fallas caras son de secuencia y no de técnica. Eso significa el inventario primero, las cuentas después, un corte agendado a una hora que tu negocio pueda darse el lujo de perder, la autenticación abierta mientras las dos plataformas todavía envían, y los reportes vigilados hasta que el dominio quede limpio. Si estás evaluando el cambio, nuestra página de migración a Google Workspace tiene el alcance con el que trabajamos. Lleva tu número de buzones y la lista de cosas que envían correo en tu nombre a una llamada de 30 minutos, y sales con el orden, los riesgos y la semana en que debería hacerse.

Fuentes

Analizador de reportes DMARC gratis: sube el XML y sabe quién envía con tu dominio

Guanacos Tech — Tue, 22 Sep 2026 12:00:00 +0000

El registro DMARC se publicó hace un mes. La dirección rua apuntaba a un buzón real, y ese buzón ya acumula cuarenta archivos comprimidos. Cada uno trae una página de XML. Nadie abrió el segundo.

Así encontramos a la mayoría de las empresas pequeñas, y no es por descuido. El reporteo funciona. La lectura nunca empieza, porque el formato se escribió para máquinas. Imagina un despacho contable de doce personas: las facturas salen del sistema contable, las campañas de una herramienta de marketing y el correo diario de Google Workspace. Los reportes conocen a los tres remitentes. El equipo no.

No hace falta aprender el XML para sacar la respuesta. Este es el camino corto que seguimos en el dominio de un cliente: qué contiene el archivo, cómo convertir uno en una lista legible en un minuto, los tres veredictos que salen de esa lista y qué te cuesta cada uno si lo dejas pasar.

Qué trae el archivo en realidad

Un reporte agregado es un conteo, no una copia. El receptor agrupa todos los mensajes que vio diciendo ser de tu dominio por IP de origen y por resultado de autenticación, y te manda los totales del período. Sin asuntos, sin destinatarios, sin cuerpos de mensaje.

El formato tiene su propia especificación. El RFC 9990, publicado en mayo de 2026 en la vía de estándares, cubre el reporteo agregado; junto con el RFC 9989 y el RFC 9991 reemplazó al RFC 7489, que fue la referencia desde 2015. Según el RFC 9990, cada registro lleva un elemento row con la source_ip que conectó, un count de mensajes y un bloque policy_evaluated con la disposición y los resultados de DKIM y SPF, además de identifiers y auth_results.

Los reportes llegan porque tu registro publicado los pidió:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

La ayuda de administrador de Google Workspace lo dice sin rodeos: los reportes se envían normalmente una vez al día, por correo, a las direcciones del registro, y cada servidor que recibe correo de tu dominio manda el suyo. Por eso se llena el buzón. Un dominio con volumen real recibe reportes de proveedores de los que nunca oyó hablar. Apunta rua a un grupo, no a la persona que un día se va de la empresa.

Si quieres el XML explicado elemento por elemento, lo escribimos aparte: cómo leer un reporte agregado de DMARC. Para la decisión de hoy puedes saltártelo.

Convierte un reporte en una lista legible

Toma el adjunto más reciente del receptor al que le mandas más correo. Será un archivo .xml, .xml.gz o .zip. Súbelo o pégalo, y lee la lista que sale en lugar del marcado.

Nuestro analizador de reportes DMARC es gratis y no pide registro. Descomprime y procesa el archivo en tu navegador, en memoria, y te muestra la política que publicaste de verdad, el volumen total del reporte, tu tasa de aprobación DMARC, cada fuente de envío ordenada por volumen y, lo más importante, cuáles remitentes que parecen legítimos no están alineados y quedarían en cuarentena o rechazados el día que actives la aplicación de la política.

Las tres columnas que deciden todo

Sea cual sea la herramienta, estás leyendo tres cosas por fila.

Fuente. La IP que conectó, y casi siempre un dueño reconocible detrás: tu proveedor de correo, una plataforma de marketing, un hosting, algo que no ubicas.
Alineación de SPF. No solo si SPF pasó, sino si el dominio para el que pasó coincide con el dominio de tu encabezado From.
Alineación de DKIM. La misma pregunta aplicada a la firma del mensaje.

La distancia entre pasó y alineado es donde se pierde la tarde. El RFC 9989 define dos modos: la alineación relajada exige que los dos dominios compartan el dominio organizacional, y la estricta que sean idénticos. Las etiquetas adkim y aspf vienen en relajado por defecto, así que sin tocarlas tienes la versión indulgente y aun así no es automático.

DMARC pasa cuando al menos uno de SPF o DKIM pasa y está alineado. Las guías para remitentes de Google dicen lo mismo para el correo masivo hacia Gmail: hay que configurar SPF y DKIM, pero basta con que uno de los dos alinee. Una fila con SPF en pass y sin alineación es una fila que falla.

Los tres veredictos, y lo que cuesta cada uno

Alineado y pasando

Tu propio proveedor, casi siempre el bloque más grande de volumen. Nada que hacer. Anota el volumen para saber cómo se ve lo normal el mes que viene.

Legítimo, pero sin alinear

Aquí está el trabajo, y casi siempre es el mismo reparto: el sistema de facturación, el CRM, la mesa de ayuda, la herramienta de boletines, la tienda en línea, la impresora de la oficina que manda escaneos. Envían con tu dominio usando su propia autenticación, que pasa para el dominio de ellos y no para el tuyo.

El arreglo es remitente por remitente y vive en el panel del proveedor, no en un solo cambio de DNS. La mayoría de las plataformas ofrecen un return path personalizado o un par de registros CNAME de DKIM para publicar; a algunas conviene moverlas a un subdominio dedicado para que su reputación no se mezcle con tu correo diario. Cada remitente que dejes sin alinear es una categoría de correo que deja de llegar el día que endurezcas la política. Ese es el costo real de no leer los reportes.

Sin autenticar y ajeno a ti

IPs dispersas, conteos pequeños, ninguna autenticación que coincida con algo tuyo. Parte es suplantación y parte es ruido viejo de listas y rastreadores. Esto no se arregla en DNS, porque no hay nada tuyo que arreglar. Lo que lo detiene es la aplicación de la política, que es justamente el objetivo del ejercicio.

Las filas que te engañan una vez

El reenvío es la falsa alarma de siempre. Cuando un mensaje pasa por un alias o una lista de correo, el servidor que reenvía conecta desde su propia IP, así que SPF se rompe, mientras la firma DKIM suele sobrevivir intacta. La fila se ve alarmante y es un reenviador haciendo su trabajo. Si DKIM sigue alineado, DMARC sigue pasando.

Un reporte es la vista de un receptor sobre un día, no tu tráfico. Un cien por ciento de aprobación en un domingo tranquilo no dice nada. Y las filas de conteo bajo con IPs desconocidas merecen una mirada, pero rara vez un susto: la señal es el volumen.

De un archivo a un inventario de remitentes

El entregable de este ejercicio no es un reporte limpio. Es una lista accionable, y sale de una o dos semanas de reportes, no de uno.

Junta reportes de al menos una semana para que aparezcan los días tranquilos y las corridas de facturación mensual.
Anota cada fuente con su volumen, y marca si alinea SPF, si alinea DKIM o si no alinea ninguno.
Clasifica en tres cubetas: se queda como está, hay que alinear, y no es nuestro.
Dale un responsable y una fecha a cada remitente de la cubeta de alinear. Alguien tiene que entrar a ese panel del proveedor.

Esa lista es lo primero que construimos en cada proyecto de entregabilidad, porque no puedes endurecer con seguridad una política que no inventariaste.

Cuándo mover la política

Quédate en p=none hasta que cada remitente legítimo del inventario alinee por SPF o por DKIM. Luego pasa a cuarentena, observa una semana completa de reportes y solo entonces rechaza. El orden y el despliegue por porcentaje los explicamos en cómo pasar DMARC de p=none a p=reject.

Vale la pena saberlo si envías con volumen: desde el 1 de febrero de 2024, quien manda más de 5,000 mensajes al día a cuentas de Gmail debe tener SPF, DKIM y un registro DMARC, y mantener la tasa de spam que reporta Postmaster Tools por debajo del 0.3%. La política puede quedarse en none para cumplir ese mínimo, así que leer tus reportes no es cuestión de aprobar una auditoría. Es saber qué se rompe antes de decidir endurecer.

Cómo ayuda Guanacos Tech

Hacemos esto en dominios de clientes casi todas las semanas: juntar quince días de reportes, armar el inventario de remitentes, alinear los que valen la pena y mover la política por etapas observando qué cambia. Si tienes un buzón de XML sin abrir, o ya los leíste y quieres un segundo par de ojos antes de endurecer, de eso se trata nuestra consultoría de entregabilidad de correo. Una llamada corta basta para saber si tu inventario está limpio o si algo se rompería el día que actives la política.

Fuentes

Qué hace de verdad un consultor de Google Workspace en una empresa de 10 a 50 personas

Guanacos Tech — Tue, 22 Sep 2026 12:00:00 +0000

Una empresa de treinta personas casi nunca tiene departamento de TI. Tiene a la persona de administración que creó las cuentas de correo hace tres años, a un desarrollador que sabe la contraseña del DNS y a un fundador que es el único superadministrador y no recuerda el teléfono de recuperación de esa cuenta. Todo funciona hasta que alguien renuncia, roban una laptop o Gmail empieza a rebotar las facturas.

Ahí suele llegar la llamada. Esto es lo que realmente es el trabajo, en el orden en que lo hacemos, para que distingas una propuesta seria de una vaga y decidas qué partes conviene que se queden con tu propio equipo.

Las cinco situaciones que hacen que una empresa llame

Casi todos los proyectos de Google Workspace que hacemos empiezan en uno de estos cinco puntos.

Una migración. El correo se mueve desde Microsoft 365, un Exchange viejo, cPanel o Zoho, y nadie quiere ser quien pierda un mensaje el día del corte.
Un susto de seguridad. Alguien hizo clic donde no debía, un buzón empezó a mandar facturas a la lista de clientes, o un seguro pidió prueba de que la verificación en dos pasos está activa.
Un desorden de salidas. Una persona se fue hace cuatro meses y todavía es dueña de la mitad de los archivos compartidos, o borraron su cuenta a las carreras y ahora el contador necesita un correo que estaba ahí.
Licencias desperdiciadas. La factura creció más de lo que justifica la plantilla y nadie sabe qué cuentas siguen asignadas a gente que ya no está.
Nadie es dueño de la consola de administración. Esta es la silenciosa. Los ajustes están como vienen por defecto, o como los dejó un proveedor en 2021, y no hay un segundo superadministrador si el primero no aparece.

Las primeras cuatro son proyectos con fecha de cierre. La quinta suele ser la razón por la que pasaron las otras cuatro, y es la que vale la pena resolver bien.

Qué revisa la primera auditoría, punto por punto

La auditoría es una lectura, no un cambio. Pedimos una cuenta de administrador delegado, o nos sentamos con quien la tenga, y recorremos la misma lista siempre. Google publica una lista de verificación de seguridad escrita justo para organizaciones de una a cien personas, y es la base honesta de esta parte: cuentas de administrador, cuentas de usuario, aplicaciones, Calendar, Chat, Chrome, dispositivos, Drive, Gmail, Grupos, Sites y Vault. Muchos de los ajustes que recomienda ya vienen activados, que es la buena noticia. Los hallazgos casi siempre están en el puñado que no.

Estos son los puntos que producen hallazgos, en el orden en que los leemos:

Superadministradores. Cuántos hay, si cada uno es una persona identificable y si cada uno tiene verificación en dos pasos. La guía de Google es directa: las cuentas de superadministrador controlan el acceso a todos los datos de la empresa y de los empleados, así que deben usar verificación en dos pasos, las llaves de seguridad son el método más fuerte, y quien tenga una de esas cuentas debería entrar a ella solo para tareas de administración y usar una cuenta normal aparte el resto del tiempo. También debe haber más de uno. Una empresa con un solo superadministrador se queda fuera de su propio correo con un teléfono perdido, y solo un superadministrador puede generar códigos de respaldo para otro administrador, que es exactamente la ayuda que necesitas el día que pasa.
Información de recuperación. Teléfonos y correos de recuperación que pertenecen a gente que ya no trabaja ahí.
Unidades organizativas y grupos. Si el acceso se da por grupos o persona por persona. El acceso otorgado nombre por nombre es lo que convierte una salida en una semana de trabajo.
Compartición en Drive. Cuánto está compartido con cualquiera que tenga el enlace, y si los archivos críticos viven en unidades compartidas de la empresa o en el Mi unidad personal de alguien.
Acceso de aplicaciones de terceros. Este es el hallazgo que más sorprende. En Seguridad, luego Control de acceso y de datos, luego Controles de API, la consola lista las aplicaciones que ya tienen un nivel de acceso configurado y las que tus usuarios conectaron de verdad a sus cuentas. Cada una se puede dejar como de confianza, limitada a servicios no restringidos, restringida a datos específicos, o bloqueada, y una aplicación de terceros sin configurar queda bloqueada por defecto: la solicitud del usuario cae en una lista para que un administrador la permita o la bloquee. Los datos de una aplicación recién autorizada pueden tardar un día o dos en aparecer, así que una herramienta conectada esta mañana no se va a ver esta tarde.
Dispositivos. Si los teléfonos que cargan el correo de la empresa están inscritos, y si de verdad es posible borrarlos a distancia.
Licencias. Qué cuentas están asignadas, cuáles están suspendidas y se siguen pagando, y en qué plan está la suscripción.
Autenticación del correo. SPF, DKIM y DMARC del dominio, y cada sistema externo que envía con él: la plataforma de facturación, el CRM, la tienda en línea, la mesa de ayuda, el escáner de la esquina que manda PDF por correo.

Ese último punto es donde se cruzan una auditoría de Workspace y una de entregabilidad, y es el que el negocio siente primero, porque es el que manda las facturas a spam. Esa parte la puedes correr ahora mismo sobre tu dominio.

Qué arreglamos y qué te devolvemos

Un consultor que vale la pena busca volverse innecesario para el trabajo de rutina. El reparto que buscamos: nosotros tomamos lo que pide criterio y una mano una sola vez, tu gente se queda con lo que hay que hacer cada semana.

Lo que tomamos nosotros: la migración y el corte, la estructura de superadministradores y la delegación de roles para que no todo el que necesita reiniciar una contraseña necesite control total, grupos y unidades organizativas rehechos para que el acceso siga a un rol y no a un nombre, los valores por defecto de compartición, la revisión de aplicaciones de terceros, la inscripción de dispositivos, y la configuración completa de SPF, DKIM y DMARC incluyendo a los remitentes externos que nadie listó. Todo lo que necesita un plan de reversa.

Lo que te devolvemos, con un procedimiento escrito lo bastante corto para que alguien lo use de verdad: dar de alta y dar de baja a una persona, agregar a alguien a un grupo, aprobar o bloquear la solicitud de una aplicación nueva, leer el resumen mensual de DMARC y una revisión trimestral de licencias. Si un consultor quiere quedarse con esas cinco cosas, pregunta por qué.

Las salidas, la parte que casi todas las empresas hacen mal

Las salidas merecen su propia sección, porque los errores caros se cometen en los primeros diez minutos y casi siempre con prisa.

El orden importa. Para un empleado que se va, la guía de Google es reiniciar las cookies de inicio de sesión de esa persona para que las sesiones abiertas dejen de servir, revocar sus llaves de seguridad y borrar los datos de la empresa de sus dispositivos móviles, y tratar la transferencia de lo que esa persona posee, archivos de Drive y eventos de calendario, como un paso propio y deliberado antes de quitar nada.

El error caro es borrar la cuenta el mismo día. Una cuenta borrada se puede restaurar, pero solo dentro de veinte días, y los archivos de Drive de los que era dueña se guardan esa misma ventana y solo se alcanzan si restauras la cuenta primero. Pasado eso, la conversación de recuperación se acabó. Suspender bloquea el acceso de la persona y deja cada archivo y cada mensaje en su lugar, y por eso es el primer movimiento correcto en casi toda salida. Si el buzón hay que conservarlo por razones contables o legales, una licencia de usuario archivado mantiene esos datos disponibles en Vault sin ocupar un puesto activo.

El patrón que dejamos instalado es aburrido a propósito: suspender el último día, transferir la propiedad durante esa semana, conservar o archivar según una regla acordada antes y no en el momento, y borrar solo cuando esa regla lo diga.

Cuánto debería costar frente a tus licencias

La respuesta honesta a cuánto debería costar esto es una proporción, no un número. Compara la propuesta con lo que ya pagas de licencias: una auditoría con lista de arreglos es un múltiplo pequeño de un mes de tu suscripción, y una migración con corte real cuesta más, pero es un gasto de una sola vez frente a una factura que pagas cada mes durante años. Lo que hay que cuestionar no es la tarifa, es un trabajo por hora sin final definido.

Las licencias son además donde el trabajo suele pagarse solo, y lo que puedes recuperar depende de tu plan. En el Plan Flexible se te cobra por las cuentas que tienes ese mes, así que borrar a un usuario baja el número de licencias y el pago de inmediato. En el Plan Anual te comprometiste a una cantidad de puestos por el periodo, y solo puedes reducirla en la renovación, configurando la suscripción para que se renueve con menos licencias antes de que termine el plazo. Las empresas que descubren esto en el mes dos de un contrato de doce pagan la lección. Nuestros términos y cómo definimos el alcance están en cómo trabajamos.

Cómo verificar que un consultor es independiente y está certificado

Tres preguntas separan a un practicante de una presentación bonita.

Pregunta en qué está certificado y cuándo lo aprobó. Google Cloud tiene una certificación con examen supervisado para administradores de Workspace, y la preparación que recomienda son alrededor de seis meses de experiencia real como superadministrador, no un fin de semana de lectura. La insignia además vence y hay que volver a obtenerla, así que decir "certificado" sin fecha vale menos de lo que parece.

Pregunta si te revende las licencias. Un revendedor gana un margen sobre la suscripción. Un consultor independiente no, y eso hace más fácil que te diga que bajes de plan cuando bajar de plan es la respuesta correcta. Ninguno de los dos modelos descalifica, pero conviene saber cuál tienes enfrente. Google lista a las empresas socias en su directorio público de partners, y vale la pena entender que una certificación pertenece a una persona mientras que el estatus de socio pertenece a una empresa. Responden preguntas distintas, y un equipo independiente y pequeño puede ser fuerte en la primera sin tener la segunda.

Pregunta qué pasa cuando terminen. La respuesta debería incluir documentación que es tuya, accesos de administrador que se quedan contigo y no con ellos, y una persona con nombre de tu lado a la que le enseñaron las tareas semanales.

Cómo ayuda Guanacos Tech

Somos una consultoría independiente con ingenieros certificados por Google, trabajamos en inglés y español con empresas de unas diez a cincuenta personas en Norteamérica y Latinoamérica, desde 2018 y con más de ochenta proyectos. Un proyecto de Workspace con nosotros casi siempre arranca con la auditoría de arriba, entregada como una lista de hallazgos ordenada por lo que te costaría cada uno si saliera mal, después los arreglos en ese orden, y al final una entrega corta para que tu propio equipo lleve el trabajo semanal. Nuestra página de consultores de Google Workspace explica cómo corre el proyecto, y una primera llamada son treinta minutos para ver juntos tu consola de administración y averiguar en cuál de las cinco situaciones estás de verdad.

Fuentes

DMARC en Office 365: el registro, cómo subir la política y los reportes que nadie lee

Guanacos Tech — Mon, 21 Sep 2026 12:00:00 +0000

Imagina una agencia de carga de 25 personas que trabaja con Microsoft 365. El correo funciona, nadie piensa en él. Hasta que un cliente reenvía una factura que la empresa nunca emitió, con el dominio propio en el campo De, y esa misma semana contabilidad nota que sus facturas reales están cayendo en spam de Gmail. Dos síntomas, un solo hueco: el dominio publica SPF y DKIM, así que el correo que sale del tenant se ve correcto, pero nada le dice al servidor que recibe qué hacer con el correo que no pasa esas revisiones.

Esa instrucción es DMARC, y es el único registro que Microsoft no crea por ti. SPF y DKIM se configuran dentro de la consola. DMARC es un registro TXT que publicas en tu propio DNS, y es la única de las tres piezas que a la vez protege el dominio contra la suplantación y te dice quién está enviando en tu nombre.

Este es el orden en que lo trabajamos en un tenant de Microsoft 365: el registro del primer día, qué muestran los reportes, cómo subimos la política y las trampas propias de Exchange Online.

Qué agrega DMARC sobre el SPF y el DKIM que te da Microsoft

SPF responde una pregunta: ¿este mensaje salió de un servidor que el dominio autorizó? DKIM responde otra: ¿este mensaje se firmó con una llave que el dominio publicó y llegó sin alteraciones? Las dos pueden pasar y el mensaje seguir mintiendo sobre quién lo envió, porque ambas revisan un dominio que el lector nunca ve.

SPF revisa el remitente del sobre, la dirección del comando SMTP MAIL FROM. DKIM revisa el dominio de la etiqueta d= de la firma. La dirección que tu destinatario realmente lee es la del encabezado De, y hasta aquí nadie comparó las dos.

DMARC es esa comparación. Exige que el dominio del encabezado De coincida con el dominio que pasó SPF o con el que firmó con DKIM. Con uno de los dos basta. Esa coincidencia se llama alineación, y por defecto DMARC usa alineación relajada, que acepta un subdominio del mismo dominio organizacional. Puedes endurecerla con aspf=s y adkim=s, y en una empresa pequeña con proveedores externos normalmente no conviene.

Con esa comparación en su lugar pasan dos cosas. Puedes indicarle a quien recibe que ponga en cuarentena o rechace el correo que falla, y puedes pedir reportes con todas las fuentes que envían usando tu dominio. Los reportes son la parte que casi todos se saltan, y la que hace que subir la política sea seguro.

Hoy además hay un piso mínimo. Desde el 1 de febrero de 2024 Google exige a quien envía más de 5,000 mensajes diarios a Gmail publicar un registro DMARC, y p=none cumple con esa regla. Microsoft aplicó un requisito equivalente para Outlook.com, Hotmail.com y Live.com, anunciado el 30 de abril de 2025 y aplicado desde el 5 de mayo de 2025, primero enviando a correo no deseado y después rechazando con 550 5.7.515. Las dos reglas piden el registro, no la aplicación estricta. Aplicarlo es lo que te protege, y esa decisión es tuya.

El registro TXT exacto en _dmarc, etiqueta por etiqueta

Este es el registro del primer día para un dominio que nunca ha tenido DMARC:

Host:  _dmarc
Tipo:  TXT
TTL:   1 hora
Valor: v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com; fo=1

De izquierda a derecha:

v=DMARC1 es obligatorio y tiene que ir primero, o el registro se ignora.
p= es la política del dominio: none, quarantine o reject. Es una instrucción para los servidores que reciben, no un interruptor dentro de tu tenant.
rua= es a dónde llegan los reportes agregados. Esta etiqueta es lo que hace útil al registro desde el primer día. Apúntala a un buzón compartido o a un grupo que alguien abra, no a una persona que puede irse de la empresa.
ruf= pide reportes de falla por mensaje. Muchos proveedores grandes no los envían, y los que sí pueden incluir contenido del mensaje, así que trata ese buzón como sensible o deja la etiqueta fuera.
sp= define una política distinta para los subdominios. Si la omites, los subdominios heredan lo que diga p=, que suele ser lo que quieres una vez que la raíz está en reject.
pct= aplica la política a una muestra del correo que falla. Solo significa algo en quarantine o reject, así que es una rampa, no un ajuste permanente.
fo=1 pide un reporte de falla cuando cualquiera de las dos revisiones no alinea, y no solo cuando fallan las dos.

Dos detalles que confunden dentro de un panel de DNS. El host es _dmarc, no el dominio a secas, y algunos paneles quieren _dmarc.ejemplo.com escrito completo mientras otros agregan el dominio por ti. Y todo el valor va en un solo registro TXT. Un segundo registro DMARC en el mismo host no se suma: quien encuentra dos trata al dominio como si no tuviera política utilizable.

Publicarlo no cambia nada en la entrega. Lo que hace es abrir el flujo de evidencia del que dependen todas las decisiones siguientes.

Qué muestran los reportes en un tenant de Microsoft 365

Los reportes agregados llegan como XML comprimido, un archivo por proveedor receptor por día, normalmente dentro de las 48 horas siguientes a publicar el registro. Cada uno agrupa los mensajes por IP de origen y dice si SPF y DKIM pasaron y si cada uno alineó con tu dominio del De. Dale dos semanas, porque los remitentes mensuales son justo los que rompen un cambio de política.

En un tenant típico de M365 aparecen cuatro grupos:

Exchange Online. El correo normal de los usuarios. Si el SPF incluye spf.protection.outlook.com y DKIM firma con tu dominio propio, esas filas pasan alineadas. Si DKIM todavía firma con el dominio onmicrosoft.com del tenant, la alineación la sostiene SPF solo, y eso aguanta hasta que alguien reenvía un mensaje.
Proveedores externos. El CRM, la plataforma de facturación electrónica, la mesa de ayuda, la herramienta de marketing, la tienda en línea. Estas filas definen tu calendario: cada una necesita su propia configuración del lado del proveedor antes de que la política pueda subir.
Relays y dispositivos en sitio. Un Exchange viejo en configuración híbrida, una multifuncional que escanea y envía, un sistema administrativo que manda estados de cuenta.
Reenvíos y suplantación real. Una lista de correo o una regla de reenvío rompe SPF en mensajes perfectamente legítimos. Todo lo que queda después de explicar el resto es alguien más usando tu dominio, y es la razón para seguir.

Lee el primer archivo tú mismo en lugar de confiar en un resumen. Si el XML te resulta ajeno, pega uno aquí y mira las filas por fuente.

Subir a cuarentena y después a reject

No movemos la política por calendario. La movemos cuando el inventario de remitentes que salió de los reportes está completo y cada entrada está alineada o retirada a propósito. La secuencia que seguimos:

Primero el correo del propio tenant. Que el SPF tenga el include de Microsoft y siga por debajo del límite de 10 consultas. Que DKIM esté activado para el dominio propio en el portal de Defender, con los dos CNAME, selector1._domainkey y selector2._domainkey, publicados, para que Microsoft pueda rotar llaves sin cortar nada.
Arregla los proveedores externos uno por uno. Cada uno tiene su camino: un return-path propio o un subdominio de envío, CNAME de DKIM, o un subdominio delegado con su propio SPF. Arregla uno, espera a verlo alineado en el siguiente reporte y pasa al que sigue. Si cambias cuatro a la vez no sabes cuál funcionó.
Resuelve los relays. Una impresora o una aplicación que no puede autenticarse no sigue enviando con el dominio principal. Muévela a envío SMTP autenticado, a un conector con restricción por IP, o a un subdominio propio.
Una semana en p=quarantine. Lo que falla cae en no deseado en vez de en la bandeja, y eso se recupera. Revisa los reportes y, sobre todo, pregúntale a quien manda correo poco frecuente si algo rebotó.
Pasa a p=reject. Si quieres rampa, pct=25 y luego pct=50 te compran una falla más lenta. Si el inventario está de verdad completo, la rampa sobre todo compra tiempo.

Deja la etiqueta rua para siempre. Una política en reject sin nadie leyendo reportes es una configuración que se va a romper en silencio la primera vez que marketing contrate una herramienta nueva.

Las trampas de Microsoft que no salen en las guías genéricas

El dominio onmicrosoft.com. Todo tenant tiene uno y sirve para suplantar. La documentación de Microsoft es explícita: SPF y DKIM ya están configurados para el dominio *.onmicrosoft.com, pero el registro DMARC no, y se crea desde el centro de administración de Microsoft 365 y no en tu DNS público. Es fácil blindar el dominio propio y dejar este abierto.

Dominios que tienes y de los que nunca envías. Microsoft recomienda publicar en los dominios estacionados un registro DMARC que diga que de ahí nunca debe salir correo, con la forma v=DMARC1; p=reject; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com. Ese dominio defensivo que registraste hace tres años es un canal gratis de suplantación hasta que lo hagas.

Direct Send. Exchange Online acepta correo sin autenticar en el puerto 25 dirigido a los buzones de tu propio tenant, que es como siempre han funcionado las impresoras y los escáneres, y también como alguien de afuera deja un mensaje que parece venir de un compañero. Microsoft agregó un control a nivel de organización para esto, RejectDirectSend, que se ajusta con Set-OrganizationConfig. Si lo activas, primero inventaría los dispositivos que dependen de eso y muévelos a envío autenticado o a un conector restringido.

Reenvíos. Las reglas de reenvío automático y las listas de correo rompen SPF por diseño, porque el servidor que reenvía no está en tu registro SPF. DKIM sobrevive al reenvío mientras el mensaje no se reescriba. Esa es la razón práctica por la que DKIM tiene que estar funcionando en el dominio propio antes de endurecer, no solo SPF.

Lo que entra es otra configuración. Publicar DMARC protege a los demás del correo falso que dice venir de ti. No hace nada contra el correo falso que llega a tus usuarios. Eso lo decide tu política antiphishing, donde respetar el p=quarantine y el p=reject de otros se controla aparte. Revísalo de una vez.

Qué vigilamos después del cambio

El primer mes leemos los reportes cada semana buscando tres cosas: una fuente que nunca había aparecido, una fuente conocida cuya tasa de alineación bajó, y un aumento del correo rechazado desde tus propios rangos de IP. Lo primero suele ser una herramienta que alguien contrató. Lo segundo suele ser una llave rotada o un proveedor que cambió de infraestructura. Lo tercero amerita una llamada.

Después de eso, mensual alcanza, mientras alguien siga abriendo ese buzón.

Cómo ayuda Guanacos Tech

Hacemos este trabajo en tenants de Microsoft 365 con la misma frecuencia que en Google Workspace. Un proyecto típico son dos semanas de reportes, un inventario de remitentes, el trabajo de alineación proveedor por proveedor, y la subida hasta reject con alguien mirando mientras pasa. Si prefieres delegarlo antes que aprender el XML, nuestra consultoría de entregabilidad de correo cubre exactamente esto. Trae tu dominio a la llamada de 30 minutos y te decimos qué hay publicado hoy y qué tan lejos estás de aplicar la política.

Fuentes

El registro SPF de Office 365: cómo revisarlo, actualizarlo y no pasar de 10 consultas

Guanacos Tech — Mon, 21 Sep 2026 12:00:00 +0000

Una correduría de seguros de 14 personas nos llama un lunes. Sus cotizaciones dejaron de llegar a las direcciones de Gmail desde el viernes. No cambiamos nada, dicen. Después alguien recuerda que mercadeo contrató una herramienta de boletines hace tres semanas, y quien la configuró pegó una línea en el DNS porque un artículo de soporte se lo indicó.

Así se ve la mayoría de los problemas de SPF en un tenant de Microsoft 365. El registro estaba bien el día que se conectó el dominio. Luego la empresa creció, sumó un remitente y nadie contó lo que costaba. Esto es lo que revisamos primero en el dominio de un cliente, el orden en que lo reparamos y las trampas que aparecen una y otra vez en Microsoft 365.

Dónde te dice Microsoft qué publicar

Empieza en el centro de administración de Microsoft 365. La documentación de Microsoft sobre configuración de dominios te lleva a Configuración, luego Dominios, luego tu dominio y la vista de registros DNS, donde aparecen los valores que tu tenant espera. Esa pantalla sirve para una cosa: decirte qué quiere Microsoft que esté presente.

No es un veredicto sobre tu registro. El centro de administración verifica que su propio valor esté ahí. No evalúa el resto del registro, no cuenta tus consultas DNS y puede mostrarte todo en verde sobre un registro que falla del lado del receptor. Así que lee el panel para saber el valor requerido y después mira lo que internet devuelve de verdad para tu dominio: consulta los registros TXT del dominio desde fuera de tu red.

; lo que lee un servidor de correo receptor
example.com.   3600   IN   TXT   "v=spf1 include:spf.protection.outlook.com -all"

Esa sola línea es toda la política publicada de un tenant que envía únicamente a través de Exchange Online. Microsoft documenta exactamente ese valor como el registro SPF de Microsoft 365.

Qué hace cada parte del registro

v=spf1 marca el registro como SPF. Cualquier cosa en tus TXT que no empiece así no es un registro SPF, por mucho que lo parezca.

include:spf.protection.outlook.com apunta al nombre que mantiene Microsoft, donde están las fuentes de envío de Exchange Online. Nunca listas tú las direcciones IP de Microsoft; el include es lo que te mantiene al día cuando Microsoft las cambia.

-all es el calificador para todo lo demás. La guía de SPF de Microsoft para Microsoft 365, en la versión de esa página fechada el 3 de julio de 2026 y consultada el 21 de septiembre de 2026, recomienda el fallo duro: "For Microsoft 365 domains, we recommend -all (hard fail) because we also recommend DKIM and DMARC for the domain." El más suave ~all pide al receptor que acepte el mensaje pero lo marque, lo cual es razonable durante una semana mientras todavía descubres remitentes, y mala idea como estado permanente.

Hay dos reglas estructurales que importan más que la sintaxis. Primero, en palabras de Microsoft, "only one SPF record is allowed per domain or subdomain": un solo registro SPF por dominio o subdominio. Segundo, SPF autoriza al remitente del sobre, la dirección que se usa en la conversación SMTP, no la dirección From que tus destinatarios ven en su cliente de correo. La documentación de Microsoft lo dice sin rodeos: SPF no intenta hacer coincidir el dominio del sobre con el del From. DMARC es la pieza que exige que coincidan. Un dominio puede pasar SPF y aun así fallar DMARC, y por eso a veces arreglar solo el SPF no cambia nada.

Agregar un segundo remitente sin romper el registro

Aquí fue donde se equivocó la correduría, y es la herida autoinfligida más común que vemos. Su DNS terminó con dos registros SPF separados:

; roto: dos registros SPF en el mismo nombre
example.com.   TXT   "v=spf1 include:spf.protection.outlook.com -all"
example.com.   TXT   "v=spf1 include:_spf.herramientaboletines.com ~all"

Un receptor que encuentra dos registros no puede elegir entre ellos, así que la evaluación termina en error permanente y los dos remitentes pierden el beneficio. La guía de Microsoft para dominios que ya tienen un registro es agregar el valor de Microsoft al registro existente, no publicar un segundo. La versión reparada es un solo registro con ambos remitentes:

; correcto: un registro, los dos remitentes
example.com.   TXT   "v=spf1 include:spf.protection.outlook.com include:_spf.herramientaboletines.com -all"

Antes de agregar nada, saca el include de la documentación del propio proveedor. Las respuestas de foros envejecen, y un include que apunta a un nombre que el proveedor retiró es una consulta que estás pagando sin recibir nada a cambio.

Contar consultas, y por qué el flattening es el último recurso

SPF tiene un techo duro. La sección 4.6.4 del RFC 7208 limita una evaluación a diez términos que requieren consulta DNS, y una implementación que se pase debe devolver un error permanente. Microsoft dice la consecuencia sin adornos: "If the number of DNS lookups is greater than 10, the message fails SPF with a permanent error."

Los términos que cuestan una consulta son include, a, mx, ptr, exists y el modificador redirect. Los que salen gratis son ip4, ip6 y all, porque la respuesta ya está en el registro.

La trampa es que un include no es una consulta. Cuesta una consulta por sí mismo más todas las que haga el registro al que apunta, hasta el final de la cadena. El include de Microsoft resuelve a un registro que contiene otros includes, y varias plataformas de mercadeo y CRM hacen lo mismo. No asumas un número para ningún proveedor. Mide tu propio registro tal como está publicado, porque tu total es el único que importa.

Pega tu dominio y mira lo que ve un receptor antes de tocar el DNS:

Cuando la cuenta pasa de diez, trabaja en este orden. Cada paso es más seguro que el siguiente.

Borra los includes de servicios que ya no usas. En un dominio que viene operando desde 2018, esto solo suele bastar para bajar del límite. El CRM viejo, la prueba de un helpdesk, la herramienta de facturación que reemplazaron hace dos años.
Quita los mecanismos a y mx que quedaron sueltos. Suelen ser un recuerdo del hosting compartido donde vivía el dominio antes de pasar a Microsoft 365. Si ese host ya no envía tu correo, son dos consultas recuperadas.
Mueve a un subdominio el remitente más ruidoso. Que facturación envíe como facturas.example.com, con su propio registro SPF y su propio presupuesto de consultas. Te cuesta una conversación con el proveedor sobre el dominio del sobre, y es la solución más duradera de esta lista.
Reemplaza un include por rangos de IP publicados, y solo donde el proveedor se comprometa por escrito a direcciones estables. Las entradas ip4 no gastan consultas y también quedan congeladas en el tiempo, así que este paso viene con un recordatorio en el calendario para revisarlo, no sin él.
Apóyate en DKIM para lo que quede. Un remitente que firma con DKIM alineado a tu dominio pasa DMARC sin estar en el registro SPF. Para una plataforma de mercadeo suele ser la respuesta más limpia.

Los servicios de flattening automático, que expanden cada include en una lista de direcciones y la mantienen actualizada, quedan fuera de esa lista a propósito. Funcionan hasta que el proveedor mueve una IP y la actualización no ocurre, y entonces el correo falla un sábado sin causa visible. Los usamos solo cuando un cliente no tiene otra ruta, y nunca sin monitoreo.

Verifica con un mensaje real, no solo con un validador

Un validador de sintaxis te dice que el registro se interpreta bien. No te dice que tu app de facturación pasa. Así que envía un mensaje real desde cada sistema que usa tu dominio, a una dirección de Gmail y a una de Outlook.com, y lee las cabeceras de lo que llega.

En la cabecera Authentication-Results quieres tres cosas: spf=pass con un smtp.mailfrom que sea de tu dominio, dkim=pass y dmarc=pass. Si SPF pasa pero DMARC no, el dominio del sobre es el del proveedor y el del From es el tuyo, y ninguna edición del SPF lo va a arreglar. Nuestro analizador de cabeceras desglosa una cabecera pegada si prefieres no leerla a ojo, y la versión larga de esa habilidad está en nuestra guía para leer cabeceras de correo y saber por qué un mensaje cayó en spam.

Los dos receptores grandes ya esperan esto. Las directrices de remitentes de Google exigen que todo remitente configure SPF o DKIM, y exigen SPF, DKIM y DMARC juntos a quien envía más de 5,000 mensajes al día a cuentas personales de Gmail, además de una tasa de quejas por spam bajo 0.3 por ciento y un enlace de baja en un clic en el correo de mercadeo. Microsoft publicó requisitos equivalentes para remitentes de alto volumen hacia Outlook.com, Hotmail.com y Live.com, en vigor desde el 5 de mayo de 2025, con el correo no conforme enviado primero a la carpeta de no deseados. Ninguna de las dos reglas es nueva, y vale la pena contrastarlas antes de dar tu registro por terminado.

Las trampas más frecuentes en tenants de Microsoft 365

El registro en el nombre equivocado. SPF va en el dominio que aparece en el remitente del sobre. Con frecuencia lo encontramos publicado en spf.example.com o _spf.example.com, donde ningún receptor lo va a buscar.
Subdominios sin registro propio. Si un subdominio envía correo y no publica nada, los receptores no heredan el registro SPF del dominio padre. Cada subdominio que envía necesita el suyo.
Escáner a correo y aplicaciones internas. La multifuncional y el sistema de gestión mandan a Exchange Online usando tu dominio, y son invisibles hasta que un reporte DMARC los muestra fallando. Inventaríalos antes de apretar nada.
El registro partido mal en cadenas. Un registro TXT guarda cadenas de hasta 255 caracteres cada una. Los SPF largos hay que partirlos, y algunos paneles de DNS lo hacen metiendo un espacio o perdiendo un carácter. Vuelve a leer siempre el valor publicado después de guardar.
~all sin DMARC detrás. Un fallo suave sin política DMARC es casi lo mismo que no tener política. Si te vas a quedar en ~all, publica DMARC y lee los reportes, y después aprieta los dos.

Si estás armando un dominio de Microsoft 365 desde cero en lugar de repararlo, nuestra guía de configuración de SPF, DKIM y DMARC en Microsoft 365 cubre los tres registros en orden, y la guía del registro DMARC en Office 365 se encarga después de subir la política. Si el problema entero es la cuenta de consultas, la versión a fondo está en cómo arreglar el SPF con demasiadas consultas DNS.

Cómo ayuda Guanacos Tech

Hacemos esto para empresas pequeñas y medianas de Norteamérica y Latinoamérica, normalmente en una sola sesión: inventariamos cada sistema que envía con tu dominio, reconstruimos el registro en una sola línea que pasa y se mantiene bajo el límite, confirmamos la alineación con mensajes reales en Gmail y Outlook, y después miramos los reportes DMARC durante un mes para cazar al remitente que nadie mencionó. Si prefieres delegarlo, nuestra consultoría de entregabilidad de correo arranca con una llamada corta para ver tu registro actual y decirte qué está roto de verdad.

Fuentes

Subdominios y DMARC: por qué un dominio raíz blindado igual se puede suplantar

Guanacos Tech — Fri, 18 Sep 2026 12:00:00 +0000

Imagina una distribuidora de 30 personas que hizo bien la tarea de DMARC. El SPF pasa, DKIM firma cada mensaje, el registro del dominio raíz está en p=reject y los reportes agregados llegan cada mañana a un buzón. Un día los clientes empiezan a reenviarles facturas falsas. La dirección del remitente dice cobros@facturacion.ejemplo.com, un subdominio que la empresa nunca creó ni usa. El dominio raíz está blindado y la suplantación ocurre una etiqueta más a la izquierda.

Este es el hueco más común que encontramos en dominios cuyos dueños dan DMARC por terminado. La política funcionó tal como está especificada. Lo que pasó es que nunca le hicieron la pregunta que el dueño creía haberle hecho.

Cómo encuentra un receptor la política de un subdominio

DMARC no evalúa el dominio que configuraste. Evalúa el dominio que aparece en la cabecera From del mensaje que tiene enfrente, al que la especificación llama dominio autor. Todo lo relacionado con subdominios sale de ese único hecho.

Cuando llega un mensaje que dice venir de facturacion.ejemplo.com, el receptor consulta primero _dmarc.facturacion.ejemplo.com. Si ahí hay un registro válido, ese registro decide el resultado y no se consulta nada del dominio raíz. Si no hay nada, el receptor sube hasta encontrar el dominio organizacional, el nombre que en realidad registraste, y aplica el registro que encuentre a ese nivel.

Ese ascenso cambió en mayo de 2026, cuando DMARC pasó a ser un protocolo Standards Track con el RFC 9989, que deja obsoleto al RFC 7489 informativo de 2015. El RFC 7489 deducía el dominio organizacional a partir de la Public Suffix List y consultaba exactamente dos nombres: el dominio autor y luego el dominio organizacional. Los niveles intermedios se saltaban por completo, así que un registro publicado en _dmarc.eu.ejemplo.com era invisible para un mensaje enviado desde mail.eu.ejemplo.com. El RFC 9989 reemplaza esa lista por un recorrido del árbol DNS: sube una etiqueta a la vez, con un límite de ocho consultas, hasta encontrar el registro que marca el límite del dominio. Si alguna vez publicaste una política en un nivel intermedio de un nombre largo y viste que no hacía absolutamente nada, ese es el comportamiento que cambió.

En cualquiera de los dos casos la regla práctica es la misma, y es la que más se malentiende: un subdominio con su propio registro DMARC ignora al padre por completo. Si publicas v=DMARC1; p=none en un subdominio, ese subdominio se queda en monitoreo por más estricto que esté el dominio raíz.

La etiqueta sp y el hueco que deja debajo

Cuando el registro que termina aplicando se encontró en el dominio organizacional y no en el subdominio, el receptor no usa p. Busca sp, la política de subdominios, y solo recurre a p si sp no está. Ese comportamiento por defecto es seguro: un p=reject sin etiqueta sp sí protege a todos los subdominios que no tengan registro propio.

El problema empieza porque sp=none es genuinamente útil durante una implementación. Es la forma de aplicar política en la raíz mientras todavía estás ordenando un sistema de facturación o una plataforma de marketing que vive en un subdominio, y lo recomendamos justo para eso. También es lo que cargan un montón de registros copiados y pegados sin ninguna razón.

_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@ejemplo.com"

Con el RFC 7489 ese registro era todo o nada. El valor de sp cubría a todos los subdominios, tanto al real que estabas sacando adelante durante una migración como al nombre que un atacante se inventó hace cinco minutos. Para dejar un subdominio real en monitoreo tenías que dejar en monitoreo también a todos los subdominios imaginarios. Ese es el hueco por donde se cuela el caso de la distribuidora.

El RFC 9989 agrega np, una política que aplica únicamente cuando el dominio autor no existe. La especificación amarra la existencia al propio DNS: si una consulta por el nombre devuelve NXDOMAIN, entonces ese nombre y cualquier subdominio suyo no existen. Los valores válidos son los tres de siempre, none, quarantine y reject, y np tiene prioridad sobre sp para cualquier nombre que no pase esa prueba de existencia.

_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:dmarc@ejemplo.com"

Lee ese registro como una frase: aplica política en la raíz, deja los subdominios reales en monitoreo mientras terminamos el trabajo y rechaza cualquier cosa que diga venir de un nombre que nunca se creó. Pocos dominios tienen una buena razón para que les falte esa tercera cláusula.

Hay una distinción que define qué etiqueta cubre qué. La existencia es una pregunta de DNS, no de correo. Un nombre como app.ejemplo.com con un registro A que apunta a una aplicación web existe. Nunca ha enviado correo ni lo hará, pero responde en DNS, así que cae bajo sp y no bajo np. El soporte de np en los receptores todavía no es universal, así que trátalo como una capa que agregas y no como lo único que te separa de un subdominio falsificado.

Lo que revisamos primero en el dominio de un cliente

Antes de tocar un solo registro armamos la lista, porque cada decisión que viene después depende de saber qué subdominios son reales y cuáles de ellos envían.

Todos los nombres del dominio que resuelven, leídos de la zona DNS y no de memoria. Aplicaciones web, ambientes de prueba, puntos de VPN, una impresora que alguien nombró hace años.
Cuáles de esos envían correo de verdad, según los reportes agregados y no según lo que la gente cree.
Si cada subdominio que envía tiene su propio registro _dmarc y qué dice. Un p=none olvidado en un subdominio anula en silencio una raíz estricta.
Si cada subdominio que envía tiene su propio registro SPF.

Ese último punto es la asimetría que sorprende hasta a administradores con experiencia. DMARC sube por el árbol. SPF no. SPF se evalúa contra el dominio exacto del remitente del sobre, y si no hay un registro TXT en ese nombre exacto el resultado es none. El registro de la raíz nunca se consulta y no ayuda en nada. Entonces un sistema de facturación que envía como facturacion.ejemplo.com sin registro SPF publicado ahí falla SPF en cada mensaje, y lo único que mantiene esas facturas entregables es una firma DKIM alineada. Si aplicas política DMARC sin revisar eso primero, lo que rompes es tu propia facturación.

Subdominios que nunca deberían enviar

Para cada nombre de la lista que no tiene por qué enviar correo publicamos tres registros. El orden importa menos que el hecho de que estén los tres.

app.ejemplo.com.        MX   0 .
app.ejemplo.com.        TXT  "v=spf1 -all"
_dmarc.app.ejemplo.com. TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@ejemplo.com"

El primero es un MX nulo, definido en el RFC 7505 como un único registro MX con preferencia 0 y un destino de longitud cero escrito como un punto, que anuncia que ese nombre no acepta correo. Un dominio que anuncia un MX nulo no debe anunciar ningún otro registro MX, así que limpia lo viejo antes de agregarlo. El segundo dice que ningún servidor está autorizado a enviar como ese nombre. El tercero hace que el nombre deje de depender de sp, y eso es lo que vuelve útil este patrón en el puñado de nombres que importan, incluso cuando ya tienes np publicado.

En una zona grande cubrimos solo los nombres que resultan creíbles en una dirección de remitente falsificada: facturacion, cobros, pagos, rrhh, planilla, seguro, y el nombre del sistema contable que use la empresa.

Delegar un subdominio a una plataforma de marketing

El caso contrario es un subdominio que existe precisamente para que alguien más envíe desde ahí. Cuando una empresa hace campañas con una plataforma de correo, mover ese tráfico a noticias.ejemplo.com en lugar del dominio raíz trae dos beneficios que sí valen la pena.

El primero es separar la reputación. Una campaña que junta quejas daña la reputación del nombre que la envió, así que mantener el correo masivo fuera del nombre por donde salen tus cotizaciones y facturas significa que un envío malo no persigue a tu equipo de ventas hasta la bandeja de entrada.

El segundo es el presupuesto de consultas de SPF. SPF permite diez consultas DNS durante la evaluación, y un registro que lo excede devuelve permerror, lo que hace fallar el SPF de una vez. Los mecanismos include de las plataformas son la razón habitual por la que un dominio se queda sin margen. Como SPF se evalúa por nombre, un include que vive en noticias.ejemplo.com no le cuesta nada al dominio raíz. Delegar tus dos o tres remitentes más pesados a subdominios propios suele ser una solución más limpia que aplanar registros que después se quedan desactualizados en silencio. El conteo y las alternativas los explicamos en la guía para bajar del límite de diez consultas.

En un subdominio delegado configuramos los registros SPF y DKIM de la plataforma en ese nombre, su propio registro _dmarc para que el subdominio pueda estar en una política distinta a la de la raíz mientras se calienta, y verificamos que la plataforma firme con un dominio que alinee. La alineación es donde estos arreglos suelen quebrarse. En el modo relajado, que es el predeterminado, SPF y DKIM alinean cuando el dominio autenticado y el dominio del From comparten el mismo dominio organizacional, así que una firma DKIM con d=ejemplo.com alinea con un remitente en noticias.ejemplo.com. En modo estricto, que se activa con adkim=s o aspf=s, los nombres deben coincidir exactamente y esa misma combinación falla. Activar alineación estricta sin auditar antes los subdominios que envían es una forma segura de romper una campaña. Los registros específicos de las plataformas más comunes están en nuestro artículo sobre la alineación de Mailchimp, HubSpot y Klaviyo.

Leer las filas de subdominios en tus reportes

Los reportes agregados, que el RFC 9990 especifica en un documento propio, son donde te enteras de qué subdominios existen en la práctica y no en el papel. Dos costumbres los vuelven útiles para esto.

Lee el dominio del From de cada bloque de registro, no solo la política que publicaste. Los reportes agrupan por el dominio que los mensajes dijeron usar, así que el tráfico de subdominios aparece en sus propias filas, fáciles de pasar por alto cuando vas buscando volumen. Una fila de un subdominio que no reconoces es justamente la razón para revisar.

Después revisa qué dice el reporte que se aplicó. El bloque de política publicada te muestra tu registro tal como lo leyó el receptor, sp incluida, así que puedes confirmar que tu política de subdominios se está viendo como querías en lugar de suponerlo desde tu propio DNS. Cuando un subdominio muestra fallos que igual se entregaron, la explicación habitual es un registro _dmarc olvidado en ese subdominio que anula a la raíz en silencio, y el reporte es donde eso se hace visible. Nuestro recorrido por el XML está en cómo leer un reporte DMARC agregado, y puedes pegar uno en nuestro analizador DMARC para ver las filas decodificadas.

Cómo ayuda Guanacos Tech

El trabajo con subdominios es inventario antes que DNS. Sacamos la zona, la comparamos con lo que los reportes muestran que realmente envía y luego decidimos nombre por nombre cuáles subdominios reciben una configuración de envío delegada en forma, cuáles se blindan y cuáles simplemente pueden heredar de la raíz. Si tu dominio raíz ya está en p=reject y quieres saber si esa protección llega un nivel más abajo, pasa tu registro por el analizador o agenda una llamada y revisamos tu zona contigo.

Fuentes

Gemini 2.5 se retira el 16 de octubre. Qué se rompe y qué revisamos primero

Guanacos Tech — Fri, 18 Sep 2026 12:00:00 +0000

Imagina una firma contable pequeña que llama a finales de octubre porque el asistente de cotizaciones de su sitio dejó de responder. Esa semana no se desplegó nada. Nadie tocó el código. En los logs se ve la misma petición saliendo y un 404 regresando, una y otra vez, desde un modelo que el viernes anterior funcionaba bien.

Así se ve el retiro de un modelo de IA desde adentro de una empresa pequeña. No hay página de estado, no hay banner rojo, no hay una caída de la que todo el mundo esté hablando. Simplemente una función deja de trabajar, y quien la construyó se fue hace meses.

Hay uno de estos en el calendario justo ahora, y está cerca.

Qué cambió y cuál es la fecha que importa

El 14 de septiembre de 2026, Google publicó fechas actualizadas de deprecación y retiro para un grupo de modelos Gemini en las notas de versión de Google Cloud. La entrada que afecta a más software en producción: Gemini 2.5 Pro, Gemini 2.5 Flash y Gemini 2.5 Flash-Lite tienen fecha de retiro el 16 de octubre de 2026, según la documentación de ciclo de vida de modelos de Google, consultada el 18 de septiembre de 2026.

Dos detalles de esa documentación pesan más que la fecha principal, y son justo los que se le pasan a la gente.

El primero: la fecha de retiro es el último día en que el modelo está disponible. Después de esa fecha, la documentación de Google indica que el modelo queda desactivado de forma permanente, sin acceso ni soporte, y que las peticiones que usan el ID de un modelo retirado normalmente devuelven un error 404. No es una advertencia ni un respaldo más lento. Es un 404, que la mayoría del código escrito con prisa trata como una falla genérica cualquiera.

El segundo detalle es el que agarra a todos desprevenidos. La página de versiones y ciclo de vida de modelos de Google indica que un mes antes de la fecha de retiro se bloquea el acceso nuevo al modelo para inferencia en línea, inferencia por lotes y ajuste. Para un retiro el 16 de octubre, esa ventana se cerró a mediados de septiembre. Si un proyecto nunca ha llamado a Gemini 2.5, es posible que ya no pueda empezar, así que aquello de "primero probamos en el modelo viejo y migramos después" dejó de ser un plan viable.

A quién le afecta de verdad

No todos los que usan Gemini tienen algo que hacer. La diferencia está en si el nombre de un modelo aparece escrito en algún lugar de tus sistemas.

Si tu equipo usa Gemini dentro de Google Workspace, en el panel lateral de Gmail o Documentos, no estás eligiendo una versión de modelo y no tienes migración que correr. Google administra lo que hay detrás de esa experiencia.

Estás expuesto si un ID de modelo como gemini-2.5-flash aparece en algo de lo que depende tu operación. En una empresa de diez a sesenta personas, suele vivir en alguno de estos lugares:

Un Apps Script pegado a una hoja de cálculo que clasifica prospectos o redacta respuestas.
Un chat o formulario de cotización del sitio web, casi siempre una Cloud Function o un backend pequeño.
Un paso en una plataforma de automatización, donde el nombre del modelo vive en un menú o en un campo JSON dentro de un flujo que nadie abre desde hace un año.
Una app web o móvil construida sobre Firebase.
Un script de reportes o de resúmenes que corre programado, y cuyo resultado alguien pega cada mes en una presentación para el cliente.
Un prototipo que se volvió producción en silencio, porque funcionaba.

El último es el que más daño hace, porque es el que no tiene dueño, ni pruebas, ni manejo de errores.

Qué revisamos primero en un proyecto de cliente

Cuando un cliente nos pide resolver una de estas fechas límite, no empezamos cambiando nombres de modelos. Empezamos por encontrarlos todos.

1. Inventariar cada punto de llamada. Buscar en todo el entorno, no solo en el repositorio principal, por familia de modelo y no por una cadena exacta. Los sufijos de versión varían, y de eso se trata la búsqueda amplia:

grep -rn "gemini-2\.5" . --include="*.js" --include="*.ts" --include="*.py" --include="*.gs" --include="*.json" --include="*.yaml" --include="*.env*"

Después hay que repetirlo a mano donde grep no llega: proyectos de Apps Script adjuntos a hojas y formularios, flujos en plataformas de automatización, variables de entorno definidas en una consola y no en un archivo, y cualquier configuración que haya dejado un proveedor anterior.

2. Separar versiones fijadas de alias. Google publica versiones estables junto con alias que se actualizan solos. El código que fija una versión exacta es predecible y se va a romper en una fecha conocida. El código que sigue un alias se mueve por su cuenta, lo cual es cómodo hasta que un cambio de generación altera el comportamiento bajo un prompt afinado para el modelo anterior. Los dos casos necesitan revisión. Necesitan revisiones distintas.

3. Probar si el acceso ya está bloqueado. Por la regla del mes que mencionamos arriba, revisamos temprano si el proyecto todavía alcanza el modelo viejo. Eso cambia el plan. Si ya no lo alcanza, no hay transición gradual que diseñar, solo una migración.

4. Rastrear qué consume la salida. Una llamada que falla es un problema. Una llamada cuya respuesta se guarda en una base de datos, se le envía por correo a un cliente o define en qué cola cae un ticket es un problema mucho mayor. Seguimos la salida hasta su última parada antes de decidir cuánto cuidado hace falta.

5. Leer el manejo de errores. Aquí aparece el riesgo real. Muchas integraciones pequeñas envuelven la llamada en un try que se traga la excepción y devuelve una cadena vacía. El día del retiro ese código no truena. Sigue corriendo, y manda contenido en blanco o cortado a clientes reales, cosa que nadie nota durante una semana.

La migración, en el orden en que la hacemos

Lee la lista de modelos vigente para tu propio proyecto. No un artículo de blog, incluido este. Las fechas y la disponibilidad cambian por región y por superficie, y las páginas de modelos de Google son el único lugar donde eso es definitivo para tu cuenta.

Elige un modelo en disponibilidad general, no uno en preview. Los modelos en preview tienen su propio ciclo de vida, a menudo más corto, y no son el lugar donde aterrizar trabajo de producción que no quieras volver a mover en seis meses. Si el único reemplazo que sirve para tu caso está en preview, conviene saberlo antes de planear el trabajo, no después.

Mueve el ID del modelo a configuración. Si la cadena está escrita a mano en el código, el primer cambio es sacarla a una variable de entorno o a una sola constante. Ese es el arreglo que vuelve esta fecha límite la última dolorosa, porque el siguiente retiro pasa a ser un cambio de configuración y una prueba.

Vuelve a probar los prompts, no solo cambies el nombre. Una generación nueva no es un reemplazo directo. Cambian el largo de la respuesta, el tono, el formato y qué tan al pie sigue las instrucciones, y a veces cambian los nombres de los parámetros entre generaciones, así que revisa la guía de migración de Google para el par que vas a mover. Si tu prompt pide JSON, comprueba que siga devolviendo JSON que se pueda parsear. Corre las veinte entradas reales más comunes y compara las respuestas lado a lado.

Arregla el manejo de errores ya que estás adentro. Cualquier llamada que pueda fallar debe fallar de forma ruidosa: registra el ID del modelo, registra el código de estado y avisa a una persona. Diez minutos de trabajo aquí convierten cada deprecación futura en una notificación en vez de un misterio.

Despliega y luego observa. Despliega antes de la fecha, no ese mismo día, y deja el valor anterior en configuración hasta que veas una semana completa de tráfico normal con el modelo nuevo.

Notas de costo y riesgo

Tres cosas sobre las que conviene ajustar expectativas.

El precio es por modelo, así que verifícalo. Las tarifas cambian entre familias y niveles de modelo, y uno más nuevo o más grande no es automáticamente el más barato ni el más caro. Revisa la tarifa vigente del modelo específico al que te vas a mover contra tu volumen mensual real antes de comprometerte, en lugar de asumir que el cambio sale igual.

Estas fechas se mueven, en los dos sentidos. No siempre se adelantan. En el mismo grupo de actualizaciones de septiembre de 2026, a Gemini 2.5 Flash Image se le puso fecha de retiro el 15 de marzo de 2027, extendida desde el 2 de octubre de 2026, y Gemini 3.1 Flash-Lite Image quedó con fecha de retiro prevista para el 28 de junio de 2027 o después. Una extensión es un regalo, no un plan. Lo correcto ante una fecha que se corre es dejar la migración agendada y disfrutar el margen extra.

El riesgo real es el inventario, no la ingeniería. Cambiar el nombre de un modelo es una tarea chica. Estar seguro de que encontraste todos los lugares donde aparece es el trabajo completo, y la primera búsqueda en un repositorio pocas veces es la que encuentra todo.

Cómo ayuda Guanacos Tech

Esto lo hacemos como un trabajo corto y acotado: inventariar cada lugar donde se llama a un modelo Gemini en tu código, scripts, automatizaciones y consolas, decirte cuáles se rompen el 16 de octubre y cuáles están bien, migrar los que importan, y dejar el ID del modelo en configuración con manejo de errores que avise la próxima vez. Somos una consultora independiente con ingenieros certificados por Google, y trabajamos en inglés y español en Norteamérica y Latinoamérica.

Si no tienes claro si algo en tu empresa llama a Gemini 2.5, esa duda ya es la respuesta, y vale una hora antes de octubre. Puedes ver qué hacemos en Google Cloud, o agendar una llamada y lo revisamos contigo.

Fuentes

Migrar el correo de cPanel u hosting compartido a Google Workspace sin perder mensajes

Guanacos Tech — Thu, 17 Sep 2026 12:00:00 +0000

Imagina una importadora de 14 personas en San Salvador. Su correo vive en hosting compartido desde 2016: once buzones en cPanel, un webmail que nadie disfruta, una cuota de 2 GB por cuenta que contabilidad rebasó hace dos años y facturas que este trimestre empezaron a caer en el spam de los clientes. Quieren Google Workspace. Y antes que nada quieren escuchar que nadie va a perder ocho años de correo.

Esa es la objeción real y es razonable. La migración en sí es trabajo de rutina. El miedo no lo es, porque en estos proyectos sí se pierde correo, casi siempre por una de dos razones: se movió el DNS antes de copiar los buzones, o nadie anotó qué estaba enviando el hosting viejo en nombre de la empresa.

Este es el orden en que trabajamos cuando el punto de partida es cPanel o cualquier otro correo de hosting compartido, qué copia de verdad la herramienta de Google y dónde se rompen las cosas sin que te des cuenta.

El correo del hosting son dos sistemas y solo uno migra

Los buzones son un sistema. La configuración alrededor de ellos es otro: reenvíos, respuestas automáticas, filtros, alias, listas de correo y la cuenta catch-all. El servicio de migración de datos de Google llega al primero por IMAP y no ve el segundo en absoluto. Cuando el origen es un servidor IMAP, el servicio mueve únicamente el correo y las etiquetas. Los eventos de calendario, los contactos, los archivos de Drive y los Sites no forman parte de una migración IMAP. Todo lo que en cPanel es configuración y no un mensaje se vuelve a construir a mano en la consola de administración, y eso está bien siempre que alguien lo haya anotado antes.

Conviene conocer tres límites antes de prometer nada. La ruta IMAP del servicio de migración admite hasta 100 usuarios de origen. Los mensajes de más de 25 MB con adjuntos incluidos no se migran. Las carpetas IMAP compartidas o públicas no son compatibles. En una empresa pequeña los dos primeros casi nunca estorban, pero el techo de 25 MB sí, justo en el buzón que te imaginas: el que recibe contratos escaneados.

El inventario, antes de crear nada

Abrimos una hoja y la llenamos desde el panel, no de memoria:

Cada buzón, su tamaño actual y su cuota. El tamaño te dice cuánto tardará la copia. La cuota te dice qué cuentas llevan tiempo rechazando correo en silencio.
Cada alias, reenvío y lista de correo, con su destino.
Cada filtro y respuesta automática, incluidos los que configuró desde el webmail alguien que ya no trabaja ahí.
La configuración del catch-all. En hosting compartido suele estar activa, así que las direcciones mal escritas llevan años llegando a algún lado.
Cada aplicación que envía con el dominio: el proveedor de facturación o DTE, la tienda en línea, el CRM, el formulario de contacto del sitio, el escáner del pasillo.
Los registros MX, SPF, DKIM y DMARC actuales, con sus valores de TTL.
Quién controla de verdad el registrador y la zona DNS. Este es el punto que atrasa los cortes.

La lista de aplicaciones es la que todos se saltan, y es la que produce la llamada de "todo funciona menos las facturas" una semana después.

Crea los usuarios como los vas a pagar

Cada persona real recibe un usuario. Las direcciones compartidas como info@ o ventas@ se vuelven grupos, no cuentas con una contraseña que conocen tres personas. Los alias se quedan como alias sobre el usuario que los lee. Una empresa que viene de hosting compartido casi siempre tiene muchas más direcciones que personas, y la diferencia entre modelar eso bien y crear un usuario con licencia por cada dirección es buena parte del costo del primer año.

Verifica el dominio con el registro TXT que te da Workspace, crea los usuarios y detente ahí. El MX se queda donde está.

Copia el correo con el sistema viejo todavía en vivo

El servicio de migración de datos se conecta al servidor del hosting por IMAP y copia hacia los buzones nuevos mientras el correo sigue llegando con normalidad a cPanel. No se interrumpe nada, así que no hay por qué apurar esta etapa. Necesitas el nombre del servidor de correo, el puerto de IMAP sobre TLS y la contraseña de cada buzón o una credencial administrativa que tu proveedor permita para migraciones.

Servidor origen:  mail.ejemplo.com
Puerto:           993 (IMAP sobre TLS)
Por buzón:        dirección + contraseña del panel de hosting

Corre la copia completa varios días antes del corte. Después del corte vuelve a ejecutar el servicio contra el mismo origen. Esa segunda pasada es un delta: recoge todo lo que llegó al hosting viejo mientras tanto, y es el mecanismo que vuelve seguro todo el proyecto. Un buzón de origen con más de 6,000 etiquetas o carpetas también necesita una pasada delta para terminar.

Una revisión antes de empezar: una cuenta no puede recibir más correo del que permite su almacenamiento en Workspace. Si un buzón de cPanel de 40 GB va hacia un plan con menos espacio que eso, la importación se detiene a medio camino, y la solución es cambiar de plan, no reintentar.

Baja el TTL dos días antes, no esa mañana

Este paso decide si tu ventana de corte se mide en minutos o en un día. El TTL de un registro le dice a los resolvers cuántos segundos guardarlo en caché, y un TTL más corto empieza a aplicar solo cuando expira el valor anterior. Si tu registro MX lleva tiempo en 86400, bajarlo esta tarde no sirve esta tarde: los resolvers que ya tenían el registro en caché pueden conservarlo otras 24 horas antes de empezar a respetar el valor nuevo y más corto. Bájalo con al menos dos días de anticipación. Google recomienda 3600 como valor de trabajo, y uno más corto como 300 cuando quieres poder revertir un cambio rápido, que es justo la situación del día del corte.

; valor típico por defecto en hosting compartido
ejemplo.com.   86400   IN   MX   0 mail.ejemplo.com.

; dos días antes del corte: mismo destino, TTL más corto
ejemplo.com.   300     IN   MX   0 mail.ejemplo.com.

El corte, en orden

Confirma que la migración masiva terminó y que los usuarios ya ven su correo viejo en Gmail.
Reemplaza el registro MX con el valor de Google Workspace y borra el MX del hosting. No dejes el viejo como respaldo con prioridad menor, porque así es como el correo sigue llegando a un lugar que nadie revisa.
Manda un mensaje de prueba desde una dirección externa y confirma que llega a Gmail.
Deja los buzones de cPanel en su lugar, recibiendo lo que todavía les llegue.
Corre la migración delta al día siguiente y otra vez una semana después.
Sube el TTL del MX de vuelta a 3600 cuando estés tranquilo.

ejemplo.com.   300   IN   MX   1 smtp.google.com.

Google Workspace usa un solo valor de MX, smtp.google.com. Los registradores no se ponen de acuerdo en cómo escribirlo: algunos piden un punto final y otros esperan la prioridad y el destino juntos en un mismo campo, como 1 smtp.google.com. Los dominios que empezaron en Workspace antes de 2023 pueden conservar el conjunto anterior de registros aspmx, que siguen siendo compatibles, así que no hay necesidad de cambiarlos como parte de este proyecto. Los registros MX nuevos pueden tardar hasta 72 horas en reconocerse en todos lados, aunque con un TTL de 300 segundos ya puesto la mayoría de remitentes te sigue en minutos.

Los días posteriores al cambio son la ventana de doble entrega: algunos remitentes todavía resuelven el registro viejo en caché y entregan a cPanel. Eso es esperable y es inofensivo mientras los buzones viejos sigan existiendo. Borrarlos el día del corte es la forma más común de perder correo de verdad en esta migración. Dos semanas es un plazo razonable, y la cuenta de hosting se cancela solo después de la última pasada delta.

Los remitentes que siguen usando el servidor viejo

Después del cambio de MX, mail.ejemplo.com normalmente sigue resolviendo y sigue aceptando SMTP. Cada aplicación configurada con ese nombre y una contraseña vieja de buzón sigue funcionando, en el sentido de que sigue enviando. Esos mensajes ahora salen por un servidor que el dominio ya no autoriza, y las copias caen en un buzón que nadie abre. Recorre la lista de aplicaciones de tu inventario y reapunta cada una: la tienda, el CRM, el formulario de contacto, el escáner, la plataforma de facturación. En El Salvador el proveedor de DTE también entra en esa lista, y escribimos aparte por qué las facturas electrónicas llegan a spam.

Autentica el mismo día

Un dominio que sale del hosting compartido también deja atrás una reputación de envío compartida, que suele ser una de las razones de la mudanza. Publica la autenticación nueva el día del corte y no el mes siguiente:

ejemplo.com.         300  IN  TXT  "v=spf1 include:_spf.google.com ~all"
google._domainkey    300  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc               300  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com"

SPF es un solo registro por dominio. El SPF del hosting se reemplaza, no se apila junto al nuevo, porque tener dos registros TXT de SPF es una falla permanente. El DKIM se genera en la consola de administración, en Gmail, Autenticar correo: elige una llave de 2048 bits si tu proveedor de DNS lo admite, conserva el prefijo de selector google por defecto, publica el registro TXT y regresa a la consola para iniciar la autenticación. Una llave de 2048 bits no cabe en una sola cadena DNS de 255 caracteres, así que se ingresa como varias cadenas entre comillas dentro del mismo registro TXT, algo que algunas interfaces de registrador resuelven por ti y otras no. DMARC arranca en p=none con una dirección de reportes, y el endurecimiento viene después de leer un par de semanas de reportes, que es el tema de pasar DMARC de p=none a p=reject.

Deja el selector DKIM y el include de SPF del hosting viejo en el DNS hasta confirmar que ya nada envía por ese servidor, y entonces bórralos.

Lo que suele salir mal

Se borraron los buzones viejos el día del corte, así que lo que se entregó durante la ventana de caché del DNS se perdió para siempre.
Nunca se recreó el catch-all, y direcciones que antes se aceptaban en silencio ahora rebotan.
Se dio por hecho que los filtros y reenvíos migran. No migran: se reconstruyen en la configuración de Gmail y en la consola de administración.
Alguien esperaba que los contactos y calendarios llegaran con una migración IMAP. Esos se exportan e importan aparte.
Se bajó el TTL la mañana del cambio, así que el registro viejo se quedó en caché el resto del día.

Cómo ayuda Guanacos Tech

Somos una consultoría independiente con ingenieros certificados por Google, trabajando en inglés y español en Norteamérica y Latinoamérica. Hacemos el inventario, corremos la copia IMAP, acompañamos la hora del corte, reconstruimos los reenvíos y filtros, y publicamos SPF, DKIM y DMARC el mismo día, para que el dominio llegue autenticado en lugar de repararse después. Si quieres ver cómo está tu dominio antes de tocar el DNS, el diagnóstico de correo es gratis, un proyecto de Workspace explica el alcance, cómo trabajamos cubre la forma de cotizar, y puedes agendar una llamada en calendar.app.google.