SPF, DKIM y DMARC en Microsoft 365: registros, portal de Defender y comprobación

Para autenticar el correo de Microsoft 365 con tu dominio propio publica tres cosas en el DNS: un TXT de SPF con v=spf1 include:spf.protection.outlook.com -all, dos CNAME de DKIM (selector1._domainkey y selector2._domainkey) con los valores que te da el portal de Defender, y un TXT de DMARC en _dmarc, empezando por p=none. Después, activa la firma DKIM.

Para comprobarlo en tu web: Auditoría SEO

Tres definiciones en una línea cada una. SPF es la lista de servidores autorizados a enviar con tu dominio. DKIM es una firma en cada mensaje que el destinatario comprueba con una clave pública publicada en tu DNS. DMARC dice qué hacer con lo que no pasa SPF ni DKIM alineados con el remitente visible y a quién mandar informes. Esta guía concreta los tres para Microsoft 365 con la documentación de Microsoft Learn actualizada el 03-07-2026; si usas Google, la guía equivalente es la de SPF, DKIM y DMARC en Google Workspace.

¿Qué hace Microsoft 365 solo y qué tienes que hacer tú?

Así lo resume Microsoft en sus tres guías123. Un detalle importante: Microsoft 365 no tiene ningún portal ni cmdlet para gestionar el SPF; se escribe en el DNS de tu dominio, en tu registrador o proveedor de DNS1.

Paso 1: el registro SPF

Si solo envías correo con Microsoft 365, el registro TXT en la raíz del dominio es1:

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

Lo que dice Microsoft sobre cada parte:

1. -all en lugar de ~all. Microsoft recomienda el fallo duro (-all) porque también recomienda DKIM y DMARC. Explica que DMARC trata los dos como fallo de SPF, pero que con ~all la política DMARC queda en la práctica sin efecto sobre los mensajes que fallan SPF y no llevan firma DKIM1. Google, en cambio, recomienda ~all para Google Workspace.
2. Un solo registro SPF por dominio o subdominio. Dos registros hacen que SPF devuelva permerror1. Si envías también con otro servicio, añade su include: al mismo registro.
3. Menos de 10 consultas DNS. include:, a, mx, exists y redirect cuentan; ip4:, ip6: y all no. Los include: anidados suman sus propias consultas. Tener menos de diez include: no garantiza tener menos de diez consultas1.
4. No «aplanes» el include de Microsoft (sustituirlo por IP): su infraestructura de envío usa direcciones que cambian a menudo1.
5. TTL de al menos 3600 segundos para evitar tiempos de espera en las consultas1.

Cada subdominio que envíe correo necesita su propio SPF. Para servicios que no controlas, como una plataforma de boletines, Microsoft recomienda usar un subdominio (marketing.example.com) para que sus problemas no afecten a la reputación del dominio principal1.

Paso 2: DKIM con los dos CNAME

Microsoft 365 genera dos pares de claves por dominio y publica las claves públicas en su propia zona. Tú solo creas dos registros CNAME que apuntan a ellas; uno está activo y el otro espera a la siguiente rotación2.

El formato de los CNAME cambió en mayo de 2025

Los dominios propios añadidos desde mayo de 2025 usan un formato de destino nuevo2:

selector1._domainkey  →  selector1-<dominio-con-guiones>._domainkey.<prefijo-inicial>.<letra>-v1.dkim.mail.microsoft
selector2._domainkey  →  selector2-<dominio-con-guiones>._domainkey.<prefijo-inicial>.<letra>-v1.dkim.mail.microsoft

<dominio-con-guiones> es tu dominio con guiones en lugar de puntos (example-com), <prefijo-inicial> es la parte variable de tu dominio onmicrosoft.com y <letra> es un carácter que asigna Microsoft (por ejemplo n o r) y que no puedes elegir. Los dominios que ya existían siguen con el formato antiguo, selector1-example-com._domainkey.example.onmicrosoft.com, y los dos formatos no pueden convivir en el mismo selector2. Por eso Microsoft insiste: copia el valor exacto del portal o de PowerShell; los de la documentación son ilustrativos.

