¿Cuál es el registro SPF de Google Workspace?

Para un dominio que envía solo por Google Workspace es un registro TXT en la raíz con el valor v=spf1 include:_spf.google.com ~all. Google pide la virgulilla y no el guion, porque el fallo duro puede bloquear correo legítimo. Un dominio lleva un solo registro SPF, así que une en esa misma línea a cualquier otro remitente.

¿Por qué no aparece mi registro DKIM en la consola de administración?

Google indica esperar de 24 a 72 horas después de activar Gmail en el dominio antes de poder generar la clave, e intentarlo antes devuelve un error de registro DKIM no creado. También necesitas el privilegio de administrador de Configuración de Gmail para ver la página Autenticar correo electrónico donde se genera la clave.

¿Puedo arrancar DMARC directo en p=reject?

Puedes, y es la forma más rápida de perder correo real. Google recomienda una semana en p=none mientras lees los reportes diarios, luego cuarentena para un porcentaje pequeño con la etiqueta pct, que vas subiendo hasta 100%. Reject significa que los mensajes que fallan nunca se entregan, así que primero hay que autenticar a cada remitente legítimo.

Configurar DMARC en Google Workspace: SPF, DKIM y el orden

Imagina un despacho contable de 12 personas que migra a Google Workspace un viernes. El correo fluye, todos contentos, y nadie vuelve a abrir el panel de DNS. Seis semanas después los estados de cuenta empiezan a caer en spam, un cliente jura que nunca le llegó un recordatorio y alguien pregunta si el correo está roto.

Casi nunca está roto. Está sin autenticar, o autenticado de una forma que no coincide con la dirección del campo De. Google Workspace no publica el DNS por ti. Tú publicas tres registros, y el orden importa: SPF y DKIM tienen que estar firmando correo real antes de que DMARC pueda decirte algo útil. Estos son los valores exactos y la secuencia que usamos en dominios de clientes, con las rutas de la consola de administración verificadas contra la Ayuda de administradores de Google Workspace el 16 de octubre de 2026.

SPF: un solo include, y la virgulilla que pide Google

SPF enumera los servidores autorizados a enviar correo por tu dominio. Para un dominio que envía únicamente a través de Google Workspace, la Ayuda de administradores de Google Workspace da un solo registro, publicado como TXT en la raíz del dominio (host @ en la mayoría de proveedores de DNS):

Tipo: TXT
Host: @
Valor: v=spf1 include:_spf.google.com ~all

El calificador es una virgulilla, no un guion. Google lo dice sin rodeos: el símbolo debe ser ~ y no -, porque el guion puede resultar demasiado restrictivo y provocar problemas de entrega en correo legítimo. El fallo duro es una meta a la que se llega cuando los reportes DMARC están limpios, no una configuración con la que se arranca.

Un dominio lleva un registro SPF, no varios. El RFC 7208 trata más de un registro que empiece con v=spf1 como un error permanente, así que un segundo registro agregado por el plugin de una tienda o por un hosting viejo deja el dominio entero en PermError sin avisar. Mejor une los mecanismos en un solo registro. Google publica valores combinados para las parejas habituales, por ejemplo un dominio con Workspace y Microsoft 365 a la vez:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Para autorizar un servidor por dirección en lugar de por include, agrega ip4: o ip6: justo antes de ~all. Cuida el presupuesto mientras lo haces: la recomendación de Google es que el registro no lleve más de diez referencias a otros dominios o servidores, que son las diez consultas DNS que permite el RFC 7208 en la sección 4.6.4. Con cuatro proveedores y sus includes ya suele romperse. La salida la escribimos en la guía de demasiadas consultas DNS en SPF.

Un punto que se pasa por alto: si envías desde subdominios, cada subdominio necesita su propio registro SPF. No lo heredan.

DKIM: genera la clave en la consola y luego activa la firma

