Configurar SPF, DKIM y DMARC en Microsoft 365

Qué hace Microsoft por ti y qué no

Microsoft 365 envía tus correos con tu dominio en el sobre, así que el permiso SPF, una vez publicado, alinea solo. El asistente de alta de Microsoft ya te pidió ese registro al conectar el dominio, y por eso casi todos los dominios con Microsoft 365 pasan DMARC desde el primer día.

La firma no viene hecha. Microsoft lo dice tal cual en su documentación: el correo de los dominios propios no lleva firma DKIM hasta que la configuras. Mientras tanto, tus correos pasan DMARC solo por el SPF. Funciona, hasta que alguien se reenvía uno de tus correos a otra cuenta: el reenvío rompe el SPF, no hay firma tuya que lo sostenga, y esa copia falla.

Y el DMARC no lo pone Microsoft. Es tu registro, y es el que decide qué pasa con lo que no supera las comprobaciones. Si no sabes por dónde empezar con él, está en qué es DMARC y por qué p=none no te protege de nada.

Cómo se hace

1. El permiso SPF. En el panel de tu DNS, un registro TXT en el nombre raíz del dominio (@ en la mayoría de los paneles). Este es el que propone Microsoft, si es lo único que envía:

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

   Con ~all en vez de -all también funciona. Si usas más herramientas que envían con tu sobre, van todas en ese mismo registro: un dominio solo puede tener un SPF.

   Si ya trabajas con nosotros la seguridad y la configuración de tu dominio, este permiso no lo añades tú: Deliveruti lo publica por ti. Dile al asistente que empiezas a usar Microsoft 365, y listo. Lo que sí sigue siendo tuyo es lo demás: los MX y la firma.

2. Las claves de la firma. Entra en security.microsoft.com/authentication con una cuenta de administrador de Microsoft 365 y abre la pestaña DKIM. Ahí están tus dominios. Pulsa en la fila del tuyo, en el nombre y no en la casilla, y en la ficha que se abre elige «Create DKIM keys» (crear claves DKIM). La ficha te enseña entonces dos registros en el apartado «Publish CNAMEs».

   Si en vez de abrir la ficha intentas activar el interruptor de la lista, sale un «Client error» con un texto largo. No has roto nada: el error trae los mismos dos valores, y el estado del dominio pasa a «CnameMissing».

3. Los dos CNAME. En tu DNS, dos registros de tipo CNAME. Los nombres son siempre los mismos, selector1._domainkey y selector2._domainkey. Los valores son tuyos y te los da el portal. Tienen una de estas dos formas:

   selector1-tudominio-com._domainkey.tuempresa.n-v1.dkim.mail.microsoft
   selector1-tudominio-com._domainkey.tuempresa.onmicrosoft.com
   

   La primera es la de los dominios añadidos desde mayo de 2025. La segunda, la de los anteriores, que siguen igual. Copia el valor del portal, no lo escribas a mano ni lo copies de un tutorial. Hacen falta los dos registros, aunque solo uno firme cada vez.

4. Activar la firma. Este es el paso que se olvida. Pasados unos minutos, vuelve a la ficha del dominio y activa «Sign messages for this domain with DKIM signatures» (firmar los mensajes de este dominio con DKIM). Si Microsoft ya ve tus CNAME, el estado cambia y la firma empieza a funcionar en minutos. Si no los ve, el estado sigue en «CnameMissing».

5. Comprobar. Envíate un correo a una cuenta de Gmail y abre «Mostrar original». En la línea de DKIM tiene que poner PASS con tu dominio.

6. El DMARC. Un TXT en _dmarc con p=none y una dirección para los informes, para empezar. Subir la política es otro trabajo, con los informes delante.

Si contrataste Microsoft 365 con GoDaddy

GoDaddy revende Microsoft 365, y eso añade dos detalles.

El primero, dónde se activa la firma. Es el mismo portal de Defender, pero se entra con la dirección y la contraseña de Microsoft 365, no con el usuario de GoDaddy. Los CNAME se crean después donde esté tu DNS, y se vuelve a Defender a activar. Si además tienes contratada su «Seguridad avanzada del correo electrónico», la firma se gestiona desde esa pantalla de GoDaddy y es un registro TXT, no dos CNAME: sigue la ayuda de GoDaddy para ese caso.

El segundo, el SPF. GoDaddy suele dejar include:secureserver.net, que autoriza toda su infraestructura y, dentro, la de Microsoft. Funciona, pero si tu correo sale por Microsoft 365, el permiso que lo autoriza es include:spf.protection.outlook.com. El de GoDaddy autoriza además servidores que no envían tu correo y gasta consultas de las diez.

Lo que vemos en los dominios que vigilamos

• Los CNAME publicados y la firma sin activar. Es lo más habitual: alguien crea las claves, publica los dos registros y no vuelve a Defender a activar la firma. El registro existe, pero detrás no hay ninguna clave servida, y los correos siguen saliendo sin firma. En los informes se ve como 0 % de firma con los registros ya en el DNS.
• El «CnameMissing» que no se va. Casi siempre es el nombre. Muchos paneles añaden el dominio al final por su cuenta, y si escribes selector1._domainkey.tudominio.com acabas con selector1._domainkey.tudominio.com.tudominio.com. Escribe solo selector1._domainkey. Si tu DNS está en Cloudflare, el proxy tiene que estar desactivado (nube gris) en esos registros.
• Los cuatro días. La documentación de Microsoft habla de cuatro días, y es fácil leerlo como el tiempo que tarda la activación. No lo es: cuatro días es lo que tarda en entrar una clave nueva cuando las rotas. Detectar los CNAME lleva minutos, y activar la firma, también.
• El valor de un tutorial. Un CNAME copiado de una guía con el formato antiguo, cuando tu dominio usa el nuevo, apunta a una clave que no existe. El valor bueno es siempre el que enseña tu portal.
• Los informes de Microsoft llegan con dos días de retraso. Un cambio hecho hoy aparece en sus informes pasado mañana. Los de Google, al día siguiente.

Desde mayo de 2025, Outlook.com exige a quien envía más de cinco mil correos al día a sus buzones personales que pasen SPF y DKIM y tengan DMARC, aunque sea en observación. Lo que no cumple se rechaza con el error 550 5.7.515. Con la firma activada y un DMARC publicado, un dominio con Microsoft 365 lo cumple.