Activar DKIM en Microsoft 365: la guía paso a paso

Connect-ExchangeOnline
New-DkimSigningConfig -DomainName ejemplo.es -KeySize 2048 -Enabled $false
Get-DkimSigningConfig -Identity ejemplo.es |
  Format-List Selector1CNAME, Selector2CNAME

Los dos CNAME: selector1 y selector2

Los valores siguen un patrón previsible. Para ejemplo.es en el tenant contoso, los dos registros que hay que publicar son:

selector1._domainkey.ejemplo.es  CNAME  selector1-ejemplo-es._domainkey.contoso.onmicrosoft.com
selector2._domainkey.ejemplo.es  CNAME  selector2-ejemplo-es._domainkey.contoso.onmicrosoft.com

La parte ejemplo-es es el dominio personalizado con los puntos convertidos en guiones; contoso.onmicrosoft.com es el dominio inicial del tenant. La consola muestra estos valores tal cual —no hay motivo para reconstruirlos a mano, pero conocer el patrón permite detectar una errata al primer vistazo—.

Dos decisiones de diseño merecen explicación. Primero, por qué un CNAME y no un TXT: la clave pública no se publica en la zona del dominio; permanece alojada en Microsoft, al final del alias. Esa indirección es precisamente la que permitirá más adelante la rotación de claves sin ninguna intervención en el DNS. Segundo, por qué dos selectores: selector1 y selector2 se turnan —uno firma, el otro espera la siguiente rotación—. El papel exacto del selector en una firma DKIM, y cómo observarlo en las cabeceras, se disecciona en el selector DKIM explicado.

Este funcionamiento distingue a Microsoft 365 del proceso genérico, en el que el administrador genera su propio par de claves y publica la clave pública como TXT —el camino descrito en cómo generar una clave DKIM—. Aquí, la clave privada nunca sale de la infraestructura de Microsoft: menos libertad, pero también menos ocasiones de comprometerla.

La publicación DNS y sus trampas clásicas

Sobre el papel, publicar dos CNAME lleva tres minutos. En la práctica, cuatro trampas se repiten sin cesar.

El CNAME introducido como TXT. Es el error más común: acostumbrado a otras plataformas, el administrador pega el valor en un registro TXT. Pero Microsoft 365 funciona exclusivamente por alias: la verificación fallará mientras el tipo de registro no sea CNAME. Google Workspace, en cambio, publica la clave pública directamente como TXT: dos lógicas distintas para el mismo estándar, comparadas en activar DKIM en Google Workspace.

El sufijo duplicado. Muchas interfaces DNS añaden automáticamente el dominio al nombre introducido. Escribir selector1._domainkey.ejemplo.es en el campo «nombre» produce entonces selector1._domainkey.ejemplo.es.ejemplo.es: un registro perfectamente publicado y perfectamente inútil. Una consulta dig o una comprobación en línea despeja la duda de inmediato.

La activación demasiado temprana. Mientras los CNAME no resuelvan públicamente, el portal se niega a activar la firma con un error del tipo «CNAME record does not exist». No es un fallo de configuración: es la propagación DNS siguiendo su curso —de unos minutos a unas horas según el TTL y el proveedor, con Microsoft anunciando prudentemente hasta 48 horas—. Reintentar más tarde basta.

Los dominios múltiples. Cada dominio aceptado del tenant tiene su propia configuración: sus dos CNAME, su interruptor, su rotación. Activar DKIM en ejemplo.es no cubre ni los subdominios declarados por separado ni los demás dominios del tenant. El dominio onmicrosoft.com, por su parte, no necesita nada: Microsoft lo firma de forma nativa.

Un último apunte de perímetro: la firma de Exchange Online cubre el correo que sale de Exchange Online. Las plataformas terceras que envían a nombre del dominio —enrutado de marketing, facturación, notificaciones de aplicaciones— firman con sus propios selectores, que se configuran en cada una de ellas.

La verificación: cabeceras y control externo

Una vez accionado el interruptor (o ejecutado Set-DkimSigningConfig -Identity ejemplo.es -Enabled $true), la prueba se lee en las cabeceras. Un mensaje de prueba enviado a un buzón externo —Gmail u Outlook.com sirven— debe exhibir dos cosas. Primero, la propia firma:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=ejemplo.es; s=selector1; ...

El d= lleva ahora el dominio personalizado, y el s= uno de los dos selectores. Después, el veredicto del receptor, en Authentication-Results:

Authentication-Results: ...; dkim=pass header.d=ejemplo.es;
  dmarc=pass header.from=ejemplo.es