DKIM es la firma que sobrevive a un reenvío, y es el registro que Google Workspace sí genera por ti. Dos cosas sobre los tiempos. Primero, después de activar Gmail en el dominio la clave no está disponible de inmediato: Google indica esperar de 24 a 72 horas, e intentarlo antes produce un error de registro DKIM no creado. Segundo, generar y publicar la clave no es lo mismo que activarla, y ese último paso es justo el que se olvida.

En la consola de administración entra a Aplicaciones, luego Google Workspace, luego Gmail y luego Autenticar correo electrónico. Necesitas el privilegio de administrador de Configuración de Gmail para verlo. Selecciona el dominio y haz clic en Generar nuevo registro. Elige la clave de 2048 bits si tu proveedor de DNS la soporta, porque la clave más larga es la más segura, y deja el prefijo en su valor predeterminado google. Google recomienda conservar ese valor y cambiarlo solo si el dominio ya tiene una clave DKIM en ese prefijo.

Haz clic en Generar, copia el nombre y el valor del registro y publícalos en tu DNS como TXT:

Tipo: TXT
Host: google._domainkey
Valor: v=DKIM1; k=rsa; p=MIIBIjANBgkqh... (el valor largo de la consola)

Después vuelve a Autenticar correo electrónico, selecciona otra vez el dominio y activa DKIM. Hasta que lo hagas, el registro está en el DNS y no se firma nada.

Si el valor de 2048 bits no se guarda, la causa casi siempre es el límite de 255 caracteres por cadena en un registro TXT. Algunos proveedores de DNS parten el valor por ti y otros no. Pregúntale al proveedor si admite registros TXT más largos y, si no los admite, la salida documentada por Google es una clave de 1024 bits. Esa sigue cumpliendo las directrices para remitentes de Gmail, que piden claves de al menos 1024 bits y recomiendan 2048.

DMARC: arranca en p=none con una dirección de reportes

Para DMARC no hay nada que tocar en la consola de administración. Es un TXT más, publicado en el host _dmarc. Antes de agregarlo, deja que SPF y DKIM autentiquen correo real durante al menos 48 horas, que es el requisito previo de Google. Un registro DMARC encima de una clave DKIM que todavía no firma produce una semana de reportes alarmantes sobre tu propio correo.

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

La etiqueta rua es opcional en el estándar y Google recomienda incluirla siempre, y estamos de acuerdo: sin ella tienes política y cero evidencia. Cada dirección necesita el prefijo mailto:, y si el buzón de reportes está en un dominio distinto al del registro, ese otro dominio tiene que publicar un registro DNS que autorice los reportes. Apúntala a un buzón que de verdad vayas a leer, o a un analizador.

Si todavía estás en medio de la activación de DKIM, Google recomienda un registro con pct=0 mientras revisas los reportes diarios.

La etiqueta sp define una política aparte para los subdominios. Si la omites, los subdominios heredan la política del dominio padre, que es lo que conviene en la mayoría de las implementaciones pequeñas.

Los tres registros, en el orden en que los publicamos

Esta es la secuencia que seguimos en el dominio de un cliente, y la verificación que tiene que pasar antes de poner el siguiente registro.

Paso	Registro	Valor o acción	Qué verificar antes de seguir
1	TXT en `@`	`v=spf1 include:_spf.google.com ~all`	Un solo registro que empiece con `v=spf1`, diez referencias o menos
2	Consola de administración	Autenticar correo, Generar nuevo registro, 2048 bits, prefijo `google`	El registro aparece en la consola (24 a 72 horas después de activar Gmail)
3	TXT en `google._domainkey`	El valor copiado de la consola	El valor completo guardado, sin cortarse en 255 caracteres
4	Consola de administración	Activar DKIM para el dominio	Un mensaje de prueba a una cuenta de Gmail muestra `dkim=pass`
5	TXT en `_dmarc`	`v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com`	48 horas con SPF y DKIM pasando, y luego reportes llegando

Los remitentes que lo rompen un mes después

Los tres registros pasan el primer día y luego una herramienta de facturación, un CRM, una tienda o una plataforma de boletines empieza a enviar como tu dominio y DMARC empieza a fallar solo en ese flujo. Conviene entender la regla y no el registro.

