Soluciona los emails de Google Workspace que van a spam

Mientras no generes una clave en la consola de administración y hagas clic en Iniciar autenticación, ninguna firma DKIM lleva tu propio dominio: DMARC se queda sin nada con lo que alinearse por el lado de DKIM y tiene que pasar apoyándose solo en SPF, que se rompe en el primer reenvío. Esta guía cubre eso y el resto de lo que falla en Workspace: el registro SPF único y el techo de diez etiquetas include:, los requisitos de Gmail para remitentes masivos, los límites de un buzón que no es una plataforma de envío, la diferencia entre smtp.gmail.com y el servicio de retransmisión SMTP, y cómo comprobarlo con un envío real a una dirección de prueba de Unspam. Lo que te dice de verdad si has terminado es el valor d= de la cabecera DKIM-Signature de uno de tus propios mensajes.

Por qué los emails de Google Workspace acaban en spam.

01

DKIM está desactivado hasta que generas la clave tú mismo

Google Workspace no genera una clave DKIM para tu dominio en el caso general, y Google documenta solo dos excepciones: si tu proveedor de dominio es Squarespace, la clave se crea y se añade a tus registros DNS de forma automática, y puede que no necesites configurar DKIM si tu dominio ya lo trae por defecto o si compraste el dominio a un partner de Google al registrarte.

02

Solo se permite un registro SPF, y el segundo se cuela sin querer

Para un dominio que envía únicamente a través de Workspace, Google publica exactamente un valor: v=spf1 include:_spf.google.com ~all, como registro TXT en el dominio raíz y con el campo de host en @. Hay dos formas de reventarlo. Un segundo registro SPF con el mismo nombre es un error permanente y no se usa ninguno de los dos, que es justo lo que pasa la tercera vez que una herramienta nueva te pide añadir este registro TXT. Y Google documenta un techo de diez etiquetas include:, al que una herramienta de soporte, una app de facturación y una plataforma de marketing llegan mucho antes de lo que nadie espera.

03

Para Gmail eres un remitente masivo y nunca publicaste DMARC

Las directrices para remitentes de Gmail te tratan como remitente masivo en cuanto envías más de 5.000 mensajes al día a cuentas personales de Gmail, contados por dominio principal. El propio ejemplo de Google son 2.500 desde solarmora.com más 2.500 desde promotions.solarmora.com, que juntos cruzan la línea. Los remitentes masivos tienen que publicar DMARC, aunque la política sea p=none, y el dominio del From debe alinearse con el dominio de SPF o con el de DKIM. Google también afirma que la condición de remitente masivo no caduca, y que el correo que incumple los requisitos acaba en la carpeta de spam o se rechaza con un error 5.7.26.

04

Un buzón no es una plataforma de envío, y los límites muerden a mitad de campaña

Las cuentas de prueba están limitadas a 500 mensajes y 500 destinatarios externos únicos al día. Una cuenta de pago sube a 2.000 mensajes diarios, pero también topa en 3.000 destinatarios externos y 2.000 destinatarios externos únicos, y los mensajes enviados por SMTP, POP o IMAP admiten como mucho 100 destinatarios cada uno. Los contadores corren sobre una ventana móvil de 24 horas, no sobre el día natural, así que nada se reinicia a medianoche y un envío que arrancó bien se corta por la mitad.

05

Tu aplicación sale por el host de Google equivocado

smtp.gmail.com se autentica con la dirección de una única cuenta más una contraseña de aplicación, y Google lo limita a 2.000 mensajes al día, así que es una ruta de buzón y no una ruta de aplicación.

06

Algo reescribe tus mensajes después de que Google los firme

DKIM firma un hash del cuerpo, así que cualquier modificación posterior a la firma la invalida y el receptor registra body hash did not verify en la cabecera Authentication-Results. La página de resolución de problemas de DKIM de Google señala las pasarelas de salida como causa habitual, en concreto las que añaden un pie de página a cada mensaje saliente, y te pide que te asegures de que la pasarela no modifica el correo de salida. Esa misma página apunta que Gmail solo evalúa las cinco primeras firmas DKIM de un mensaje, de modo que una firma válida que queda en sexto lugar no se comprueba nunca.

