Última actualización: julio de 2026

En resumen: Al terminar esta guía tu dominio publicará un registro SPF correcto para Google Workspace — incluidos registros combinados para servicios de newsletter y CRM.

Requisitos previos

  • Una cuenta de Google Workspace con tu propio dominio
  • Acceso a la gestión de DNS de tu dominio — que no está en Google, sino en tu proveedor de dominio

¿Qué es SPF?

SPF (Sender Policy Framework) es un registro TXT en el DNS de tu dominio. Enumera qué servidores de correo pueden enviar emails con tu dominio como remitente. Los servidores receptores usan la entrada para comprobar si un mensaje procede de un servidor autorizado. Sin SPF, cualquier servidor puede enviar correo en tu nombre — y tu correo legítimo acaba antes en spam.

Google convierte esto ahora en un requisito estricto: los remitentes de correo masivo (más de 5.000 mensajes al día) deben tener configurados SPF, DKIM y DMARC, de lo contrario Gmail ya no acepta su correo de forma fiable.

El punto de partida en Google Workspace

Igual que en Microsoft 365: no hay nada que hacer para SPF en la consola de administración de Google. El registro se introduce en el proveedor de dominio — es decir, allí donde vive tu zona DNS. Cómo funciona en cada caso lo muestran nuestras guías para IONOS, Strato, All-Inkl, Netcup y Hetzner DNS.

Dos notas de la propia documentación de Google: SPF puede estar ya configurado para tu dominio (p. ej. si registraste el dominio a través de un partner de Google) — así que comprueba primero, luego cambia. Y el registro debería contener todos los servidores que envían por tu organización, no solo Google.

Guía paso a paso

1. Comprueba si SPF ya está activo

Lo más rápido, desde el terminal:

dig TXT example.com +short | grep spf1

Como alternativa, introduce tu dominio en el escáner MXAudit gratuito — comprueba a la vez la sintaxis del registro y el límite de lookups.

2. Determina el registro

Solo envía Google Workspace (el caso normal):

v=spf1 include:_spf.google.com ~all

El include apunta ahora a una lista plana de rangos IP de Google (IPv4 + IPv6) y cuesta exactamente un lookup de DNS. En guías antiguas todavía circulan los includes anidados _netblocks — ya no necesitas introducir esos.

¿Envían también otros servicios? Google documenta la combinación por su cuenta, todas las fuentes en un registro — p. ej. con Mailchimp:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Con Salesforce:

v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all

O en paralelo con Microsoft 365:

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

3. Introduce el registro en el proveedor de dominio

Inicia sesión en tu proveedor de dominio y crea el valor como registro TXT en el dominio principal (host @) — o actualiza la entrada v=spf1 existente. Solo puede haber un registro SPF por dominio.

4. Ten en cuenta los subdominios

Según Google, cada subdominio que envía necesita su propia entrada SPF — el registro del dominio principal no se aplica automáticamente.

5. Espera hasta que el cambio esté activo

Los cambios de DNS tardan: según el TTL y el caché puede tardar unas horas hasta que todos los servidores del mundo vean el nuevo registro.

Los componentes en detalle

ComponenteSignificado
v=spf1identificador de versión, siempre al principio
include:_spf.google.compermite la infraestructura de envío de Google (lista plana IPv4/IPv6, 1 lookup)
include: (adicional)permite servicios externos — 1 lookup de DNS adicional cada uno
~allsoftfail: la recomendación por defecto de Google en el registro de ejemplo

Un contraste interesante: Google muestra ~all en todos los ejemplos, mientras que Microsoft recomienda -all para 365. Ambas posturas son defendibles — con DKIM y DMARC limpios (que Google exige de todos modos para grandes remitentes) la elección del all importa menos, porque DMARC asume la aplicación.

Verifica el resultado

Comprueba tu configuración con el escáner MXAudit gratuito — te muestra de inmediato si tu registro SPF es sintácticamente correcto y cuántos lookups de DNS consume (el límite es 10).

O directamente en el terminal:

dig TXT example.com +short | grep spf1

La salida debe contener exactamente un registro con v=spf1.

Errores habituales

Crear un segundo registro SPF en lugar de ampliar el existente. Muchos dominios ya tienen un registro del host. El include de Google va dentro de él — dos entradas v=spf1 provocan un permerror.

No recoger todos los remitentes. La documentación de Google es clara: el registro debería contener los servidores de todos los sistemas de envío — CRM, herramienta de facturación, sistema de tickets. Lo que falte se descarta en el destinatario.

Includes _netblocks obsoletos. Las guías antiguas listan los registros de netblock internos de Google uno por uno. Innecesario: include:_spf.google.com basta y se mantiene actualizado cuando Google cambia sus rangos IP.

Olvidar los subdominios. Cada subdominio que envía necesita su propia entrada SPF.

+all al final. Un +all permite enviar a cualquier servidor y deja todo el registro sin efecto — no lo copies.

Los reenvíos fallan. Si un destinatario reenvía tu correo automáticamente, SPF falla a menudo en el destinatario final — el servidor que reenvía no está en tu registro. Es una debilidad de diseño de SPF, no un error de configuración; DKIM y DMARC cubren este caso.

Más información