Activarlo en el portal de Microsoft Defender

1. Abre Email & collaboration > Policies & rules > Threat policies > Email authentication settings (en la interfaz en español, Correo electrónico y colaboración > Directivas y reglas > Directivas contra amenazas > Configuración de autenticación de correo electrónico), o ve directo a https://security.microsoft.com/authentication?viewid=DKIM2.
2. En la pestaña DKIM, busca tu dominio. Su estado debe ser NoDKIMKeys y el interruptor, deshabilitado.
3. Intenta activar el interruptor. Aparece un error con los valores de los CNAME; acéptalo. El estado pasa a CnameMissing.
4. Abre el detalle del dominio y copia los dos valores de Publish CNAMEs.
5. En tu proveedor de DNS, crea los dos CNAME.
6. Al rato (Microsoft habla de unos minutos o más), vuelve al detalle y activa Sign messages for this domain with DKIM signatures. El estado debe pasar a «Signing DKIM signatures for this domain»2.

O con PowerShell de Exchange Online

# Estado y valores de los CNAME de todos los dominios
Get-DkimSigningConfig | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

# Si el dominio no aparece: crear la configuración con clave de 2048 bits (por defecto es 1024)
New-DkimSigningConfig -DomainName example.com -Enabled $false -KeySize 2048

# Cuando los dos CNAME estén publicados: activar la firma
Set-DkimSigningConfig -Identity example.com -Enabled $true

Los tres cmdlets y el parámetro -KeySize (1024 por defecto, o 2048) están en la guía de Microsoft2. Si Set-DkimSigningConfig no encuentra los CNAME, devuelve un error con los valores esperados: revisa guiones, puntos y guiones bajos, espera y repite. Para rotar las claves más adelante existe Rotate-DkimSigningConfig, y el cambio tarda cuatro días (96 horas) en aplicarse2.

Paso 3: DMARC por fases

Antes de DMARC, Microsoft pide tener SPF y DKIM configurados en todos los dominios y subdominios que envían desde Microsoft 3653. El registro va como TXT en el host _dmarc, que es obligatorio.

Microsoft propone empezar por un dominio o subdominio con poco volumen y subir por fases3:

1. p=none: no se pide ninguna acción. Lees los informes agregados (rua) y corriges los remitentes que fallan.
2. p=quarantine: el correo que falla se acepta pero marcado, por ejemplo en correo no deseado.
3. p=reject: el correo que falla se rechaza. Es el objetivo final para todos tus dominios.

Dos matices de la documentación. Con p=quarantine o p=reject, el correo saliente de Microsoft 365 que falla DMARC en el destino sale por su grupo de entrega de alto riesgo, sin excepción posible3. Y los informes agregados suelen llegar una vez al día, en un XML comprimido que es difícil de leer a mano: Microsoft sugiere automatizarlo o usar un servicio de informes DMARC3.

Los ejemplos de Microsoft llevan pct=100. El RFC 9989, publicado en mayo de 2026 para sustituir a la especificación original de DMARC, retiró esa etiqueta y la marca como histórica4; como 100 es además el valor por defecto según Microsoft, en el ejemplo de abajo no la incluyo.

No olvides el dominio onmicrosoft.com si no lo usas para enviar: Microsoft recomienda publicar en él v=DMARC1; p=reject desde el centro de administración de Microsoft 365, en Settings > Domains > tu dominio onmicrosoft.com > DNS records > Add record3.

Los registros de ejemplo para example.com

Así queda la zona DNS de un dominio añadido después de mayo de 2025, con el dominio inicial example.onmicrosoft.com. La letra n de los CNAME es ilustrativa: la tuya puede ser otra.

example.com.                       3600 IN TXT   "v=spf1 include:spf.protection.outlook.com -all"
selector1._domainkey.example.com.  3600 IN CNAME selector1-example-com._domainkey.example.n-v1.dkim.mail.microsoft.
selector2._domainkey.example.com.  3600 IN CNAME selector2-example-com._domainkey.example.n-v1.dkim.mail.microsoft.
_dmarc.example.com.                3600 IN TXT   "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