Cómo autentica Google Workspace tu correo.

Google no escribe los registros DNS por ti. Todos los registros de abajo viven en tu proveedor de dominio, y la consola de administración se limita a generar los valores y luego comprobarlos. Primero van SPF y DKIM, y Google te pide esperar 48 horas después de esos dos antes de añadir DMARC. Todo el trabajo de DKIM ocurre en Aplicaciones > Google Workspace > Gmail > Autenticar correo electrónico, y tienes que haber iniciado sesión como superadministrador.

registro por defecto el problema la solución
SPF No hay nada publicado salvo que lo hayas publicado tú. Añadir los registros MX de Google no añade SPF. Sin registro no hay un pase de SPF con el que alinearse. Con dos registros en el mismo nombre no se usa ninguno. Pasadas las diez etiquetas include:, el registro deja de evaluarse y todos tus remitentes fallan a la vez. Publica un único registro TXT en el dominio raíz, con el campo de host en @ y el valor v=spf1 include:_spf.google.com ~all. Funde a cualquier otro remitente dentro de ese mismo registro en lugar de añadir un segundo. Google recomienda ~all antes que -all, y avisa de que los cambios de SPF pueden tardar hasta 48 horas en surtir efecto.
DKIM Desactivado en la mayoría de los dominios. Google recoge dos excepciones: un dominio alojado en Squarespace recibe la clave creada y añadida automáticamente, y un dominio que ya trae DKIM por defecto o que compraste a un partner de Google al registrarte puede no necesitar configuración alguna. En el resto de los casos, después de activar Gmail tienes que esperar de 24 a 72 horas antes de que la consola de administración genere una clave y, hasta que termines, la página Autenticar correo electrónico te dice que actualices los registros DNS de este dominio. Sin una clave propia no hay ninguna firma que lleve tu dominio, así que DMARC tiene que pasar apoyándose solo en SPF. Eso aguanta hasta el primer reenvío o la primera lista de correo, que rompe SPF y se lleva por delante el resultado de DMARC. En Aplicaciones > Google Workspace > Gmail > Autenticar correo electrónico, selecciona el dominio, deja el selector de prefijo por defecto google, elige la longitud de clave de 2048 bits si tu proveedor de DNS la admite, publica el registro TXT en google._domainkey y vuelve para hacer clic en Iniciar autenticación. El estado pasa a Autenticando correo electrónico con DKIM en cuanto Google lo verifica.
DMARC No está publicado, y Google no lo publica nunca por ti. Gmail exige un registro DMARC a los remitentes masivos, y Google te pide dejar pasar 48 horas desde que configuras SPF o DKIM antes de añadir uno, para que no estés aplicando una política contra una autenticación que todavía no se ha propagado. Publica un registro TXT en _dmarc.yourdomain.com, empezando por v=DMARC1; p=none con una dirección rua, lee los informes agregados y después endurece a p=quarantine y a p=reject. Apunta rua a un grupo o a un buzón dedicado: Google avisa de que las organizaciones grandes pueden recibir cientos o miles de informes al día.
Additional domains La página Autenticar correo electrónico tiene un menú Dominio seleccionado con los dominios de tu cuenta, y cada uno arranca sin clave propia. Los equipos generan la clave del dominio principal, luego envían desde un segundo dominio que no tiene ninguna, y cada mensaje que sale de él falla la alineación DKIM mientras el dominio principal luce impecable. La instrucción de Google es explícita: si estás configurando DKIM para más de un dominio, completa los pasos en cada dominio y consigue una clave DKIM única desde la consola de administración para cada uno. Publica google._domainkey en todos los dominios desde los que envíes, no solo en el principal.

Una vez actualizados estos registros, confirma que pasan con el comprobador de SPF, el comprobador de DKIM y el comprobador de DMARC gratuitos de Unspam.

