SPF, DKIM y DMARC para Google Workspace.
Autenticar Google Workspace significa demostrar que los servidores de Gmail que envían en nombre de tu dominio son realmente tú. Se reduce a tres registros DNS más un interruptor dentro de la consola de administración: un registro SPF TXT que añade el include compartido de Google, una clave DKIM que generas en la consola y publicas como registro TXT (y luego activas con «Iniciar autenticación»), y un registro de política DMARC. Google Workspace es uno de los pocos remitentes que también actúa como receptor, así que conseguir que los tres estén alineados es lo que hace que tu correo llegue a las bandejas de entrada de Gmail en lugar de mostrar un aviso «via» o acabar en spam.
¿Por qué autenticar Google Workspace?
El correo de Google Workspace ya circula por la propia infraestructura de Google, pero hasta que no lo autenticas, ese correo solo es débilmente atribuible a tu dominio: Gmail puede mostrar una nota «via», DMARC no puede pasar y tu dirección From no es criptográficamente tuya. Desde febrero de 2024, las propias directrices para remitentes de Google exigen que todo remitente pase SPF o DKIM, y que todo remitente masivo (aproximadamente más de 5.000 mensajes al día a Gmail) publique además una política DMARC de al menos p=none, con alineación. Yahoo adoptó las mismas normas ese mismo mes y Microsoft empezó a aplicarlas en 2025. Como Google evalúa aquí el correo con sus propias directrices, un dominio de Workspace sin autenticar es la vía más rápida a la carpeta de spam o a un rechazo directo. Configurar SPF + DKIM + DMARC correctamente alinea ambos mecanismos con tu dominio, elimina la etiqueta «via», permite que DMARC pase y construye reputación de envío bajo tu propio nombre.
La realidad del SPF con Google Workspace
Google Workspace es un auténtico proveedor de tipo «include»: añades un único mecanismo compartido, include:_spf.google.com, al único registro SPF TXT de tu dominio raíz — el registro completo es v=spf1 include:_spf.google.com ~all. Este es un include compartido real (todos los clientes de Workspace usan el mismo), a diferencia de los proveedores de delegación por CNAME. Aquí importa más que para la mayoría de remitentes porque el correo que envías a través de Google usa un remitente de sobre en tu propio dominio, así que SPF realmente se alinea con tu dominio organizativo y contribuye a un DMARC pass (no solo DKIM). Una actualización importante: include:_spf.google.com es ahora un único registro SPF plano que contiene solo mecanismos ip4:/ip6: — ya no anida la antigua cadena include:_netblocks.google.com / _netblocks2 / _netblocks3. Eso significa que cuesta una sola consulta DNS frente al límite de 10 de la RFC 7208, no las tres o cuatro que las guías más antiguas y algunos verificadores de SPF con caché siguen indicando. Google recomienda terminar con ~all (softfail) en lugar de -all, porque los usuarios de Workspace suelen enviar también de forma legítima a través de otras herramientas; solo endurece a -all cuando tengas la certeza de que todos los remitentes están incluidos. Y debe haber exactamente un registro SPF TXT en el dominio — si también usas SendGrid, Mailchimp, Microsoft 365, etc., fusiona todos los mecanismos en esa única línea v=spf1 en lugar de publicar un segundo registro SPF (dos registros SPF son un PermError).
Paso a paso
- 1
Abre Autenticar correo electrónico
Inicia sesión en admin.google.com como superadministrador, luego ve a Menú (☰) → Apps → Google Workspace → Gmail → Autenticar correo electrónico. Esta es la página de DKIM; SPF y DMARC se añaden directamente en tu proveedor DNS, no aquí.
- 2
Selecciona el dominio correcto
Si gestionas más de un dominio, elige el dominio de envío en el desplegable de la parte superior de la página Autenticar correo electrónico. Cada dominio principal, dominio secundario y alias de dominio se autentica por separado.
- 3
Genera la clave DKIM
Haz clic en Generar registro nuevo. Establece la longitud de clave en 2048 bits (la recomendación de Google; recurre a 1024 bits solo si tu proveedor DNS no puede almacenar un valor TXT largo) y deja el prefijo de selector con el valor predeterminado google. Haz clic en Generar.
- 4
Copia el registro DKIM
Google muestra un registro TXT: el host/nombre es google._domainkey y el valor empieza por v=DKIM1; k=rsa; p=… seguido de una clave pública larga. Copia ambos. Deja esta pestaña abierta — volverás para hacer clic en Iniciar autenticación.
- 5
Publica el registro DKIM TXT
En tu proveedor DNS, añade un registro TXT con el host google._domainkey y el valor que te dio Google. Una clave de 2048 bits es más larga que el límite TXT de 255 caracteres por cadena, así que algunos proveedores requieren que la mantengas como varios fragmentos entrecomillados en un mismo registro — la mayoría de paneles lo gestionan automáticamente; si no, pega el valor dividido exactamente como se muestra.
- 6
Añade o fusiona el registro SPF
Añade un registro TXT en el dominio raíz (host @ o en blanco) con v=spf1 include:_spf.google.com ~all. Si ya existe un registro SPF, no crees un segundo — fusiona include:_spf.google.com en la línea v=spf1 existente junto a cualquier otro remitente.
- 7
Publica el registro DMARC
Añade un registro TXT en el host _dmarc con v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com. Empieza en p=none (solo monitorización) para que nada se vea afectado mientras confirmas la alineación; lo endurecerás más adelante.
- 8
Haz clic en Iniciar autenticación
De vuelta en la página Autenticar correo electrónico, espera hasta que el DKIM TXT se haya propagado, luego haz clic en Iniciar autenticación. Este es el paso que la gente se salta — generar la clave no hace nada hasta que inicias la autenticación, tras lo cual el estado indica «Autenticando el correo electrónico de este dominio».
- 9
Envía una prueba y revisa las cabeceras
Envía un mensaje desde una dirección de Workspace, ábrelo en otra cuenta de Gmail y usa ⋮ → Mostrar original. Confirma SPF: PASS, DKIM: PASS con «signed-by: tudominio.com» (selector google), y DMARC: PASS — todos alineados con tu dominio, no con google.com.
- 10
Repite para otros dominios y alias
El paso de DKIM y de Iniciar autenticación debe repetirse para cada dominio secundario y alias de dominio desde el que envíes. Los registros SPF y DMARC también deben existir en cada uno de esos dominios, o su correo no se autenticará.
Registros que añadir
Google Workspace genera los valores exactos en su asistente de configuración; estos muestran la forma de lo que añadirás en tu proveedor de DNS.
| Tipo | Host | Valor |
|---|---|---|
| TXT | @ | v=spf1 include:_spf.google.com ~allSPF raíz — mantén un solo registro SPF; fusiona los demás remitentes en esta línea. include:_spf.google.com cuesta ahora 1 consulta DNS. |
| TXT | google._domainkey | v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from the Admin console)Ilustrativo — la clave real se genera por dominio en Apps → Google Workspace → Gmail → Autenticar correo electrónico. Las claves de 2048 bits pueden necesitar publicarse como cadenas entrecomilladas divididas. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comUn registro DMARC por dominio. Empieza en p=none, luego endurece a quarantine/reject. |
Mantén exactamente un registro TXT de SPF (v=spf1) en tu dominio raíz: fusiona en él todos los remitentes. Tener dos registros SPF es en sí mismo un error.
El presupuesto de 10 consultas
El SPF tiene un límite estricto de 10 consultas DNS: si lo superas, devuelve un permerror y deja de validar en todas partes. Esto es lo que la configuración de Google Workspace consume de ese presupuesto.
Google Workspace añade 1 de tus 10 consultas; los mecanismos ip4: e ip6: no cuentan.
DKIM
El DKIM de Google Workspace se genera dentro de la consola de administración, no se copia de un valor fijo. Ve a Apps → Google Workspace → Gmail → Autenticar correo electrónico, selecciona el dominio, haz clic en Generar registro nuevo y elige 2048 bits con el prefijo de selector predeterminado google. Google muestra entonces un registro TXT cuyo host es google._domainkey.tudominio.com y cuyo valor es v=DKIM1; k=rsa; p=<tu clave pública>. Publicas ese TXT en tu proveedor DNS — Google conserva la clave privada correspondiente y firma con ella el correo saliente. Dos cosas hacen que el DKIM de Workspace sea diferente al de la mayoría de proveedores. Primera, publicar el registro no basta: debes volver a la página Autenticar correo electrónico y hacer clic en Iniciar autenticación, o Google nunca empieza realmente a firmar con tu clave (esta es la razón más común por la que un registro correctamente publicado sigue sin mostrar un DKIM pass). Segunda, una clave pública de 2048 bits supera el límite de 255 caracteres de una única cadena TXT, así que muchos proveedores DNS la almacenan como varios fragmentos entrecomillados dentro de un mismo registro; la consola de administración muestra el valor ya formateado, y la mayoría de paneles (GoDaddy, Cloudflare, Namecheap, etc.) lo reensamblan correctamente — si más tarde Gmail informa de que la clave no es válida, una concatenación rota suele ser la causa. El selector google es adecuado para conservarlo; solo lo cambiarías si ese selector ya lo usa otro servicio en el dominio. Deja de usar cualquier clave heredada de 1024 bits en cuanto puedas, y recuerda que DKIM se habilita por dominio y por alias, no una sola vez para toda la cuenta.
DMARC
DMARC es un registro de política aparte que publicas tú mismo — Google no lo crea por ti. Añade un registro TXT en _dmarc.tudominio.com con v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com. p=none es solo de monitorización: no cambia nada en la entrega, pero indica a los receptores que te envíen por correo informes agregados para que puedas confirmar que el correo de Google Workspace pasa SPF y DKIM alineados con tu dominio. Como Workspace alinea ambos mecanismos (SPF a través de tu propio dominio de sobre, DKIM a través del selector google en tu dominio), deberías ver pases limpios rápidamente. Vigila los informes rua durante una o dos semanas, asegúrate de que todo remitente legítimo — Workspace más cualquier herramienta de terceros — se está autenticando, y luego endurece la política a p=quarantine y finalmente p=reject. Mantén exactamente un registro _dmarc para todo el dominio, independientemente de cuántos remitentes uses; nunca añadas un segundo registro DMARC específicamente para Google. Ten en cuenta que la propia norma para remitentes masivos de Google solo exige p=none como mínimo, pero p=reject es lo que realmente protege tu dominio de la suplantación.
Comprueba que de verdad funcionó
No te fíes solo del estado de la consola de administración — puede retrasarse y seguir diciendo «hasta 48 horas» cuando el DNS ya está activo. Confírmalo en un mensaje real: envía desde una dirección de Workspace a otro buzón, ábrelo en Gmail y elige ⋮ → Mostrar original. Quieres SPF: PASS, DKIM: PASS y DMARC: PASS, con los dominios de signed-by de DKIM y de SPF mostrando ambos tudominio.com (selector google) en lugar de google.com. Google también publica su propio diagnóstico, la herramienta Admin Toolbox CheckMX (toolbox.googleapps.com/apps/checkmx), que señala registros SPF/DKIM/DMARC y MX ausentes o mal formados. Puedes hacer una comprobación puntual de los registros en bruto con dig TXT google._domainkey.tudominio.com y dig TXT _dmarc.tudominio.com. Por último, pasa el dominio por la verificación de salud de dominio de Qualisend para confirmar que todos los registros resuelven y que el SPF se mantiene por debajo del límite de 10 consultas, y en cuanto empiecen a llegar los informes agregados de DMARC, mete uno en el analizador de informes DMARC — Google debería aparecer como una fuente alineada y que pasa por completo.
Errores habituales
- Rompe la autenticación
Generar la clave DKIM no hace nada hasta que haces clic en Iniciar autenticación en la página Autenticar correo electrónico. Un registro google._domainkey publicado con la firma nunca iniciada es la razón n.º 1 por la que DKIM sigue fallando una comprobación.
- Rompe la autenticación
Las claves DKIM de 2048 bits son más largas que una única cadena TXT de 255 caracteres, así que se almacenan como varios fragmentos entrecomillados. Si Gmail informa de que la clave no es válida tras publicarla, una concatenación estropeada (o tu panel omitiendo la división) es casi siempre la causa.
- Rompe la autenticación
La consola de administración puede seguir mostrando «no se está autenticando» o «hasta 48 horas» incluso después de que tu DNS sea correcto — el estado se vuelve a comprobar con retraso. Fíate de Mostrar original / Admin Toolbox antes que del aviso de la consola.
- Cobertura
DKIM debe configurarse por separado para cada dominio secundario y alias de dominio, y cada uno de esos dominios también necesita sus propios registros SPF y DMARC. Autenticar el dominio principal no cubre los demás.
- Rompe la autenticación
Mantén exactamente un registro SPF TXT en la raíz. Si también envías a través de SendGrid, Mailchimp, Microsoft 365, etc., fusiona include:_spf.google.com en la única línea v=spf1 — dos registros SPF son un PermError.
- Configuración de DNS
include:_spf.google.com es ahora un único registro plano (1 consulta), pero las guías más antiguas y algunos verificadores de SPF con caché siguen contándolo como 3–4 — no sobreaprovisiones ni aplanes por pánico basándote en cifras obsoletas.
- Cobertura
Usa ~all, no -all. Google recomienda softfail porque los usuarios de Workspace envían con frecuencia de forma legítima a través de otros servicios; un -all prematuro puede hacer fallar en firme correo que olvidaste incluir.
- Cobertura
El correo enviado a través de un relé de terceros, un SMTP externo «Enviar correo como» de Gmail o una plataforma de marketing no lo firma Google con DKIM — esas vías necesitan su propia autenticación y no se alinearán solo porque el DKIM de Workspace esté activado.
Crea tu registro SPF
Google Workspace ya viene preseleccionado abajo. Añade cualquier otra plataforma desde la que envíes y luego publica el registro fusionado único.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF de Google Workspace — Preguntas frecuentes
Lecturas relacionadas
Una vez publicado, confirma que todo se resuelve con el chequeo de salud del dominio y luego averigua quién envía en tu nombre con el analizador de informes DMARC. Explora todas las fuentes de envío en el generador. Eso sí, la autenticación es solo la mitad de la entregabilidad: una IP o un dominio de envío incluidos en una lista negra te llevan igualmente a spam por muy limpio que esté tu SPF, así que conviene vigilar las listas negras con monitorización de listas negras.
Autenticado: ahora mantén la lista limpia
Pasar SPF, DKIM y DMARC te lleva a la bandeja de entrada; una lista limpia te mantiene ahí. Verifica la tuya: empieza gratis con 100 créditos, sin tarjeta.