¿Qué exige Outlook.com a los remitentes de alto volumen?

Microsoft anunció el 02-04-2025 requisitos para los dominios que envían más de 5.000 mensajes al día a su servicio de consumo, Outlook.com, que incluye las direcciones outlook.com, hotmail.com y live.com5:

La entrada en vigor fue el 05-05-2025. En una actualización del 29-04-2025, Microsoft cambió el plan inicial de enviar lo que no cumple a correo no deseado y decidió rechazarlo con el error 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.5 Si ves ese error en un rebote, el problema es la autenticación de tu dominio, no el destinatario.

Cómo comprobarlo

1. En un mensaje real: envía un correo a una cuenta de otro sistema (Gmail u Outlook.com). Microsoft avisa de que dentro de tu propia organización el mensaje no lleva firma DKIM, y desaconseja probar con AOL2. En la cabecera, DKIM-Signature debe mostrar d=example.com y Authentication-Results, dkim=pass, spf=pass y dmarc=pass.
2. Con el analizador de cabeceras: Microsoft enlaza el Message Header Analyzer en https://mha.azurewebsites.net para leer cabeceras largas2.
3. En PowerShell: Get-DkimSigningConfig debe mostrar Enabled: True y Status: Valid para tu dominio2.
4. En el DNS: consulta el TXT de la raíz y de _dmarc.example.com y los CNAME de los dos selectores con cualquier herramienta de DNS pública.

Qué hace SmoothSeen con esto

SmoothSeen consulta el DNS del dominio que analizas y comprueba si tiene un registro SPF y un registro DMARC, y con qué política. No comprueba DKIM: la clave pública está en un nombre que depende del selector, y aunque en Microsoft 365 los selectores se llamen selector1 y selector2, otros proveedores usan nombres distintos y no se pueden adivinar desde fuera. Para DKIM, la prueba fiable es la cabecera de un mensaje real.

Qué hacer esta semana

Ejecuta Get-DkimSigningConfig o abre la pestaña DKIM del portal de Defender y comprueba que tus dominios propios están en «Valid». Si alguno sigue en CnameMissing, publica los CNAME hoy y deja DMARC en p=none para leer los primeros informes. Para revisar después el resto de tu web, analízala con SmoothSeen.

Preguntas frecuentes

¿Por qué Microsoft recomienda -all y Google ~all?

Son criterios distintos de cada proveedor. Google prefiere que el correo de servidores no listados se marque como sospechoso. Microsoft prefiere -all porque, según su documentación, con ~all la política DMARC queda sin efecto práctico sobre los mensajes que fallan SPF y no llevan firma DKIM. Si usas los dos servicios a la vez, publica un único SPF con los dos include:.

¿Por qué mis CNAME de DKIM no se parecen a los de los tutoriales?

Porque Microsoft cambió el formato en mayo de 2025. Los dominios añadidos desde entonces apuntan a un nombre terminado en dkim.mail.microsoft, con una letra que asigna Microsoft; los anteriores siguen apuntando a tu dominio onmicrosoft.com. Copia siempre los valores del portal de Defender o de Get-DkimSigningConfig, nunca de un ejemplo.

¿Tengo que crear DMARC para el dominio onmicrosoft.com?

Microsoft lo recomienda. SPF y DKIM ya vienen configurados en ese dominio, pero DMARC no. Si no lo usas para enviar correo, publica v=DMARC1; p=reject desde el centro de administración de Microsoft 365, en el apartado de dominios y registros DNS. Así nadie puede suplantarlo con éxito ante los servidores que aplican DMARC.

¿Qué significa el error 550 5.7.515?

Es el rechazo de Outlook.com a un dominio que le envía más de 5.000 mensajes al día sin cumplir sus requisitos de autenticación: SPF que pase, DKIM que pase y DMARC con al menos p=none alineado con uno de los dos. La solución está en el DNS y en la firma DKIM del dominio que envía, no en el buzón del destinatario.