Última actualización: julio de 2026

En resumen: Al terminar esta guía tu dominio publicará un registro SPF correcto para Microsoft 365 — incluidos los casos especiales de configuración híbrida, subdominio de newsletter y dominios aparcados.

Requisitos previos

  • Un tenant de Microsoft 365 con tu propio dominio
  • Acceso a la gestión de DNS de tu dominio — que no está en Microsoft, sino en tu proveedor de dominio/DNS

¿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 consultan el registro en cada mensaje entrante y comprueban si el servidor que lo entrega está en la lista. Sin SPF, cualquier servidor puede enviar correo en tu nombre — y tu correo legítimo acaba antes en spam.

Para ponerlo en contexto: SPF por sí solo no es una protección completa. Solo junto con DKIM y DMARC se convierte en una base sólida — y el propio Microsoft recomienda expresamente los tres.

El punto de partida en Microsoft 365

Dos cosas distinguen a Microsoft 365 de los hosts clásicos:

1. No hay una interfaz de SPF en Microsoft 365. La documentación de Microsoft lo dice claramente: la entrada TXT de SPF se crea en el registrador de dominio — no hay ninguna configuración de SPF disponible en el propio Microsoft 365. Así que introduces el registro allí donde está tu zona DNS. Cómo funciona en cada caso lo muestran nuestras guías para IONOS, Strato, All-Inkl y Netcup.

2. Microsoft recomienda -all (hardfail). Mientras que los hosts alemanes casi siempre sugieren el más suave ~all, Microsoft recomienda expresamente -all para dominios de 365 — argumentando que DKIM y DMARC forman parte del cuadro de todos modos, y que DMARC con ~all no surte efecto sin una firma DKIM.

La única excepción: no puedes cambiar la entrada SPF de tu dominio *.onmicrosoft.com — ese lo gestiona Microsoft.

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. Muchos dominios ya tienen un registro SPF del host; ese hay que ampliarlo para Microsoft 365, no reemplazarlo.

2. Elige el registro correcto

Solo envía Microsoft 365 (el caso normal):

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

La mayoría de las organizaciones de Microsoft 365 necesitan exactamente este valor include. Apunta a una lista plana de rangos IP de Microsoft (IPv4 + IPv6) y cuesta solo un único lookup de DNS.

Configuración híbrida con un servidor Exchange/de correo local: añade la IP pública de tu servidor, el ejemplo propio de Microsoft:

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

Envío de newsletter/masivo a través de un servicio externo: Microsoft recomienda para esto un subdominio dedicado (p. ej. marketing.example.com), para que la reputación de tu dominio principal quede intacta. El registro del subdominio (el ejemplo de Microsoft con el servicio ficticio Adatum):

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

Dominios aparcados que nunca envían: prohíbe el envío por completo:

v=spf1 -all

3. Introduce el registro en el proveedor de DNS

Crea el valor elegido como registro TXT en el dominio principal (host @) — en tu registrador o host de DNS, no en el centro de administración de Microsoft 365. Si ya existe ahí una entrada TXT con v=spf1, edítala y añade include:spf.protection.outlook.com — solo se permite una entrada SPF por dominio.

4. Ten en cuenta los subdominios

Según Microsoft, cada subdominio definido necesita su propia entrada SPF — el registro del dominio principal no se aplica automáticamente. Para subdominios no definidos, DMARC asume la protección.

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.protection.outlook.compermite la infraestructura de envío de Microsoft 365 (lista plana IPv4/IPv6, 1 lookup)
ip4: / ip6:permite servidores propios individuales (escenario híbrido)
-allhardfail: los servidores no listados se rechazan — la recomendación de Microsoft para dominios de 365

Casos especiales para nubes gubernamentales de EE. UU.: GCC High y DoD usan v=spf1 include:spf.protection.office365.us -all en lugar del include estándar.

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. Colocar el registro de Microsoft junto al registro del host existente produce un permerror — los servidores receptores entonces ignoran SPF por completo. Todos los valores include van en un único registro.

Olvidar los subdominios. Cada subdominio que envía (newsletter, sistema de tickets) necesita su propia entrada SPF. El dominio principal no los cubre.

~all por vieja costumbre. Con Microsoft 365 no hay motivo para softfail: Microsoft recomienda -all, precisamente porque se añaden DKIM y DMARC. Mantener ~all regala efecto protector.

+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