DMARC pasa cuando un mensaje pasa SPF o DKIM y el dominio que pasó coincide con el dominio del campo De. Google lo plantea como alineación: DMARC aprueba o rechaza según qué tan de cerca coincide el encabezado De con el dominio de envío identificado por SPF o por DKIM. Un proveedor que envía con su propio dominio de sobre puede pasar SPF a su nombre y aun así fallar DMARC para el tuyo.

Por eso la preferencia, siempre, es una firma DKIM en tu dominio por parte de cada proveedor, publicada en su propio selector. No cuesta consultas de SPF y sobrevive al reenvío. Acumular includes de proveedores en SPF es justo como los dominios llegan al muro de las diez consultas. Cuando el correo de verdad sale de Google, el relay SMTP y enviar como son las dos rutas de Workspace que vale la pena conocer, y autentican de forma distinta.

Verifica en los encabezados, no en un checador

Un checador de DNS te dice que el registro existe. No te puede decir qué hizo Gmail con un mensaje real. Manda uno a una dirección que controles y lee el resultado.

En Gmail de escritorio, junto a Responder haz clic en Más y luego en Mostrar original. El encabezado Authentication-Results trae los veredictos, y una firma válida se lee como dkim=pass. Más rápido todavía, Google documenta la señal en la bandeja: un mensaje que pasó muestra las líneas Enviado por y Firmado por en los detalles del remitente, y un signo de interrogación junto al nombre del remitente significa que no se autenticó.

Dos detalles de Google que conviene saber antes de pasar una hora depurando un encabezado. Gmail revisa solo las primeras cinco firmas DKIM que aparecen en ese encabezado, así que una cadena larga de reenviadores y relays puede dejar la tuya fuera de vista. Y en un mensaje reenviado que pasa SPF o DKIM pero cuya cadena ARC muestra que falló antes, Gmail lo trata como no autenticado, que es la razón por la que el reenvío rompe SPF de maneras que el DNS no arregla.

Si la firma DKIM está en el encabezado y de todos modos falla, las causas habituales son una lista corta, y la guía de fallos de DKIM en Google Workspace las recorre en orden.

Luego la rampa, y los umbrales con los que te miden

Un registro en p=none no protege a nadie. Te compra una semana de evidencia. El despliegue recomendado por Google es una semana en none para todo el correo mientras lees los reportes diarios, que suele alcanzar para que cada flujo de correo aparezca al menos una vez. Después cuarentena para una porción pequeña con pct: el ejemplo de Google es que una organización pequeña puede empezar en 10% y una grande en 1%. Súbelo con el tiempo hasta 100%. Reject es opcional, y Google es claro en lo que implica: los mensajes que no pasan son rechazados por los servidores receptores y nunca se entregan.

Mientras tanto, las directrices para remitentes de Gmail fijan el piso para cualquier dominio: SPF o DKIM en todo el correo, DNS directo e inverso válidos y tasas de spam por debajo de 0.3%. Si cruzas unos 5,000 mensajes en 24 horas hacia cuentas personales de Gmail, eres remitente masivo, lo que exige SPF, DKIM y un registro DMARC publicado, donde una política de none se acepta. La escalera de aplicación está en nuestro despliegue de p=none a p=reject.

Cómo ayuda Guanacos Tech

Montamos esto como un trabajo acotado para equipos pequeños y medianos de Norteamérica y Latinoamérica: leemos lo que hay hoy en el DNS, publicamos los tres registros en el orden de arriba, confirmamos cada uno con un mensaje real y no con un checador, levantamos el inventario de remitentes externos que nadie anotó y luego vigilamos contigo los reportes DMARC durante la rampa. Cómo trabajamos cabe en una página. Si prefieres tenerlo verificado en lugar de investigado, para eso están los consultores de Google Workspace, y media hora con tu panel de DNS abierto alcanza para decir cuál de los tres registros falta y cómo debería ser la rampa para tu correo.

SPF, DKIM y DMARC en Google Workspace: los registros exactos, en orden