Lee el rebote antes de tocar nada

El rechazo de Gmail no es un solo error. Son varios problemas distintos que en la conversación diaria se resumen como "550 5.7.1", y el código exacto más la frase que lo acompaña te dice cuál de ellos tienes en realidad.

"550-5.7.1 ... Our system has detected that this message is suspicious due to the very low reputation of the sending domain" significa que Gmail evaluó el historial de envío de tu dominio y decidió que se parece lo suficiente a una fuente de spam como para no aceptar correo de él por ahora. Es un problema de reputación de dominio, y ese historial lo construye Google Postmaster Tools con el tiempo.

Un mensaje parecido, "low reputation of the sending IP address", es el mismo rechazo pero referido a la IP en vez del dominio. Si envías desde Google Workspace, esa IP es de Google, no tuya, así que el bloqueo suele apuntar a otra cosa en la infraestructura compartida, o a un servidor de terceros cuya IP arrastra un mal historial que no tiene nada que ver con tu dominio.

Un tercer mensaje, "550-5.7.26, This mail is unauthenticated", no es un problema de reputación. Gmail no pudo verificar SPF ni DKIM para ese mensaje en particular y lo rechazó directamente, sin evaluar reputación. Es la exigencia de autenticación de remitentes de Google haciendo su trabajo: desde febrero de 2024, todo remitente necesita que SPF o DKIM pasen, y los remitentes masivos, aproximadamente 5,000 mensajes al día o más a cuentas personales de Gmail, necesitan que ambos pasen más un registro DMARC.

Guarda el rebote completo, no solo la línea resumen. Casi siempre trae un enlace a la explicación oficial de Google y, más importante, el código exacto que te dice si estás ante un problema de reputación, de autenticación o de otra cosa. Tratar "unauthenticated" como si fuera reputación te hace perder semanas en un plan de calentamiento que nunca iba a resolverlo.

Paso 1: autentica todo y revisa la alineación

Antes de asumir que el problema es de reputación, descarta la autenticación. Los dominios que antes pasaban SPF y DKIM se salen de cumplimiento en cuanto una herramienta nueva empieza a enviar en su nombre, un sistema de facturación, un CRM, una plataforma de marketing, sin que la agreguen al registro SPF ni le den un selector DKIM.

Revisa tres cosas en el dominio que aparece en el rebote:

• SPF: el registro TXT debe incluir a todos los servicios que envían en tu nombre, y debe resolver en "pass" para la IP que realmente está enviando el mensaje.
• DKIM: el correo saliente necesita una firma válida que se verifique contra la llave pública publicada en el registro TXT selector._domainkey. En Google Workspace, DKIM viene apagado por dominio hasta que generas y publicas esa llave desde el Admin Console.
• DMARC: el dominio necesita un registro DMARC, aunque sea p=none, y el encabezado From visible tiene que alinear con el dominio de SPF o con el dominio que firma el DKIM. Las reglas de remitentes masivos de Gmail solo exigen que uno de los dos alinee, pero apuntar a que ambos alineen es la meta más segura.

Envía un correo de prueba real a una cuenta de Gmail que controles, ábrelo, elige "Mostrar original" y lee el encabezado Authentication-Results de ese envío exacto. Confirma SPF=pass, DKIM=pass y DMARC=pass. Corrige el que falle antes de invertir tiempo en reputación, porque un registro de autenticación roto debajo de un problema de reputación hace que el motivo del rebote cambie de forma impredecible entre uno y otro.

Paso 2: revisa qué dice Postmaster Tools

Si la autenticación está limpia y sigues rebotando, Google Postmaster Tools es el único lugar que muestra la visión que Google tiene de tu historial de envío. Necesita verificación de propiedad del dominio y un volumen real de correo autenticado con DKIM o SPF hacia cuentas de Gmail antes de que los paneles muestren datos, así que date de alta ahí si todavía no lo has hecho.

Dos paneles importan aquí. Reputación de dominio y reputación de IP se califican como Alta, Media, Baja o Mala. Google define Alta como "un historial de tasas de spam muy bajas" que cumple las guías de remitentes, y Mala como "un historial de envío de un alto volumen de spam de forma regular", donde el correo "casi siempre se marca como spam o se rechaza en el servidor receptor". Si tu dominio está en Baja o Mala, esa calificación, no algo visible desde tu propia bandeja, es lo que produce el rebote 550 5.7.1.

La tasa de spam es el porcentaje de tus mensajes que llegan a la bandeja de un destinatario activo y luego se marcan manualmente como spam. La guía de Google es mantenerla por debajo de 0.10% y tratar 0.30% como techo duro. Si lo cruzas, pierdes elegibilidad para el soporte de mitigación de entrega de Google hasta que te mantengas debajo de 0.30% durante siete días seguidos.

Google también ha señalado que las pestañas de Reputación de IP y Reputación de Dominio en particular se van a descontinuar eventualmente, sin fecha fija. Trata la tasa de spam y la autenticación como las señales más duraderas para armar tu monitoreo de aquí en adelante.

Paso 3: para la hemorragia antes de intentar arreglar la reputación

La reputación mira hacia atrás. Cada mensaje que sigues enviando hacia un bloqueo agrega otro dato malo a un historial con el que Google ya está inconforme. Antes que nada:

• Pausa o reduce fuerte el volumen hacia Gmail, sobre todo en cualquier lista que no puedas demostrar que está suscrita y activa.
• Saca del envío activo a quien no ha abierto ni dado clic en los últimos 90 a 180 días. Las listas viejas son el motivo más común detrás de una tasa de spam en aumento, porque los destinatarios que ya no reconocen al remitente son los que más presionan "reportar spam" en vez de darse de baja.
• Busca un envío que haya quedado corriendo: una campaña programada, una automatización, una cuenta comprometida reenviando spam a través de tu dominio. Un desplome de reputación que coincide con una fecha específica casi siempre es un remitente identificable comportándose mal, no un deterioro orgánico lento.
• Si calificas como remitente masivo, agrega los encabezados de baja con un clic que exige Google, List-Unsubscribe y List-Unsubscribe-Post, para que quien ya no quiera el correo tenga una salida fácil que no sea el botón de spam.