dkim=pass con header.d=ejemplo.es: la firma es válida y está alineada. Si ya hay un registro DMARC publicado, el dmarc=pass sigue mecánicamente.

Del lado de la consola, Get-DkimSigningConfig debe mostrar Enabled : True, y el portal Defender el interruptor en posición activa. Para un control exterior sin bucear en cabeceras, una comprobación en línea del dominio restituye el estado DNS observable —registros publicados, resolución de los selectores— y lo confronta con la política DMARC vigente. En los días siguientes, los informes agregados confirman el cambio: los volúmenes emitidos por Exchange Online pasan a DKIM alineado.

La rotación de selectores sin tocar la zona DNS

Una clave DKIM no es eterna: las buenas prácticas recomiendan una rotación periódica, y precisamente para eso Microsoft impone dos selectores. La rotación se dispara con un botón en el portal («Rotar claves DKIM») o en PowerShell:

Rotate-DkimSigningConfig -Identity ejemplo.es -KeySize 2048

La mecánica es elegante. Microsoft genera un nuevo par de claves y publica la nueva clave pública detrás del selector inactivo —en el lado de Microsoft, al final del CNAME—. Adquirida la propagación, la firma bascula al nuevo selector; el antiguo se convierte a su vez en la reserva de la próxima rotación. En ningún momento se modifica la zona DNS del dominio: los dos CNAME publicados el primer día siguen valiendo de por vida. Ahí está todo el interés de la indirección por alias.

La rotación es también la ocasión de modernizar una configuración antigua: los tenants configurados hace años a veces siguen firmando con 1024 bits; una rotación con -KeySize 2048 lleva la clave al estándar actual sin un segundo de interrupción. Una rotación anual, anclada a una revisión de seguridad existente, es un ritmo razonable —la operación es indolora y no hay razón para privarse de ella—.

Lo que la firma alineada desbloquea para DMARC

Activar DKIM en el dominio personalizado no es un fin en sí mismo: es la pieza que hace a DMARC realmente fiable en un tenant de Microsoft 365.

Primero, porque DKIM sobrevive donde SPF se rompe. Un reenvío de buzón a buzón, una lista de distribución, un relé: en todos esos escenarios cambia la IP emisora y SPF pierde el alineamiento. La firma DKIM, en cambio, viaja dentro del mensaje y sigue siendo verificable a la llegada mientras el contenido firmado no se altere. Un dominio cuyo correo de Exchange Online está firmado y alineado conserva un dmarc=pass en la mayoría de los caminos de reenvío: la condición indispensable para plantearse una política estricta sin perder correo legítimo.

Segundo, porque los informes se vuelven legibles. Con un DKIM alineado, los volúmenes legítimos emitidos por Exchange Online se distinguen con nitidez de las fuentes no autenticadas; lo que sigue fallando merece entonces una investigación de verdad —una plataforma olvidada o un intento de suplantación—. Sobre esa base sana se construye la subida de política, de p=none a p=quarantine y de ahí a p=reject, con plantillas comentadas para cada etapa en los ejemplos de registros DMARC listos para adaptar.

Por último, el alineamiento DKIM es el prerrequisito de resultados más visibles: las exigencias de los grandes proveedores de correo hacia los remitentes de volumen y, a término, la exhibición del logotipo vía BIMI, que presupone una política DMARC aplicada.

En resumen

Microsoft 365 firma por defecto con el dominio técnico onmicrosoft.com: un DKIM válido pero no alineado y, por tanto, mudo para DMARC. La activación útil cabe en tres gestos: crear la configuración de firma (portal Defender o New-DkimSigningConfig), publicar los dos CNAME selector1/selector2._domainkey apuntando a contoso.onmicrosoft.com, y encender la firma una vez adquirida la propagación. Las trampas son conocidas: un CNAME introducido como TXT, un sufijo duplicado por la interfaz DNS, una activación demasiado temprana y unos dominios múltiples que reclaman cada uno su propio par. La verificación se lee en las cabeceras (dkim=pass header.d=ejemplo.es), la rotación no toca la zona, y la ganancia es inmediata: un alineamiento DKIM que resiste los reenvíos y abre el camino hacia p=reject.

Para situar el punto de partida, un análisis DMARC gratuito del dominio muestra en segundos el estado de los registros publicados y lo que queda por corregir. Y para seguir el efecto de la activación en los informes agregados —semana a semana, fuente a fuente—, la creación de una cuenta abre el panel que convierte esos datos en bruto en un plan de acción hacia una política aplicada.