SPF para Microsoft 365 y Google Workspace: la configuración que funciona

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

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

Las dos juntas

Muchas organizaciones migran, fusionan o explotan las dos en paralelo. En ese caso, un único registro SPF combina ambos include:

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

Recuerda la regla de oro: un solo registro v=spf1 por dominio. Si publicas un registro para Microsoft y otro para Google, creas un doble registro, fuente de PermError, y muchos destinatarios ignorarán los dos. La buena práctica es combinarlo todo en una sola línea.

La trampa del recuento de resoluciones

Esto es lo que sorprende a los equipos: estos dos include, por sí solos, consumen muchas resoluciones DNS. include:_spf.google.com se despliega en varios sub-include (_netblocks, _netblocks2, _netblocks3), o sea unas cuatro resoluciones. include:spf.protection.outlook.com consume dos o tres. Pon los dos juntos, y ya estás en seis o siete resoluciones antes de haber añadido el más mínimo proveedor tercero.

Ahora bien, el límite de búsquedas DNS de SPF es de diez. Solo te quedan, pues, tres o cuatro resoluciones para tu router de marketing, tu facturación, tu herramienta de soporte… Se entiende por qué tantos registros caen en PermError: Microsoft y Google ocupan ya la mitad del presupuesto.

La estrategia para añadir tus otros proveedores

Puesto que el presupuesto es ajustado, el método importa. Por orden de preferencia:

1. Separa por subdominio. Mantén Microsoft 365 o Google Workspace en tu dominio raíz (la mensajería humana), y haz salir el marketing desde news.tu-dominio.com y el transaccional desde notif.tu-dominio.com, cada uno con su propio SPF. Cada subdominio parte de un presupuesto de diez resoluciones intacto. Es con diferencia la estrategia más duradera.
2. Prioriza la alineación DKIM para los terceros. Un router que firma en DKIM alineado (d=tu-dominio.com) satisface DMARC sin consumir resolución SPF. Es a menudo la mejor forma de integrar un proveedor sin sobrecargar tu SPF.
3. Congela en ip4: los proveedores con IP estables, como último recurso, vigilando que no cambien.

Evita a toda costa apilar los include en el dominio raíz «porque es más simple»: es el camino directo hacia el PermError.

Durante una migración: las dos, temporalmente

El cambio de Google Workspace a Microsoft 365 (o al revés) es un momento de riesgo para tu SPF. Durante la transición, envías desde ambas plataformas: tu registro debe, pues, incluir los dos include simultáneamente.

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

Dos trampas acechan. Primero, no crees en absoluto dos registros separados «mientras dura la migración»: es el doble registro asegurado, y el PermError que lo acompaña. Segundo, no olvides retirar el include de la antigua plataforma una vez terminada la migración: un include huérfano consume resoluciones para nada, y si el antiguo servicio acaba cerrando su registro, se convertirá en un void lookup. Una migración limpia termina, pues, con una limpieza del registro, no solo con el cambio de mensajería. El buen reflejo: anota desde el principio la fecha prevista de retirada del antiguo include, para no dejarlo rondar meses y despertarte un día en PermError.

Las trampas específicas

Algunos errores reaparecen con estas dos plataformas:

• Recopiar IP de Google o Microsoft a mano. Rompes el vínculo automantenido y te expones a fallos cuando los rangos cambian. Quédate en los include oficiales.
• Olvidar los subdominios de envío. Si envías desde mail.tu-dominio.com, ese subdominio necesita su propio SPF: el SPF de la raíz no se aplica automáticamente a los subdominios.
• Confundir SPF y DKIM/DMARC. Configurar el include no basta: acuérdate de activar la firma DKIM del lado de Microsoft o Google (mediante su consola), y de publicar tu registro DMARC.
• Mezclar tenants. Si tienes varios tenants de Microsoft o varios dominios de Google, cada uno tiene su configuración; no mezcles sus include sin verificar lo que autorizas realmente.

Un registro completo, de la vida real

Tomemos una empresa típica: mensajería en Microsoft 365, marketing mediante un router (Brevo), facturación mediante una app de negocio, y una herramienta de soporte que envía notificaciones. La tentación es escribir una sola línea cajón de sastre:

v=spf1 include:spf.protection.outlook.com include:spf.brevo.com
  include:_spf.facturacion.com include:_spf.soporte.com -all

Despleguemos: Microsoft ≈ 3, Brevo ≈ 1-2, facturación ≈ 1, soporte ≈ 1, más los eventuales sub-include. Estamos en seis o siete resoluciones, quizá más. «Pasa» hoy, pero sin margen, y la quinta herramienta hará caer en PermError.