Paso 4: reconstrúyela con calma

Una vez retirada la señal mala, el consejo de Google para recuperar reputación coincide con su consejo para cualquier remitente nuevo: empieza con volumen bajo hacia tus destinatarios más activos y súbelo despacio, evitando picos repentinos. Google no publica un calendario día por día, así que trata cualquier "calendario de calentamiento de 14 días" que encuentres en otro lado como una estimación de terceros, no como política oficial. Lo que se mantiene igual entre fuentes es la dirección: volumen pequeño hacia gente que abre y responde, vigilado de cerca, ampliado solo cuando la tasa de spam y los paneles de reputación se mantienen estables o mejoran, no según un calendario fijo.

Espera que esto tome semanas, no días. Los paneles de reputación en Postmaster Tools son históricos, así que una semana limpia no borra un mes malo.

Cuando el problema de reputación no depende directamente de ti

Si envías desde Microsoft 365, Zoho o hosting compartido por SMTP, la IP detrás de tu correo puede estar compartida con cientos de otros clientes. La guía de Google es directa al respecto: "la actividad de cualquier remitente que use una dirección IP compartida afecta la reputación de todos los remitentes" en ella. Si Postmaster Tools muestra la reputación de IP en Baja o Mala mientras la reputación de dominio se ve bien, lo más probable es que otro cliente en esa IP compartida sea la causa. La solución es trabajar con el proveedor para aislar o rotar la IP, o moverte a un esquema donde controles, o puedas pedir, una ruta de envío dedicada. La reputación de dominio es la palanca que controlas por completo. La reputación de IP en infraestructura compartida, muchas veces no.

Los dominios nuevos empiezan sin reputación, no con mala reputación

Un dominio recién creado, o uno que nunca ha enviado volumen significativo a Gmail, no tiene un rebote de baja reputación esperándolo. No tiene reputación en absoluto, y Postmaster Tools puede simplemente mostrar que aún no hay datos. Enviar un lote grande desde un dominio nuevo el primer día se ve idéntico a un atacante que arma un dominio desechable para mandar spam, y Gmail lo trata en consecuencia. La solución es el mismo principio de arranque lento que en una recuperación: autentica primero, envía volumen pequeño y constante a destinatarios reales, y deja que el dominio construya un historial antes de depender de él para algo urgente.

Cómo ayuda Guanacos Tech

La mayoría de los casos 550 5.7.1 que revisamos son una mezcla de dos o tres de las causas anteriores encimadas, un selector DKIM que dejó de verificar sin que nadie lo notara, una herramienta de marketing que nadie agregó a SPF, y una lista vieja que alguien siguió usando de todas formas. Hacemos el diagnóstico completo (autenticación, reputación en Postmaster Tools, historial de tasa de spam, higiene de listas), corregimos el DNS y las prácticas de envío en el orden correcto, y acompañamos la recuperación de reputación durante el calentamiento para que no estés adivinando cuándo es seguro volver al volumen normal. Si quieres una segunda opinión sobre tu caso, agenda una llamada de revisión de reputación.

Fuentes

• Postmaster Tools dashboards - Gmail Help
• Email sender guidelines - Google Workspace Admin Help
• Email sender guidelines FAQ - Gmail Help
• Prevent mail to Gmail users from being blocked or sent to spam

Por qué el correo de Microsoft 365 falla en Gmail aunque el tenant se vea sano

Exchange Online manda tu correo esté autenticado tu dominio o no. Eso es lo que confunde. Los mensajes salen, la carpeta de enviados se llena, nada aparece en rojo en el centro de administración, y aun así un cliente en Gmail te dice que tu cotización cayó en spam, o te regresa un rebote diciendo que el mensaje no venía autenticado.

En un dominio de Microsoft 365 la causa casi siempre es la misma historia de tres partes: el SPF se publicó cuando se agregó el dominio, el DKIM del dominio propio nunca se activó, y el DMARC nunca se publicó. Microsoft firma el correo saliente con el dominio onmicrosoft.com de tu tenant hasta que tú activas DKIM para el dominio propio. Entonces sí hay una firma, pero lleva el dominio equivocado y no sirve de nada para la dirección que tu lector ve en el campo De. Terminas autenticado solo con SPF, que es la mitad frágil: el SPF se rompe con cualquier reenvío, y no hay firma DKIM de tu propio dominio que sirva de respaldo.

Los tres registros, en el orden que no te tumba el correo

Publica primero SPF, después DKIM y al final DMARC. Cada registro demuestra algo distinto, y DMARC es el único que puede empezar a rechazar correo, así que entra cuando ya confirmaste que los otros dos funcionan.

• SPF dice qué servidores tienen permiso de entregar tu correo a internet. Se revisa contra el remitente del sobre, la dirección del comando SMTP MAIL FROM, no contra el De que ve tu lector.
• DKIM le pone una firma criptográfica al mensaje. El receptor busca la llave pública en tu DNS y confirma que el mensaje lo firmó quien controla ese dominio y que nadie lo alteró en el camino.
• DMARC amarra cualquiera de los dos resultados al dominio que aparece en el De visible, y le dice al receptor qué hacer cuando ninguno cuadra. Un mensaje pasa DMARC cuando SPF o DKIM pasa y el dominio con el que pasó está alineado con el del De. Con uno de los dos basta, y por eso justamente importa el que falta.

SPF: un include, y el presupuesto de consultas que gastas después

Para un tenant que solo envía por Exchange Online, Microsoft documenta un solo registro:

example.com.   TXT   "v=spf1 include:spf.protection.outlook.com -all"

El -all del final es un fallo duro: lo que no esté autorizado se debe rechazar. Microsoft documenta ese y también el más suave ~all. Empieza con ~all si de verdad no estás seguro de haber encontrado todos tus remitentes, y aprieta a -all cuando tus reportes DMARC ya te muestren la lista completa. Nunca publiques dos registros SPF para el mismo dominio. Si ya existe uno, fusiona el include ahí.