Cómo probar una campaña de Google Workspace con Unspam.

Unspam no se conecta a Google Workspace. No tiene integración con la API de Gmail, ni acceso de administrador, y nunca inicia sesión en tu cuenta. Recibes una dirección de prueba, le envías un mensaje real igual que lo reciben tus destinatarios y Unspam lee lo que llegó. Si quieres que la prueba se repita de forma periódica, puedes facilitar credenciales SMTP para las pruebas automáticas de Inbox Placement, y esa es la única credencial que Unspam llega a guardar.

  1. 01

    Consigue tu dirección de prueba de Unspam y pega el ID de prueba

    Inicia una prueba antispam o una prueba de Inbox Placement en Unspam y copia la dirección que genera. Las pruebas de Inbox Placement entregan en buzones de prueba de Gmail, Outlook, Yahoo y otros cinco proveedores, e informan de dónde aterrizó cada copia. Una prueba de Inbox Placement también genera un ID de prueba. Pégalo en el asunto o en el cuerpo antes de enviar, o el mensaje llegará a los buzones de prueba y no se asociará nunca a tu prueba.

  2. 02

    Envía desde la cuenta y la ruta que ven de verdad tus destinatarios

    Si el correo que te preocupa lo escribe una persona en Gmail, mándalo como ese usuario y no desde tu cuenta de superadministrador, que suele arrastrar otras firmas, otros grupos y otro historial. Si es una aplicación, dispara la aplicación para que el mensaje salga por el host que usa en producción, smtp.gmail.com o smtp-relay.gmail.com. La ruta cambia el resultado: la retransmisión deja que una aplicación envíe como cualquier dirección de tu organización, mientras que smtp.gmail.com obliga a que el From sea el de la cuenta autenticada.

  3. 03

    Lee los veredictos de autenticación y fíjate bien en d=

    En el informe de Unspam, revisa los resultados de SPF, DKIM y DMARC. El dominio firmante es la pista. Si d= es un subdominio de gappssmtp.com en lugar de tu propio dominio, nunca terminaste los pasos de la consola de administración, y DMARC se está apoyando solo en SPF, si es que pasa. El mismo informe puntúa el contenido, los enlaces y las cabeceras, así que verás si la autenticación es toda la historia o solo la primera parte.

  4. 04

    Lanza la prueba de Inbox Placement para ver el reparto por proveedor

    Una puntuación de spam te dice cómo califica el mensaje un filtro. Una prueba de Inbox Placement te dice dónde aterrizaron de verdad las copias en los proveedores de los buzones de prueba, que es lo que estabas preguntando. El reparto rara vez es uniforme: un dominio en el que Gmail confía desde hace años puede seguir filtrándose en otro sitio, y ese patrón apunta a la reputación y al contenido, no a tu DNS.

  5. 05

    Cambia una sola cosa, espera y vuelve a probar

    Aquí la parte lenta es el DNS. Google dice que los cambios de SPF pueden tardar hasta 48 horas, y que la consola de administración puede seguir mostrando el aviso de DNS hasta 48 horas después de que añadieras correctamente el registro DKIM. Verifica los valores publicados con las herramientas Dig y Check MX de Google Admin Toolbox en lugar de fiarte del aviso, y después envía otra vez a una dirección de prueba nueva. Si tu volumen da para ello, añade el dominio a Postmaster Tools y vigila la tasa de spam: Gmail te pide mantenerla por debajo del 0,10% y no llegar nunca al 0,30%.

La misma prueba renderiza tu campaña en más de 50 clientes de correo reales, entre ellos Gmail, Outlook, Apple Mail, iPhone y Android, cada uno en modo claro y oscuro, mediante vistas previas en clientes de correo, para que confirmes la llegada a la bandeja de entrada y el renderizado de una sola vez.

Funciones de Google Workspace que afectan a la entrega sin que lo notes.

El aviso de la consola de administración sobrevive al arreglo

