¿Necesito DKIM si mi SPF ya pasa en Microsoft 365?

Sí. Microsoft firma el correo saliente con el dominio onmicrosoft.com de tu tenant hasta que activas DKIM para el dominio propio, así que un tenant nuevo en la práctica queda autenticado solo con SPF. El SPF es la mitad que se rompe con cualquier reenvío, y DMARC necesita al menos un resultado alineado, así que sin DKIM de tu propio dominio no tienes respaldo.

¿Por qué el DKIM muestra header.d=contoso.onmicrosoft.com y no mi dominio?

Porque todavía no activaste la firma DKIM para el dominio propio. Publica los CNAME de selector1 y selector2 que te muestra el portal de Defender, espera a que resuelvan y luego activa la firma para ese dominio. Desde ahí el correo saliente se firma con tu dominio, que es lo que exige la alineación de DMARC.

¿Puedo pasar directo a p=reject en un dominio de Microsoft 365?

Publicarlo puedes, pero no lo hagas hasta que los reportes agregados en p=none te hayan mostrado todos tus remitentes por un par de semanas. En reject, todo lo que no esté alineado empieza a fallar, y en la mayoría de los tenants eso primero significa el correo de facturación, del CRM o del escáner, no algo malicioso.

SPF, DKIM y DMARC en Microsoft 365

Por qué el correo de Microsoft 365 falla en Gmail aunque el tenant se vea sano

Exchange Online manda tu correo esté autenticado tu dominio o no. Eso es lo que confunde. Los mensajes salen, la carpeta de enviados se llena, nada aparece en rojo en el centro de administración, y aun así un cliente en Gmail te dice que tu cotización cayó en spam, o te regresa un rebote diciendo que el mensaje no venía autenticado.

En un dominio de Microsoft 365 la causa casi siempre es la misma historia de tres partes: el SPF se publicó cuando se agregó el dominio, el DKIM del dominio propio nunca se activó, y el DMARC nunca se publicó. Microsoft firma el correo saliente con el dominio onmicrosoft.com de tu tenant hasta que tú activas DKIM para el dominio propio. Entonces sí hay una firma, pero lleva el dominio equivocado y no sirve de nada para la dirección que tu lector ve en el campo De. Terminas autenticado solo con SPF, que es la mitad frágil: el SPF se rompe con cualquier reenvío, y no hay firma DKIM de tu propio dominio que sirva de respaldo.

Los tres registros, en el orden que no te tumba el correo

Publica primero SPF, después DKIM y al final DMARC. Cada registro demuestra algo distinto, y DMARC es el único que puede empezar a rechazar correo, así que entra cuando ya confirmaste que los otros dos funcionan.

SPF dice qué servidores tienen permiso de entregar tu correo a internet. Se revisa contra el remitente del sobre, la dirección del comando SMTP MAIL FROM, no contra el De que ve tu lector.
DKIM le pone una firma criptográfica al mensaje. El receptor busca la llave pública en tu DNS y confirma que el mensaje lo firmó quien controla ese dominio y que nadie lo alteró en el camino.
DMARC amarra cualquiera de los dos resultados al dominio que aparece en el De visible, y le dice al receptor qué hacer cuando ninguno cuadra. Un mensaje pasa DMARC cuando SPF o DKIM pasa y el dominio con el que pasó está alineado con el del De. Con uno de los dos basta, y por eso justamente importa el que falta.

SPF: un include, y el presupuesto de consultas que gastas después

Para un tenant que solo envía por Exchange Online, Microsoft documenta un solo registro:

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

El -all del final es un fallo duro: lo que no esté autorizado se debe rechazar. Microsoft documenta ese y también el más suave ~all. Empieza con ~all si de verdad no estás seguro de haber encontrado todos tus remitentes, y aprieta a -all cuando tus reportes DMARC ya te muestren la lista completa. Nunca publiques dos registros SPF para el mismo dominio. Si ya existe uno, fusiona el include ahí.

Ese registro es barato. Deja de serlo en cuanto agregas un CRM, un sistema de facturación, una plataforma de marketing y una mesa de ayuda, porque el RFC 7208, sección 4.6.4, limita la evaluación de SPF a 10 consultas DNS y obliga al receptor a devolver permerror si te pasas. Cada término include, a, mx, ptr, exists y redirect cuesta una consulta, incluidos los que van anidados dentro del include de alguien más. Las entradas ip4 e ip6 no cuestan nada, y por eso los entornos híbridos ponen directo las IP de salida de sus servidores locales en lugar de agregar otro include:

example.com.   TXT   "v=spf1 ip4:203.0.113.25 include:spf.protection.outlook.com -all"

Cuenta el registro en vivo con una herramienta que siga los includes anidados, no contando las entradas que alcanzas a ver. El conteo completo y las salidas posibles las explicamos en la guía del límite de consultas de SPF.

DKIM: dos CNAME, y por qué Microsoft pide dos

Microsoft 365 usa dos selectores por dominio propio, selector1 y selector2, para poder rotar las llaves de firma sin dejar un hueco. Publicas dos registros CNAME que apuntan a llaves que Microsoft guarda por tu tenant:

selector1._domainkey.example.com.   CNAME   selector1-example-com._domainkey.contoso.onmicrosoft.com.
selector2._domainkey.example.com.   CNAME   selector2-example-com._domainkey.contoso.onmicrosoft.com.

Saca los valores exactos del portal en lugar de armarlos a mano. El patrón es predecible, pero el nombre del tenant dentro del destino tiene que estar bien o la consulta no resuelve a nada. En el portal de Microsoft Defender esto vive en Correo electrónico y colaboración, Directivas y reglas, Directivas de amenazas, DKIM. Microsoft reacomoda ese menú cada tanto, así que busca DKIM dentro del portal si no está donde lo esperas.