Ese registro es barato. Deja de serlo en cuanto agregas un CRM, un sistema de facturación, una plataforma de marketing y una mesa de ayuda, porque el RFC 7208, sección 4.6.4, limita la evaluación de SPF a 10 consultas DNS y obliga al receptor a devolver permerror si te pasas. Cada término include, a, mx, ptr, exists y redirect cuesta una consulta, incluidos los que van anidados dentro del include de alguien más. Las entradas ip4 e ip6 no cuestan nada, y por eso los entornos híbridos ponen directo las IP de salida de sus servidores locales en lugar de agregar otro include:

example.com.   TXT   "v=spf1 ip4:203.0.113.25 include:spf.protection.outlook.com -all"

Cuenta el registro en vivo con una herramienta que siga los includes anidados, no contando las entradas que alcanzas a ver. El conteo completo y las salidas posibles las explicamos en la guía del límite de consultas de SPF.

DKIM: dos CNAME, y por qué Microsoft pide dos

Microsoft 365 usa dos selectores por dominio propio, selector1 y selector2, para poder rotar las llaves de firma sin dejar un hueco. Publicas dos registros CNAME que apuntan a llaves que Microsoft guarda por tu tenant:

selector1._domainkey.example.com.   CNAME   selector1-example-com._domainkey.contoso.onmicrosoft.com.
selector2._domainkey.example.com.   CNAME   selector2-example-com._domainkey.contoso.onmicrosoft.com.

Saca los valores exactos del portal en lugar de armarlos a mano. El patrón es predecible, pero el nombre del tenant dentro del destino tiene que estar bien o la consulta no resuelve a nada. En el portal de Microsoft Defender esto vive en Correo electrónico y colaboración, Directivas y reglas, Directivas de amenazas, DKIM. Microsoft reacomoda ese menú cada tanto, así que busca DKIM dentro del portal si no está donde lo esperas.

Aquí el orden también importa. Publica los dos CNAME, espera a que resuelvan y después activa la firma para el dominio. Si activas primero, falla, porque Microsoft verifica que puede leer las llaves antes de firmar con ellas. En tenants viejos vale la pena revisar el largo de la llave: 2048 bits es el estándar actual, y una configuración creada hace años puede seguir en 1024. En PowerShell de Exchange Online eso vive en la configuración de firma, por ejemplo New-DkimSigningConfig -DomainName example.com -KeySize 2048.

Una vez activada la firma para el dominio propio, el correo saliente se firma con ese dominio en lugar del onmicrosoft.com. Ese solo cambio es lo que convierte al DKIM de adorno en un identificador que DMARC sí puede usar.

DMARC: publícalo en p=none y después lee los reportes

El registro es una entrada TXT en el subdominio _dmarc:

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

p=none no cambia nada en la entrega. Le pide a los receptores que te manden reportes agregados con cada dirección IP que envía como tu dominio, y si SPF y DKIM pasaron y alinearon en cada caso. Esa lista es el único inventario honesto de tus remitentes, y siempre es más larga que la que tienes en la cabeza: el sistema contable, la herramienta de agendas que alguien contrató, el escáner de la oficina.

Déjalo en p=none unas dos semanas, arregla cada remitente legítimo hasta que alinee, y luego pasa a p=quarantine y por último a p=reject. Llegar a aplicar la política es el objetivo, y la guía de Microsoft recorre el mismo camino de monitorear, cuarentena y rechazo, pero saltar directo a reject en un dominio que no inventariaste es exactamente como dejan de llegar las facturas. Vale saberlo también en el otro sentido: Exchange Online Protection evalúa DMARC en el correo entrante y respeta la política que publicó el dominio remitente, así que tu propia política también protege a tu equipo del correo que suplanta tu dominio. Microsoft publica además una guía aparte para poner reportes DMARC en dominios estacionados y en el dominio de enrutamiento onmicrosoft.com del tenant, y las dos valen la pena una vez que el dominio principal ya quedó.

Las trampas de alineación propias de Microsoft 365

Hay cuatro cosas que rompen la alineación en tenants que por fuera se ven bien configurados:

1. La firma con onmicrosoft.com. La más común por mucho. Un DKIM que pasa con header.d=contoso.onmicrosoft.com cuando tu De es de example.com no alinea, y DMARC simplemente lo ignora.
2. Los subdominios. Una política DMARC cubre los subdominios a través del dominio padre, salvo que la sobrescribas con sp=. Si un subdominio manda correo real desde otra plataforma, dale su propio SPF y DKIM en lugar de descubrirlo en un reporte cuando ya estás en reject.
3. Servicios de Microsoft que no son Exchange Online. La automatización de flujos y el motor de correo propio de un CRM envían en tu nombre desde infraestructura que tu include de Exchange no cubre. Son remitentes aparte y necesitan su propia autorización o su propia firma DKIM, igual que un proveedor externo.
4. Relays y conectores. Un appliance, un formulario del sitio en hosting compartido o un servidor local que saca el correo por un conector agregan una dirección a la cadena. Si no está en SPF y el mensaje no va firmado con DKIM de tu dominio, falla.

Verifica con un mensaje real, no con un validador

Los validadores de DNS te dicen que el registro existe y que se puede leer. No te pueden decir qué concluyó un receptor sobre un mensaje de verdad, que es lo único que importa. Manda una prueba desde el tenant a una dirección de Gmail, abre Mostrar original y lee la cabecera Authentication-Results. Quieres tres cosas a la vez: spf=pass con un smtp.mailfrom de tu dominio, dkim=pass con el header.d= de tu dominio y no de onmicrosoft.com, y dmarc=pass. Dos de tres es donde está la mayoría de los tenants antes de este trabajo, y donde muchos se quedan sin darse cuenta.

Qué agregan las reglas para remitentes masivos

