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

La regla de oro no admite excepción: un solo registro v=spf1 por dominio. Publicar un registro para Microsoft y otro para Google crea 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. Los dos reunidos, el contador marca ya seis o siete resoluciones antes del más mínimo proveedor tercero.

Ahora bien, el límite de búsquedas DNS de SPF es de diez. Solo quedan, pues, tres o cuatro resoluciones para el router de marketing, la facturación, la 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 los otros proveedores

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

1. Separar por subdominio. Mantener Microsoft 365 o Google Workspace en el dominio raíz (la mensajería humana), y hacer salir el marketing desde news.ejemplo.es y el transaccional desde notif.ejemplo.es, 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. Priorizar la alineación DKIM para los terceros. Un router que firma en DKIM alineado (d=ejemplo.es) satisface DMARC sin consumir resolución SPF. Es a menudo la mejor forma de integrar un proveedor sin sobrecargar el registro.
3. Congelar en ip4: los proveedores con IP estables, como último recurso, vigilando que no cambien.

Apilar los include en el dominio raíz «porque es más simple» hay que evitarlo a toda costa: 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 el SPF. Durante la transición, el correo sale de ambas plataformas: el 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, sobre todo nada de dos registros separados «mientras dura la migración»: es el doble registro asegurado, y el PermError que lo acompaña. Segundo, hay que pensar en 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: anotar desde el principio la fecha prevista de retirada del antiguo include, para no dejarlo rondar meses y descubrir un PermError una buena mañana.

Las trampas específicas

Algunos errores reaparecen con estas dos plataformas:

• Recopiar IP de Google o Microsoft a mano. El vínculo automantenido se rompe, y los fallos aparecen en cuanto los rangos cambian. Los include oficiales siguen siendo la única vía segura.
• Olvidar los subdominios de envío. Un envío desde mail.ejemplo.es exige un SPF propio de ese subdominio: el SPF de la raíz no se aplica automáticamente a los subdominios.
• Confundir SPF y DKIM/DMARC. Configurar el include no basta: queda activar la firma DKIM del lado de Microsoft o Google (mediante su consola), y publicar el registro DMARC.
• Mezclar tenants. Con varios tenants de Microsoft o varios dominios de Google, cada uno tiene su configuración; mezclar sus include sin verificar lo que autorizan realmente lleva directo al accidente.

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 un 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 el From:— la que hace la protección, no el SPF solo. Ambas plataformas ofrecen su DKIM en unos clics; detenerse en el SPF sería un error. Una vez las tres piezas implementadas, el objetivo es p=reject del lado de DMARC, para que la suplantación del dominio sea realmente rechazada y no solo observada.

La propagación DNS, a no olvidar

Un detalle operativo que a menudo se olvida: una modificación SPF no es instantánea. Los resolutores del mundo entero mantienen el 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), hay que bajar 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, el TTL sube a un valor normal. Y un cambio que «no funciona» al primer minuto no prueba nada: más vale interrogar a varios resolutores antes de retocar el registro, so pena de apilar correcciones sobre un simple retraso de caché.

Verificar la configuración

Una vez implementado el registro, el control es simple: 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 mostrar su coste real. El procedimiento completo está en cómo verificar un registro SPF. Y lo esencial no se pierde de vista: 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? -all se impone una vez listadas todas las 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 el From:. Para la mensajería humana, la alineación suele ser buena; para los terceros que envían «en nombre del dominio» a través de esas plataformas, la alineación se verifica en los 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. La salida: aislar el router en un subdominio, o cambiarlo a DKIM alineado.

¿Pueden convivir Microsoft 365 y Google Workspace en el mismo dominio? Sí, combinando sus include en un solo registro. El recuento queda por vigilar, porque los dos juntos consumen ya una buena mitad del presupuesto.

¿Hay que configurar SPF cuando DKIM ya está implementado? Sí, ambos son complementarios. SPF y DKIM cubren casos diferentes, y DMARC se apoya en uno u otro alineado. Los dos van juntos: ver cómo funcionan los tres protocolos juntos.

Thomas compone el registro

Combinar Microsoft, Google y los terceros bajo la barra de las diez resoluciones es un rompecabezas. Thomas, el CISO virtual, lee las fuentes reales, compone el registro SPF óptimo (raíz y subdominios), indica 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.

Analizar un dominio gratis o crear una cuenta para una configuración SPF que aguante.