Aquí el orden también importa. Publica los dos CNAME, espera a que resuelvan y después activa la firma para el dominio. Si activas primero, falla, porque Microsoft verifica que puede leer las llaves antes de firmar con ellas. En tenants viejos vale la pena revisar el largo de la llave: 2048 bits es el estándar actual, y una configuración creada hace años puede seguir en 1024. En PowerShell de Exchange Online eso vive en la configuración de firma, por ejemplo New-DkimSigningConfig -DomainName example.com -KeySize 2048.

Una vez activada la firma para el dominio propio, el correo saliente se firma con ese dominio en lugar del onmicrosoft.com. Ese solo cambio es lo que convierte al DKIM de adorno en un identificador que DMARC sí puede usar.

DMARC: publícalo en p=none y después lee los reportes

El registro es una entrada TXT en el subdominio _dmarc:

_dmarc.example.com.   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

p=none no cambia nada en la entrega. Le pide a los receptores que te manden reportes agregados con cada dirección IP que envía como tu dominio, y si SPF y DKIM pasaron y alinearon en cada caso. Esa lista es el único inventario honesto de tus remitentes, y siempre es más larga que la que tienes en la cabeza: el sistema contable, la herramienta de agendas que alguien contrató, el escáner de la oficina.

Déjalo en p=none unas dos semanas, arregla cada remitente legítimo hasta que alinee, y luego pasa a p=quarantine y por último a p=reject. Llegar a aplicar la política es el objetivo, y la guía de Microsoft recorre el mismo camino de monitorear, cuarentena y rechazo, pero saltar directo a reject en un dominio que no inventariaste es exactamente como dejan de llegar las facturas. Vale saberlo también en el otro sentido: Exchange Online Protection evalúa DMARC en el correo entrante y respeta la política que publicó el dominio remitente, así que tu propia política también protege a tu equipo del correo que suplanta tu dominio. Microsoft publica además una guía aparte para poner reportes DMARC en dominios estacionados y en el dominio de enrutamiento onmicrosoft.com del tenant, y las dos valen la pena una vez que el dominio principal ya quedó.

Las trampas de alineación propias de Microsoft 365

Hay cuatro cosas que rompen la alineación en tenants que por fuera se ven bien configurados:

La firma con onmicrosoft.com. La más común por mucho. Un DKIM que pasa con header.d=contoso.onmicrosoft.com cuando tu De es de example.com no alinea, y DMARC simplemente lo ignora.
Los subdominios. Una política DMARC cubre los subdominios a través del dominio padre, salvo que la sobrescribas con sp=. Si un subdominio manda correo real desde otra plataforma, dale su propio SPF y DKIM en lugar de descubrirlo en un reporte cuando ya estás en reject.
Servicios de Microsoft que no son Exchange Online. La automatización de flujos y el motor de correo propio de un CRM envían en tu nombre desde infraestructura que tu include de Exchange no cubre. Son remitentes aparte y necesitan su propia autorización o su propia firma DKIM, igual que un proveedor externo.
Relays y conectores. Un appliance, un formulario del sitio en hosting compartido o un servidor local que saca el correo por un conector agregan una dirección a la cadena. Si no está en SPF y el mensaje no va firmado con DKIM de tu dominio, falla.

Verifica con un mensaje real, no con un validador

Los validadores de DNS te dicen que el registro existe y que se puede leer. No te pueden decir qué concluyó un receptor sobre un mensaje de verdad, que es lo único que importa. Manda una prueba desde el tenant a una dirección de Gmail, abre Mostrar original y lee la cabecera Authentication-Results. Quieres tres cosas a la vez: spf=pass con un smtp.mailfrom de tu dominio, dkim=pass con el header.d= de tu dominio y no de onmicrosoft.com, y dmarc=pass. Dos de tres es donde está la mayoría de los tenants antes de este trabajo, y donde muchos se quedan sin darse cuenta.

Qué agregan las reglas para remitentes masivos

Pasado cierto volumen, los tres registros dejan de ser una buena práctica y se vuelven requisito de entrada. Las guías para remitentes de Google consideran remitente masivo a un dominio que manda cerca de 5,000 mensajes o más en un día a cuentas personales de Gmail, y esos remitentes necesitan SPF, DKIM y un registro DMARC de al menos p=none, mantener la tasa de spam reportado por usuarios por debajo del 0.3 por ciento, y ofrecer la baja en un clic descrita en el RFC 8058. Microsoft publicó un requisito comparable para remitentes de alto volumen hacia direcciones de Outlook.com, Hotmail.com y Live.com: SPF, DKIM y un registro DMARC válido, con el correo que no cumple mandado a Correo no deseado antes de una aplicación más dura. Cruza cualquiera de esos umbrales sin los registros y las fallas se vuelven ruidosas rápido, en forma de rechazos por autenticación y reputación y no de un viaje silencioso a la carpeta de spam.

Cómo ayuda Guanacos Tech

La mayoría de los tenants de Microsoft 365 que revisamos están a dos registros de pasar en todas partes, y los dos que faltan casi siempre son el DKIM del dominio propio y el DMARC. Inventariamos cada remitente desde tus reportes agregados, alineamos uno por uno, y llevamos la política de none a reject en un calendario que no pone en riesgo tus facturas. Si estás migrando hacia o desde Google Workspace, hacemos el mismo trabajo en los dos lados del cambio. Empieza con el diagnóstico de correo gratis o el analizador de DMARC, o agenda una llamada y leemos tus cabeceras contigo.

Configurar SPF, DKIM y DMARC en Microsoft 365: la guía para que Gmail acepte tu correo