Pasado cierto volumen, los tres registros dejan de ser una buena práctica y se vuelven requisito de entrada. Las guías para remitentes de Google consideran remitente masivo a un dominio que manda cerca de 5,000 mensajes o más en un día a cuentas personales de Gmail, y esos remitentes necesitan SPF, DKIM y un registro DMARC de al menos p=none, mantener la tasa de spam reportado por usuarios por debajo del 0.3 por ciento, y ofrecer la baja en un clic descrita en el RFC 8058. Microsoft publicó un requisito comparable para remitentes de alto volumen hacia direcciones de Outlook.com, Hotmail.com y Live.com: SPF, DKIM y un registro DMARC válido, con el correo que no cumple mandado a Correo no deseado antes de una aplicación más dura. Cruza cualquiera de esos umbrales sin los registros y las fallas se vuelven ruidosas rápido, en forma de rechazos por autenticación y reputación y no de un viaje silencioso a la carpeta de spam.

Cómo ayuda Guanacos Tech

La mayoría de los tenants de Microsoft 365 que revisamos están a dos registros de pasar en todas partes, y los dos que faltan casi siempre son el DKIM del dominio propio y el DMARC. Inventariamos cada remitente desde tus reportes agregados, alineamos uno por uno, y llevamos la política de none a reject en un calendario que no pone en riesgo tus facturas. Si estás migrando hacia o desde Google Workspace, hacemos el mismo trabajo en los dos lados del cambio. Empieza con el diagnóstico de correo gratis o el analizador de DMARC, o agenda una llamada y leemos tus cabeceras contigo.

Fuentes

• Set up SPF to identify valid email sources for your Microsoft 365 domain - Microsoft Learn
• How to use DKIM for email in your custom domain - Microsoft Learn
• Set up DMARC to validate the From address domain - Microsoft Learn
• Enable DMARC reporting for MOERA and parked domains - Microsoft Learn
• External DNS records required for Microsoft 365 - Microsoft Learn
• Email sender guidelines - Gmail Help
• Outlook requirements for high-volume senders - Microsoft Q&A
• RFC 7208, Section 4.6.4 - DNS Lookup Limits
• RFC 8058 - One-Click Unsubscribe

¿Es spam o es rebote?

Antes de buscar culpable, separa dos problemas distintos que la gente mezcla todo el tiempo. Un rebote (bounce) es cuando el mensaje nunca se entrega: el servidor receptor lo rechaza y tú recibes un correo de error, normalmente con un código como 550. Que un correo "llegue a spam" es otra cosa: el mensaje sí se entrega, pero el filtro del destinatario lo manda a la carpeta de correo no deseado en vez de a la bandeja principal, sin avisarte nada a ti.

Esa diferencia importa porque el diagnóstico es distinto. Un rebote casi siempre es un problema de autenticación o de un bloqueo directo, y tú te enteras porque el error regresa. Que caiga en spam es un problema de confianza acumulada, el receptor decidió que ese mensaje en particular, o ese remitente en general, se parece más a correo no deseado que a correo legítimo, y ahí es donde entran las siete causas reales que revisamos abajo. Casi todas se pueden confirmar gratis en menos de diez minutos.

Causa 1: SPF ausente o roto

SPF es el registro DNS que le dice al mundo qué servidores tienen permiso de enviar correo en nombre de tu dominio. Google exige que todo remitente tenga SPF o DKIM configurado correctamente, y si envías 5,000 mensajes o más al día a cuentas personales de Gmail, exige ambos. Sin SPF, o con un SPF que no incluye al servicio que realmente está enviando el correo (tu proveedor de hosting, tu CRM, tu sistema de facturación), el mensaje llega como no autenticado, y Gmail puede rechazarlo directamente con un error 550-5.7.26 o simplemente mandarlo a spam.

Un error común es tener dos registros SPF distintos publicados por accidente, algo que rompe la validación por completo porque el estándar solo permite uno por dominio. Revísalo buscando el TXT record de tu dominio y confirmando que hay exactamente un v=spf1 que incluye a todos tus remitentes reales.

Causa 2: DKIM sin firmar

DKIM agrega una firma criptográfica a cada mensaje que sale, y el receptor la verifica contra una llave pública publicada en tu DNS. En Google Workspace, DKIM viene apagado por dominio hasta que lo activas manualmente desde el Admin Console y publicas la llave, así que si nunca lo configuraste, tu correo sale sin firmar aunque todo lo demás esté bien. Google recomienda llaves de 2048 bits, más seguras que las de 1024, que solo deberías usar si tu proveedor de DNS no soporta la longitud mayor.

Esto se repite igual en Zoho Mail y en cPanel: DKIM no se activa solo, hay que generarlo y publicar el registro TXT correspondiente, con un selector específico (algo como google._domainkey o zoho._domainkey). Revísalo enviando un correo de prueba a una cuenta de Gmail que controles, abriéndolo, y viendo el encabezado Authentication-Results en "Mostrar original": tiene que decir dkim=pass.

Causa 3: DMARC sin alineación

DMARC no reemplaza a SPF ni a DKIM, los conecta con el dominio que el destinatario realmente ve en el campo "De". Según el RFC 7489, para que DMARC pase, el dominio que aprueba SPF o el dominio que firma DKIM tiene que coincidir (alinear) con el dominio organizacional del encabezado "De" visible. Puedes tener SPF y DKIM pasando perfectamente y aun así fallar DMARC si, por ejemplo, tu sistema de facturación firma con DKIM usando su propio dominio en vez del tuyo.

Sin un registro DMARC publicado, ni siquiera hay una regla que le diga al receptor qué hacer con el correo que no alinea, así que muchos proveedores lo tratan con más sospecha por default. Publicar un DMARC en modo p=none no bloquea nada, pero te empieza a mandar reportes que muestran exactamente qué remitentes están fallando la alineación, información que sin DMARC simplemente no tienes.

Causa 4: reputación del dominio o de la IP

Aunque SPF, DKIM y DMARC estén perfectos, el historial de envío de tu dominio o de la IP que usas puede estar dañado. Google Postmaster Tools califica esto como Alta, Media, Baja o Mala: Alta significa "un historial de tasas de spam muy bajas", Mala significa que el correo "casi siempre se marca como spam o se rechaza". La tasa de spam que Google vigila es el porcentaje de tus mensajes que la gente marca manualmente como spam después de recibirlos, y la guía oficial es mantenerla debajo de 0.10% y nunca llegar a 0.30%.