La propia documentación de Google dice que la página Autenticar correo electrónico puede seguir pidiéndote que actualices tus registros DNS hasta 48 horas después de que hayas añadido el registro TXT correcto, y por separado te advierte de que no hagas clic en Iniciar autenticación antes de que el registro esté publicado de verdad. Trata el aviso como decoración, no como diagnóstico. Confirma el valor en vivo con la herramienta Dig de Admin Toolbox y lee la cabecera Authentication-Results de un mensaje real buscando DKIM=pass.

Una clave de 2048 bits no cabe en una sola cadena TXT

El DNS limita cada cadena de caracteres a 255 caracteres y una clave de 2048 bits es más larga que eso. La solución de Google es repartir los caracteres de la clave en varias cadenas de texto, cada una con sus propias comillas, dentro de un mismo registro. Algunos paneles de DNS lo hacen por ti, otros rechazan la entrada y otros la aceptan y guardan un valor truncado, que es el peor desenlace porque el registro parece publicado y no verifica nunca. Si tu proveedor de verdad no puede almacenarla, Google ofrece la opción de 1024 bits justo para este caso.

La retransmisión SMTP reescribe el remitente del sobre

Google documenta que, si el remitente no pertenece a uno de tus dominios, la retransmisión cambia el remitente del sobre de user@domain_you_don't_own a postmaster@your_domain. Los rebotes vuelven entonces a tu dirección postmaster y el Return-Path deja de coincidir con el From. Google marca además la opción Cualquier dirección como no recomendada, porque te hace más vulnerable al abuso, ya sea por software malicioso en los dispositivos de tus usuarios o por una configuración SMTP incorrecta.

Probar de Workspace a Workspace no demuestra nada

Google lo dice sin rodeos: las directrices para remitentes de correo electrónico no se aplican a los mensajes enviados a cuentas de Google Workspace. El correo que mandas a un compañero de tu propio dominio, o a otra empresa que también usa Workspace, no se califica igual que el correo dirigido a una cuenta personal de Gmail. Si tu única prueba es tu propia bandeja de entrada, estás probando el único camino que no iba a fallar. Envía a buzones de prueba en proveedores de consumo reales.

Con qué se encuentran los remitentes reales de Google Workspace.

Los problemas de entregabilidad que más sufren los remitentes de Google Workspace, cada uno con la solución que lo resuelve.

Añadí el registro DKIM hace dos días y la consola de administración sigue diciéndome que actualice mis registros DNS. ¿Qué he roto?

Esto lo producen dos cosas distintas. La documentación de Google dice que el mensaje puede persistir hasta 48 horas después de añadir un registro correcto, así que muchas veces la consola sencillamente está desactualizada. La otra causa es saltarse el último clic: generar la clave y publicar el registro TXT no hace nada por sí solo, y el estado solo pasa a Autenticando correo electrónico con DKIM cuando vuelves a Autenticar correo electrónico, haces clic en Iniciar autenticación y Google verifica el registro.

La solución Comprueba el registro publicado directamente con la herramienta Dig de Google Admin Toolbox en google._domainkey.yourdomain.com, en lugar de fiarte de la consola. Después envía un mensaje a una dirección externa y lee la cabecera Authentication-Results: un DKIM=pass con d= apuntando a tu propio dominio significa que el trabajo está hecho, diga lo que diga el aviso. Si el registro es correcto y ya has hecho clic en Iniciar autenticación, aguanta las 48 horas.

Mi registrador no acepta el valor de DKIM. No para de decirme que el registro es demasiado largo.

Una clave pública de 2048 bits supera el máximo de 255 caracteres de una sola cadena de caracteres DNS, así que la clave hay que guardarla como varias cadenas entrecomilladas dentro de un mismo registro TXT. Algunos paneles de control la parten por ti, otros rechazan la entrada de plano y otros la aceptan y la truncan en silencio, que es el peor caso: el registro existe, en el panel se ve bien y no valida nunca.