La configuración duradera reparte los flujos por subdominio:

• Dominio raíz (empresa.com): v=spf1 include:spf.protection.outlook.com -all — únicamente la mensajería humana.
• news.empresa.com: v=spf1 include:spf.brevo.com -all — el marketing, con DKIM alineado sobre el subdominio.
• notif.empresa.com: v=spf1 include:_spf.soporte.com -all — las notificaciones.
• La facturación, que solo tiene una IP fija, pasa a DKIM alineado sin tocar el SPF.

Cada registro permanece minúsculo, lejos del límite, y cada flujo puede crecer sin amenazar a los demás. Es más trabajo al principio que una línea cajón de sastre, pero es exactamente lo que evita el PermError seis meses después, cuando una quinta herramienta llega sin avisar.

Y DMARC en todo esto

Configurar el include de Microsoft o Google hace pasar SPF, pero es solo la mitad del cuadro. Para que tu dominio esté realmente protegido, hay que activar también la firma DKIM (en la consola de Microsoft 365 o Google Workspace) y publicar un registro DMARC. Es la alineación —SPF o DKIM alineado con tu From:— la que hace la protección, no el SPF solo. Ambas plataformas ofrecen su DKIM en unos clics; no te detengas sobre todo en el SPF. Una vez las tres piezas implementadas, apunta a p=reject del lado de DMARC, para que la suplantación de tu dominio sea realmente rechazada y no solo observada.

Piensa en la propagación DNS

Un detalle operativo que a menudo se olvida: una modificación SPF no es instantánea. Los resolutores del mundo entero mantienen tu registro TXT en caché hasta la expiración de su TTL, así que el cambio puede tardar de unos minutos a varias horas en verse en todas partes, y durante esa ventana algunos destinatarios evalúan todavía la versión antigua. Antes de un cambio planificado (añadir un include, cambio de migración), baja el TTL del registro algún tiempo antes: la propagación será tanto más rápida, y una eventual marcha atrás también. Una vez estabilizada la situación, sube el TTL a un valor normal. Y no concluyas nunca que un cambio «no funciona» al primer minuto: interroga a varios resolutores antes de retocar el registro, o de lo contrario corres el riesgo de apilar correcciones sobre un simple retraso de caché.

Verificar tu configuración

Una vez implementado tu registro, contrólalo: un solo v=spf1, sintaxis válida, recuento de resoluciones bajo diez, cualificación -all. Nuestro analizador gratuito hace todo eso en unos segundos y despliega los include de Microsoft y Google para mostrarte su coste real. El procedimiento completo está en cómo verificar tu registro. Y no olvides lo esencial: la cualificación terminal debe apuntar a -all (ver los mecanismos -all y ~all).

Preguntas frecuentes

¿Hace falta -all o ~all con Microsoft 365 / Google Workspace? Apunta a -all una vez listadas todas tus fuentes. Microsoft y Google recomiendan a veces ~all por prudencia al arrancar, pero no es un objetivo: un dominio dominado termina en -all.

¿Basta el include de Google/Microsoft para DMARC? No. Hace pasar SPF para la mensajería de la plataforma, pero DMARC exige la alineación con tu From:. Para la mensajería humana, la alineación suele ser buena; para los terceros que envían «en tu nombre» a través de esas plataformas, verifica la alineación en tus informes.

¿Por qué mi SPF se desborda si solo tengo Microsoft y un router? Porque spf.protection.outlook.com más un router que se despliega pueden acercarse ya a diez resoluciones. Separa el router en un subdominio, o cámbialo a DKIM alineado.

¿Puedo poner Microsoft 365 y Google Workspace en el mismo dominio? Sí, combinando sus include en un solo registro. Solo vigila el recuento, porque los dos juntos consumen ya una buena mitad del presupuesto.

¿Debo configurar SPF si ya uso DKIM? Sí, ambos son complementarios. SPF y DKIM cubren casos diferentes, y DMARC se apoya en uno u otro alineado. Configura ambos: ver cómo funcionan los tres protocolos juntos.

Deja que Thomas componga tu registro

Combinar Microsoft, Google y tus terceros bajo la barra de las diez resoluciones es un rompecabezas. Thomas, tu CISO virtual, lee tus fuentes reales, compone el registro SPF óptimo (raíz y subdominios), te dice qué conservar en include, qué cambiar a DKIM alineado, y qué aislar en un subdominio, para un SPF limpio, bajo el límite y alineado con DMARC.

Analiza tu dominio gratis → o crea una cuenta para una configuración SPF que aguante.