Si usas hosting compartido, Microsoft 365 en un plan básico o cualquier plataforma donde compartes IP con otros clientes, tu reputación puede caer por culpa de otro remitente en esa misma IP. Google lo dice de forma directa: "la actividad de cualquier remitente que use una dirección IP compartida afecta la reputación de todos los remitentes" en ella. Revísalo dándote de alta en Google Postmaster Tools, que muestra estos paneles una vez que tienes volumen suficiente de correo autenticado hacia Gmail.

Causa 5: contenido y listas

Más allá de la autenticación, el filtro de spam también evalúa qué estás enviando y a quién. Listas viejas que ya nadie abre son el problema más común: la gente que ya no reconoce al remitente es la que más presiona "reportar spam" en vez de simplemente ignorar o darse de baja, y eso empuja tu tasa de spam hacia arriba con el tiempo. El contenido también cuenta: asuntos exagerados, enlaces acortados, imágenes sin texto, o mandar el mismo mensaje idéntico a miles de personas de golpe son señales que los filtros modernos ya reconocen.

Revísalo mirando tus métricas de apertura por segmento. Si un grupo grande de contactos no ha abierto nada en 90 o 180 días, sácalo del envío activo antes de que arrastre al resto.

Causa 6: remitentes externos no autorizados

Esta es la causa que más se escapa porque no está en tu bandeja, está en herramientas de terceros que envían correo "en tu nombre" sin que lo hayas revisado: el sistema de facturación electrónica, el CRM, la tienda en línea, la plataforma de cobros. Si ese servicio envía usando tu dominio en el "De" pero no está en tu SPF ni firma con un DKIM alineado, cada correo que manda cuenta en contra de tu reputación general, aunque tú nunca hayas dado clic en "enviar".

Revísalo haciendo una lista de todo lo que envía correo con tu dominio (no solo tu bandeja de Gmail o Workspace) y confirmando que cada uno esté autorizado en SPF y firmando con DKIM propio.

Causa 7: dominio nuevo

Un dominio recién registrado, o uno que nunca ha enviado volumen real a Gmail, no tiene mala reputación, tiene reputación en cero. Postmaster Tools puede simplemente no mostrar datos todavía. El problema es que enviar un lote grande de golpe desde un dominio así se ve prácticamente igual a un atacante armando un dominio desechable para mandar spam, y los filtros lo tratan con la misma sospecha.

Revísalo con paciencia: empieza con volumen bajo hacia contactos que sí van a abrir y responder, sube despacio, y deja que el dominio construya historial antes de depender de él para algo urgente como una campaña grande o una migración completa.

Revísalo ahora, gratis

Las primeras seis causas se pueden confirmar sin pagar nada: revisa tu SPF y DKIM con el diagnóstico de correo de Guanacos Tech, lee un encabezado real con el analizador de encabezados, y si ya tienes DMARC publicado, revisa los reportes con el analizador DMARC. Entre los tres tienes visibilidad de casi todo lo que revisamos arriba en una sola sesión.

Cómo ayuda Guanacos Tech

La mayoría de los casos que revisamos no tienen una sola causa, tienen dos o tres encimadas: un DKIM que nunca se activó, una plataforma de facturación que nadie autorizó en SPF, y una lista que se dejó de limpiar hace un año. Hacemos el diagnóstico completo, arreglamos el DNS en el orden correcto y nos quedamos monitoreando hasta que la reputación se estabilice. Si quieres que lo revisemos juntos, agenda una llamada gratuita.

Fuentes

• Configura DKIM para evitar la suplantación - Ayuda de administración de Google Workspace
• RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• Guías de remitentes de correo - Ayuda de administración de Google Workspace
• Paneles de Postmaster Tools - Ayuda de Gmail
• Evitar que el correo a usuarios de Gmail se bloquee o se marque como spam

Por qué existe el límite

SPF no es una lista de direcciones IP que publicas una vez. Es un pequeño programa que el servidor receptor tiene que ejecutar: obtiene tu registro TXT y luego sigue cada mecanismo include, a, mx, ptr y exists, más cualquier modificador redirect, y cada uno de esos dispara su propia consulta DNS. El RFC 7208, sección 4.6.4, pone el tope en 10: "las implementaciones de SPF DEBEN limitar el número total de esos términos a 10 durante la evaluación de SPF, para evitar una carga irrazonable sobre el DNS". Si lo cruzas, "la implementación DEBE devolver permerror".

PermError no es un fallo suave. No significa "trátalo como neutral", como pasa cuando falta el registro. La mayoría de los receptores grandes, Gmail incluido, tratan un SPF PermError como si no hubiera SPF válido en absoluto, y las reglas de remitentes masivos de Gmail exigen que SPF o DKIM pasen, así que un dominio que se pasa del presupuesto de consultas puede empezar a rebotar con errores de correo sin autenticar, aunque el registro se vea bien a simple vista.

Dentro de esa misma regla hay dos límites relacionados. Cada mecanismo MX que uses no puede requerir consultar más de 10 registros A o AAAA para resolverse, y el mismo tope de 10 aplica a las consultas PTR. El RFC 7208 también recomienda que las implementaciones limiten las "consultas vacías" (void lookups), es decir, las que no devuelven nada, a dos, y que devuelvan permerror después de eso. En la práctica, esto significa que un registro inflado puede fallar antes de llegar a contar las 10 consultas reales, si suficientes de ellas regresan vacías.

Cuenta tus consultas con honestidad

El error más común en los registros SPF es contar solo los include del primer nivel y detenerse ahí. El límite no es "10 includes", son 10 consultas DNS en total durante toda la evaluación, y un include puede a su vez contener más includes, cada uno con su propio costo.

Toma un registro que parece inofensivo:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:spf.zoho.com redirect=_hspf.hubspot.com a mx include:sendgrid.net ~all