La solución Parte tú mismo la clave en varias cadenas de texto, cada una entre sus propias comillas dentro del mismo registro TXT, que es exactamente lo que indica la página de resolución de problemas de DKIM de Google. Después verifica con Dig que lo que vuelve coincide carácter por carácter con el valor de la consola de administración. Si tu proveedor de verdad no puede guardarla, regenera la clave a 1024 bits, la opción que Google ofrece para los proveedores que no admiten claves de 2048 bits.

Nuestra aplicación debería enviar las facturas como billing@ourdomain.com, pero todo llega desde la cuenta de administrador con la que la configuramos.

La aplicación se está autenticando en smtp.gmail.com con la dirección de un usuario y una contraseña de aplicación. Google documenta que, por esa ruta, la dirección del From tiene que coincidir con la cuenta autenticada, así que cualquier otro From se sustituye. El correo se autentica y se entrega, sencillamente no sale de la dirección que esperan tus clientes, y las respuestas caen en el buzón equivocado.

La solución Pasa la aplicación al servicio de retransmisión SMTP. En la consola de administración ve a Aplicaciones > Google Workspace > Gmail > Enrutamiento, configura el servicio de retransmisión SMTP y pon Remitentes permitidos en Solo direcciones de mis dominios para que la aplicación pueda enviar como billing@. Apunta la aplicación a smtp-relay.gmail.com en el puerto 587 con TLS y autentícala con Requerir autenticación SMTP o con la opción Aceptar solo correo de las direcciones IP especificadas. Ten en cuenta que las dos páginas de Google enuncian el techo de la retransmisión de forma distinta, una como 10.000 mensajes por usuario en un periodo de 24 horas y la otra como 10.000 destinatarios por usuario y día, así que dimensiona tus lotes contra la lectura más baja.

Gmail nos cortó durante un día y dijo que habíamos alcanzado un límite de envío. Apenas habíamos mandado 600 emails.

El tope que te paró probablemente no era el de mensajes. Una cuenta de pago de Workspace tiene 2.000 mensajes al día, pero solo 3.000 destinatarios externos y 2.000 destinatarios externos únicos, y los mensajes enviados por SMTP, POP o IMAP están limitados a 100 destinatarios cada uno. Una tanda de 600 mensajes que incluya listas de distribución revienta los contadores de destinatarios mucho antes que el de mensajes. Los límites corren sobre una ventana móvil de 24 horas, no sobre el día natural, así que a medianoche no se reinicia nada.

La solución Cuenta destinatarios, no envíos, y averigua qué contador tocaste antes de cambiar nada. Si el volumen es real y recurrente, sácalo del buzón: la retransmisión SMTP permite 10.000 mensajes por usuario en 24 horas, y el marketing de verdad pertenece a una plataforma hecha para eso. En una cuenta de prueba, cuenta con 500 mensajes y 500 destinatarios únicos al día hasta que el dominio haya pagado $100 USD o el equivalente, y ten presente que Google dice que el aumento puede tardar hasta 75 días en aplicarse a partir de ese umbral.

Tenemos DKIM configurado en Google Workspace, pero nuestra newsletter sigue fallando DMARC.

La clave de Workspace solo firma el correo que sale de los servidores de Google. Una newsletter enviada desde una plataforma de marketing no toca esa clave jamás, así que necesita su propio registro DKIM publicado para tu dominio en el selector que te dé esa plataforma. La página de resolución de problemas de DMARC de Google te manda a la documentación del tercero precisamente para este caso. Lo mismo vale para las herramientas de soporte, los recibos de e-commerce, las notificaciones del CRM y cualquier otra cosa que envíe como tu dominio.

La solución Haz inventario de todos los sistemas que envían como tu dominio y autentica cada uno: publica el registro DKIM de la plataforma en su propio selector y funde su mecanismo SPF dentro de tu registro SPF único. Usa los informes agregados DMARC que llegan a tu dirección rua para encontrar a los remitentes que se te olvidaron, que es justo para lo que sirven esos informes. Después manda un mensaje de prueba desde cada origen a una dirección de prueba, para leer el dominio d= de cada sistema en lugar de suponerlo.

La entregabilidad en Google Workspace, tus dudas resueltas.

Google ya firma mi correo, ¿por qué tengo que configurar DKIM?

Porque DMARC comprueba el dominio firmante, no la firma. El correo saliente de Workspace se firma con un dominio de infraestructura de Google, un subdominio de gappssmtp.com, y ese es el valor d= que verás en la cabecera DKIM-Signature de tu propio mensaje: no puede coincidir nunca con tu dominio del From. Las directrices para remitentes de Gmail exigen que el dominio de la cabecera From se alinee con el dominio de SPF o con el de DKIM. Generar tu propia clave en Aplicaciones > Google Workspace > Gmail > Autenticar correo electrónico es lo que hace posible la mitad DKIM de esa alineación.

¿Qué va exactamente en mi registro SPF?

Si Workspace es tu único remitente, un registro TXT en el dominio raíz, con el campo de host en @ y el valor v=spf1 include:_spf.google.com ~all. Si además envías desde una plataforma de marketing, una herramienta de soporte o un sistema de facturación, añade sus mecanismos a ese mismo registro. No publiques nunca un segundo registro SPF con el mismo nombre, y no pierdas de vista el límite de diez etiquetas include: que documenta Google.

¿El registro debe terminar en ~all o en -all?

Google recomienda ~all, y lo describe como decirle a los servidores receptores que marquen como spam los mensajes que vengan de servidores que no figuran en el registro. -all pide a los receptores que rechacen sin más, algo que solo es seguro cuando tienes la certeza de que todos tus remitentes legítimos están en el registro. Como SPF es solo una de las dos vías para satisfacer DMARC, el calificador estricto aporta menos de lo que la gente supone y cuesta más el día en que alguien añade una herramienta nueva.

¿Cuántas consultas DNS gasta include:_spf.google.com?

Una, comprobado en agosto de 2026. El registro encadenaba antes con _netblocks, _netblocks2 y _netblocks3, y buena parte de los consejos que circulan siguen dándolo por hecho. Hoy _spf.google.com responde con un único registro de rangos ip4 e ip6 y sin includes anidados, así que gasta una de tus diez. Compruébalo tú mismo antes de aplanar nada por lo que diga un artículo antiguo, porque el registro es de Google y Google puede cambiarlo.

¿Soy remitente masivo si solo escribo a clientes desde mi buzón de Workspace?

Solo a partir de los 5.000 mensajes al día a cuentas personales de Gmail, contados entre tu dominio principal y sus subdominios en conjunto, no por subdominio. El tope de 2.000 mensajes diarios por usuario hace que llegar sea difícil desde un solo buzón y fácil entre un equipo o a través de una retransmisión. Google dice que la condición no caduca, así que se queda contigo en cuanto la cruzas. Los requisitos no se aplican a los mensajes enviados a cuentas de Google Workspace.

¿Puede Unspam conectarse a mi cuenta de Google Workspace y probarla automáticamente?

No. Unspam no se integra con la API de Gmail y nunca inicia sesión en tu cuenta ni en tu consola de administración. Hay dos puntos de contacto: una dirección de prueba a la que envías un mensaje real y, para las pruebas que se repiten de forma periódica, unas credenciales SMTP que facilitas tú para las pruebas automáticas de Inbox Placement. Todo lo que aparece en el informe se lee del mensaje que llegó. El plan gratuito incluye 10 pruebas antispam y 3 pruebas de Inbox Placement al mes sin tarjeta; los planes de pago empiezan en $9 al mes con 14 días de reembolso.

Los detalles de la plataforma Google Workspace se verificaron con la documentación disponible públicamente en agosto de 2026 y pueden haber cambiado desde entonces. Google Workspace es una marca comercial de su respectivo propietario. Unspam no está afiliada a Google Workspace ni cuenta con su respaldo.

Prueba tu próxima campaña de Google Workspace antes de que lo hagan tus suscriptores.