Léelo de izquierda a derecha contra la lista del RFC de lo que cuenta (include, a, mx, ptr, exists, redirect): include:_spf.google.com es 1, include:spf.protection.outlook.com es 1, include:servers.mcsv.net es 1, include:spf.zoho.com es 1, el mecanismo a es 1, el mecanismo mx es 1, e include:sendgrid.net es 1. Van 7 antes de siquiera tocar el redirect de HubSpot. La cadena SPF de HubSpot no es plana. Seguirla tal como está publicada hoy significa que redirect=_hspf.hubspot.com (1 consulta) resuelve a un registro que a su vez incluye _hspf1.hubspot.com (1 más), que incluye _hspf2.hubspot.com (1 más), que incluye otro sub-registro. Esa sola cadena de redirect agrega 4 consultas o más encima de las 7, llevando el total a 11 o más, por encima del límite, en un registro que parecía tener seis o siete entradas modestas.

Los proveedores más comunes

No todos los proveedores cuestan lo mismo. Tal como está publicado hoy, include:_spf.google.com de Google Workspace resuelve directamente a una lista plana de rangos de IP, sin includes anidados, así que cuesta exactamente 1 consulta. include:spf.protection.outlook.com de Microsoft 365 tiene la misma forma: plano, 1 consulta. include:servers.mcsv.net de Mailchimp también es plano, 1 consulta. include:spf.zoho.com de Zoho igualmente resuelve a una sola lista plana, 1 consulta, aunque la propia documentación de Zoho a veces muestra un registro combinado con includes adicionales como zcsend.net para su producto de marketing, cada uno con su propio costo. HubSpot es la excepción: su SPF es una cadena de redirect e includes de varios niveles, y seguirla completa cuesta 4 consultas o más por sí sola, más que cualquier otro proveedor común en una pila típica.

Esto cambia con el tiempo. Los proveedores reestructuran su infraestructura SPF sin avisar, y uno que hoy es plano puede agregar includes anidados el próximo trimestre. Trata cualquier conteo, incluidos los de arriba, como algo que hay que reverificar con una herramienta en vivo, no como algo para grabar en una hoja de cálculo.

Arreglo 1: elimina includes muertos

La ganancia más rápida casi siempre es borrar mecanismos que ya nadie usa. Los registros SPF se acumulan igual que las listas viejas de copia: una herramienta de marketing que cancelaste hace dos años, una pasarela de fax a correo que nadie recuerda, un relay local que se dio de baja cuando migraste a Workspace o M365. Saca el registro actual, compara cada include contra un remitente que realmente esté enviando hoy, y borra lo que no esté activo. Solo esto resuelve una buena parte de los casos de "demasiadas consultas" sin tocar nada más.

Arreglo 2: mueve el costo a un subdominio

Cada subdominio tiene su propia evaluación de SPF y su propio presupuesto de 10 consultas. Si tu dominio raíz envía correo transaccional por Workspace y correo de marketing por HubSpot y Mailchimp, mover los envíos de marketing a un subdominio dedicado, por ejemplo mail.example.com o news.example.com, divide un presupuesto de 10 consultas saturado en dos presupuestos separados. Este es también el arreglo que recomienda dmarcian, la empresa que construyó y luego retiró su propia herramienta de aplanado de SPF, en lugar de aplanar: segmentar remitentes por subdominio da "mejor control, menor superficie de ataque, eficiencia operativa y resiliencia de reputación" en vez de un registro compartido e inflado.

Arreglo 3: aplanado, y por qué trae su propio riesgo

Aplanar reemplaza un include por los rangos ip4/ip6 literales a los que resuelve hoy, bajando el conteo de consultas a casi cero. Funciona, hasta que el proveedor cambia sus IPs de envío, algo que todos los grandes ESP hacen de vez en cuando sin publicar un changelog. Un registro aplanado se vuelve obsoleto en cuanto eso pasa, y el correo desde las nuevas IPs del proveedor empieza a fallar SPF en silencio, muchas veces antes de que alguien note el patrón de rebotes. dmarcian corrió el aplanado como experimento público durante años y lo cerró en marzo de 2023, concluyendo que la práctica cambia un problema operativo por uno de seguridad: un registro sobre-autorizado y rara vez auditado son "entradas innecesarias en registros SPF" que amplían la superficie de ataque en vez de reducirla. Si aplanas, trátalo como una solución temporal con una revisión programada en el calendario, no como un arreglo permanente.

Arreglo 4: apóyate en la alineación de DKIM en vez de forzar a SPF a cubrir todo

DMARC solo necesita que SPF o DKIM pasen y alineen, no ambos. Si un remitente que no puedes quitar de SPF sin romper el correo está bien firmado con DKIM y con dominio alineado, DMARC sigue pasando para ese remitente aunque SPF por sí solo exceda el límite de consultas o falle directamente. Esto no elimina el riesgo del PermError, un SPF PermError sigue siendo tratado como un fallo total de SPF por la mayoría de los receptores sin importar lo que DMARC decida al final, así que es una mitigación para la alineación, no un sustituto de bajar el conteo por debajo de 10. Prioriza configurar DKIM para cada remitente que conserves, y úsalo como red de seguridad mientras bajas el conteo de SPF, no como excusa para ignorarlo.

Verifica antes de darlo por hecho

Publica el cambio y luego revisa el registro en vivo en vez de confiar en tu propio conteo. Un registro que se veía bien en papel puede seguir excediendo el límite una vez que sigues una cadena de redirect como la de HubSpot hasta el final, y un error de tipeo en un include puede romper en silencio todo el registro en vez de solo esa entrada. Haz un envío de prueba real con el diagnóstico de correo de Guanacos Tech y confirma que SPF devuelve pass, no permerror ni none, en un mensaje real.

Cómo ayuda Guanacos Tech

Vemos esto sobre todo en empresas que cambiaron de plataforma de correo o de marketing dos o tres veces a lo largo de los años y nunca limpiaron el rastro. Auditamos la cadena completa de consultas, incluyendo redirects e includes anidados que la mayoría de los verificadores de SPF dejan de contar después del primer nivel, la bajamos de 10 en el orden correcto, y configuramos la alineación de DKIM como cobertura de respaldo para lo que tenga que quedarse. Si tu registro SPF sigue devolviendo PermError, agenda una llamada y lo revisamos juntos.

Fuentes

• RFC 7208, sección 4.6.4 - DNS Lookup Limits
• Acerca de los registros SPF - Ayuda de administración de Google Workspace
• Concluding the Experiment: SPF Flattening - dmarcian
• Set up SPF to identify valid email sources for Microsoft 365 - Microsoft Learn

Hiciste todo bien. El doble factor está obligatorio en cada cuenta. Nadie reutilizó una contraseña de una filtración de 2019. Y aun así el atacante entró, leyó el correo del director financiero durante una semana y redirigió una transferencia.

Cuando esto pasa, el análisis posterior casi nunca encuentra una contraseña descifrada ni una solicitud de MFA vencida. Encuentra una sesión de navegador robada. El inicio de sesión ya ocurrió, en un dispositivo legítimo, hecho por el usuario real. El atacante simplemente entró cargando la prueba.

Por qué el 2FA dejó de alcanzar sin que nadie lo dijera

Esta es la parte que a casi ningún administrador le explicaron con claridad. La autenticación de dos factores protege el momento en que inicias sesión. Una vez adentro, tu navegador guarda una cookie de sesión. Esa cookie es la credencial que dice "sí, esta persona inició sesión", y tu navegador la presenta en cada solicitud para que no tengas que escribir la contraseña y tocar el teléfono cuarenta veces al día.

Un malware llamado infostealer va tras esa credencial. Corre en una laptop infectada, copia las cookies de sesión activas del navegador y se las lleva. El atacante carga esas cookies en su propio navegador y aterriza dentro de la cuenta ya autenticado. Sin solicitud de contraseña. Sin reto de MFA. No hay nada que retar, porque para el sistema la sesión ya estaba aprobada.

No es una técnica marginal. La investigación de identidad de Constella encontró que los infostealers procesaron 51,7 millones de paquetes en 2025, un salto del 72% frente al año anterior, y buena parte de por qué esos paquetes valen tanto es que llevan cookies de sesión activas que esquivan el MFA de plano. SpyCloud, trabajando con un conjunto de datos distinto, recapturó 8.600 millones de cookies y artefactos de sesión robados de infecciones de malware, y contabilizó 1,17 millones de registros de malware que contenían tanto credenciales corporativas como cookies de sesión activas. Las familias que hacen la mayor parte de esto a principios de 2026 son LummaC2, ACRStealer, StealC y Vidar. Una sola máquina infectada en tu organización puede convertirse en una sesión autenticada en manos ajenas.

Qué activó Google, y cuándo

El 28 de mayo de 2026, Google anunció que las Device Bound Session Credentials (DBSC) en el navegador Chrome sobre Windows ya están disponibles de forma general y activadas por defecto para los usuarios de Google Workspace. El despliegue empezó de manera gradual el 25 de mayo y puede tardar hasta 60 días en aparecer por completo entre Rapid Release y Scheduled Release.

La idea detrás de DBSC es simple una vez que le quitas el acrónimo. Cuando se crea una sesión, Chrome genera una clave criptográfica privada y la guarda dentro del TPM del dispositivo, un chip de seguridad integrado en el hardware de la máquina. La cookie de sesión queda atada a esa clave. A partir de ahí, cada vez que la sesión se renueva, Chrome tiene que demostrar que todavía posee la clave del dispositivo que corresponde. Una cookie copiada de esa laptop no trae la clave a la que estaba atada, así que en la máquina del atacante simplemente falla la validación. La credencial robada ya no abre la puerta.

Si el sistema detecta que una sesión no coincide con el dispositivo al que estaba atada, se le pide al usuario que vuelva a iniciar sesión. El usuario honesto se encoge de hombros y se reautentica. El atacante queda trabado.

Dos cosas importan para tu presión arterial aquí. Está activado por defecto, para todos los clientes de Workspace, los suscriptores de Workspace Individual y las cuentas personales de Google. No hay control de administrador para deshabilitarlo ni ajuste de usuario final que cambiar. No tienes que desplegar nada para obtener la protección base.

La letra chica: hasta dónde no llega DBSC

Es un control fuerte, no un campo de fuerza. Conocer sus bordes es todo el trabajo, porque los atacantes se mueven hacia cualquier cosa que dejaste sin cubrir.

• Solo Chrome y Windows. Necesita Chrome 146 o posterior sobre Windows, y un TPM para guardar las claves. El TPM es estándar en la mayoría del hardware con Windows 11, pero las máquinas viejas o sin gestionar pueden no calificar.
• macOS, móviles y otros navegadores siguen expuestos. Una sesión robada de Safari, de un teléfono, o de Firefox o Edge no recibe esta atadura al dispositivo. El análisis de Constella señala lo mismo: el alcance de Chrome sobre Windows deja sobre la mesa a macOS, a los móviles, a otros navegadores y al robo de tokens fuera del navegador.
• Los tokens fuera del navegador no están cubiertos. Los tokens OAuth y las credenciales de aplicaciones que viven fuera del navegador son un problema aparte que DBSC no toca.

Lee esa lista como un mapa de dónde todavía necesitas otras defensas, no como una razón para descartar DBSC. Para el lugar donde realmente ocurre la mayoría del robo de credenciales, la laptop corporativa con Windows corriendo Chrome, la cookie de mayor valor acaba de volverse mucho menos útil de robar.

Qué debería hacer realmente un administrador

No se requiere nada para activar DBSC. Pero "no se requiere nada" y "no hay nada que valga la pena hacer" son cosas distintas. Unos pocos movimientos convierten un valor por defecto pasivo en algo que puedes ver y dirigir.

Vigila los eventos de binding. En la herramienta de investigación de seguridad, DBSC escribe registros de auditoría que puedes revisar. Los eventos de registro de usuario muestran DBSC key binding y DBSC key validation como Succeeded o Failed. Los eventos de registro de Access Evaluation exponen solicitudes denegadas con códigos como DBSC_BOUND_COOKIE_MISSING, DBSC_BOUND_COOKIE_CORRUPTED y DBSC_BOUND_COOKIE_EXPIRED. Un pico de validaciones fallidas es una señal que vale la pena seguir, no ruido que silenciar.

Evalúa exigir sesiones atadas. DBSC funciona junto con Context-Aware Access. Si quieres ir más allá del valor por defecto, puedes usar Context-Aware Access para requerir una sesión atada y bloquear que las no atadas lleguen a aplicaciones específicas. Tiene sentido para tus sistemas más sensibles; pruébalo antes de apuntarlo a todo el mundo, porque puede dejar afuera a cualquiera que esté en un navegador, sistema operativo o dispositivo no compatible.

Estandariza la flota para que los dispositivos realmente califiquen. DBSC solo ayuda en máquinas que cumplen el listón. Chrome gestionado, más Windows 11 con un TPM funcionando y versiones actuales del navegador, es lo que hace que la protección sea real en lugar de teórica. Si tu flota es una colcha de retazos de laptops personales y versiones viejas de Chrome, esa es la brecha que hay que cerrar primero.

Sigue agregando capas. Passkeys resistentes al phishing para reforzar el inicio de sesión en sí, Context-Aware Access para condicionar por postura del dispositivo, e higiene básica de endpoints para que los infostealers ni siquiera puedan ejecutarse. DBSC le quita un arma de las manos al atacante. No se las quita todas.

La conclusión honesta

El robo de sesión era la brecha silenciosa detrás de muchos incidentes del tipo "pero teníamos MFA", y Google acaba de cerrar una buena porción de eso gratis, en la plataforma donde vive la mayoría de tus usuarios. Es una noticia genuinamente buena. También es el tipo de cambio que es fácil malinterpretar como "ya terminamos". No terminaste. Estás mejor protegido en Chrome y Windows, y ahora tienes registros que lo demuestran y una lista clara de lo que todavía falta cubrir.

Si prefieres no armar todo esto por tu cuenta, esta es la clase de auditoría que hacemos cada semana: confirmar que DBSC está aterrizando de verdad en tu flota, conectar el monitoreo para que los bindings fallidos lleguen a una persona, decidir si la aplicación de Context-Aware Access encaja con tu riesgo, y encontrar las brechas de macOS y móviles antes de que lo haga alguien más. Somos un equipo independiente de Workspace y Cloud, no un revendedor empujando una licencia. Si tu última revisión de seguridad es anterior a todo esto, es un buen momento para una mirada nueva.

Probablemente has notado que algunas empresas tienen su logotipo oficial mostrado directamente en la bandeja de Gmail antes incluso de abrir el correo. Esto no es una función premium de Google: es un estándar de autenticación de correo llamado BIMI.

Brand Indicators for Message Identification (BIMI)

BIMI exige que tu dominio tenga una política DMARC estricta (p=quarantine o p=reject). Una vez que demuestras que tu dominio está protegido contra suplantación, los proveedores de correo te recompensan mostrando tu logotipo verificado.

El enfoque de Guanacos Tech

Nos especializamos en limpiar tus registros SPF, DKIM y DMARC para llevarte a aplicación estricta, allanando el camino para implementar BIMI y maximizar la entrega de tu correo.

Si has estado siguiendo las novedades de Google Workspace, podrías estar buscando "Duet AI". Ese nombre quedó oficialmente retirado. A finales de 2025, Google unificó sus capacidades de IA más potentes bajo la marca Gemini, lanzando Gemini Enterprise como el nuevo estándar para la IA de negocio.

Gemini Enterprise no es solo un cambio de marca; es un salto enorme en capacidad, razonamiento e integración.

¿Por qué el cambio?

Google quería llevar su modelo más capaz, Gemini Ultra 1.0 (y ahora 1.5 Pro), directamente a los usuarios de Workspace. Duet AI era excelente, pero Gemini Enterprise está diseñado para ser un agente: un compañero que puede ejecutar tareas complejas y de varios pasos en Gmail, Docs, Sheets y Slides.

Funciones clave para empresas

• Ventana de contexto: Gemini 1.5 Pro tiene una ventana de contexto enorme, lo que le permite "leer" y razonar sobre miles de líneas de código o cientos de documentos en segundos.
• Integración en panel lateral: vive en el panel lateral de tus apps favoritas. En Gmail, puedes pedirle "resume este hilo y redacta una respuesta". En Slides, puede "generar visuales para esta diapositiva".
• Seguridad de nivel empresarial: a diferencia de la versión de consumidor de Gemini, la edición Enterprise garantiza que tus datos nunca se usen para entrenar los modelos de Google. Tu propiedad intelectual sigue siendo tuya.

¿Vale la pena la actualización?

Para los equipos que dedican horas a analizar datos o redactar contenido, el ROI es inmediato. La capacidad de fundamentar las respuestas de Gemini en los datos de tu propia empresa (archivos en Drive, correos) lo hace mucho más útil que un chatbot genérico.

Estamos ayudando a clientes a desplegar Gemini Enterprise con políticas de gobernanza de datos adecuadas. Si te interesa un piloto, cuéntanos.

Si notas que tus tasas de apertura están cayendo o que tus correos llegan a spam, presta atención. En 2026, Google volvió a endurecer sus requisitos para remitentes, y una nueva herramienta llamada AI Security Add-on se está volviendo esencial para usuarios Enterprise.

El nuevo AI Security Add-on

Lanzado recientemente, este add-on para Google Workspace usa modelos de IA con preservación de privacidad para clasificar y proteger automáticamente archivos sensibles en Google Drive. Pero, lo más importante para los administradores de correo, mejora las defensas anti-spam y anti-malware en Gmail.

Funciona como una segunda capa de defensa, identificando intentos de phishing complejos que los filtros estándar podrían pasar por alto. Si manejas activos financieros o de datos sensibles, este add-on ($10/usuario/mes) es una mejora recomendada.

DMARC ya no es opcional

Lo hemos dicho antes, pero vale la pena repetirlo: si envías correos masivos (5,000+ por día), debes tener una política DMARC en su lugar.

• SPF y DKIM: Deben ser válidos.
• DMARC: Debe estar configurado al menos en p=none (monitoreo), pero idealmente en p=quarantine o p=reject.
• Cancelación de suscripción con un clic: Los correos de marketing deben soportar cabeceras conformes al RFC para facilitar la baja.

¿No sabes el estado de tu DMARC? Usa nuestro Diagnóstico de entrega gratis para revisar tu puntaje de riesgo al instante.