Configurar Microsoft 365 (Exchange Online) con SPF, DKIM y DMARC alineados
Cómo configurar Microsoft 365 / Exchange Online: SPF correcto, DKIM con dos selectores, DMARC alineado y conectores para envíos relayed.
Microsoft 365 (Exchange Online) es uno de los proveedores más usados en entornos corporativos. Por defecto trae SPF razonable, pero DKIM no se firma con tu dominio hasta que lo activas explícitamente, y DMARC sin alineamiento te deja a medias. Esta guía cubre la configuración de los tres registros, la activación de DKIM con sus dos selectores, los conectores cuando combinas Exchange Online con MTAs externos, y los puntos donde el setup falla en organizaciones reales.
Lo que viene “por defecto” y lo que falta
Cuando das de alta un tenant en Microsoft 365 y verificas tu dominio, Exchange Online empieza a enviar correo con tu dominio. Sin tocar nada más:
- SPF: Microsoft espera que publiques
v=spf1 include:spf.protection.outlook.com -all(o~all). - DKIM: NO está activo. Los mensajes salen sin firma DKIM con tu dominio. El receptor verá
dkim=noneparaheader.d=tudominio.com. Microsoft puede firmar con su propio dominio (onmicrosoft.com) pero eso no aligna con tuFrom:. - DMARC: no se publica nada por ti. Si no lo haces tú, no hay política.
Sin DKIM con tu dominio y sin DMARC, los receptores tratan tus envíos con la reputación general de Microsoft, que es enorme pero no específica a tu dominio. Para señales propias y para BIMI o reputación independiente, hay que activar la pila.
SPF correcto para Microsoft 365
Si solo envías desde Exchange Online:
v=spf1 include:spf.protection.outlook.com -allSi combinas con otros remitentes (Mailchimp, SES, etc.), añade los include: en el orden lógico:
v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net include:amazonses.com -allCuidado con el límite de 10 lookups DNS de SPF. spf.protection.outlook.com cuenta como 1 lookup pero internamente hace varios; si combinas más de 3-4 servicios, tendrás que aplanar o segmentar por subdominios.
Más detalle en la guía de SPF.
DKIM en Exchange Online: los dos selectores
Microsoft 365 usa un esquema con dos selectores rotables: selector1 y selector2. La razón es operacional: Microsoft puede rotar la clave activa entre uno y otro sin tu intervención.
Para activarlo, hay que publicar dos CNAME en tu DNS:
selector1._domainkey.tudominio.com CNAME selector1-tudominio-com._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey.tudominio.com CNAME selector2-tudominio-com._domainkey.<tenant>.onmicrosoft.comLos hostnames exactos los obtienes desde el portal:
- Microsoft 365 Defender > Email & collaboration > Policies & rules > Threat policies > DKIM (la ruta cambia con frecuencia).
- Selecciona tu dominio.
- Si DKIM está deshabilitado, Microsoft te muestra los CNAME a publicar.
- Tras publicar, vuelve y pulsa “Enable”.
Si activas DKIM antes de publicar los CNAME, la activación falla con un error CNAME record does not exist. Publica primero, propaga, activa.
Verificación con dig
dig +short CNAME selector1._domainkey.tudominio.com
dig +short CNAME selector2._domainkey.tudominio.comDeben resolver a los hosts de <tenant>.onmicrosoft.com. La clave pública en sí está en el TXT al que apuntan los CNAME, pero tú no lo tocas.
Activación
Una vez los CNAME resuelven y has activado DKIM en el panel, los envíos saliendo de Exchange Online firman con header.d=tudominio.com y s=selector1 (o selector2 cuando rote).
DMARC
Publica el TXT en _dmarc.tudominio.com:
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r;Empieza siempre en p=none durante semanas, recoge reportes, identifica todos los flujos legítimos, y solo después sube a quarantine o reject siguiendo la lógica explicada en quarantine vs reject.
Conectores para envíos relayed
Si tienes aplicaciones internas que envían vía Exchange Online (relay con autenticación SMTP, conector de salida desde un CRM, scanner que manda PDF), debes:
- Configurar un conector de entrada que acepte el tráfico desde IPs específicas o con autenticación.
- Verificar que el dominio del
From:está aceptado en el tenant. - Si el
From:está fuera de tu dominio (relay para terceros), Exchange Online por defecto rechaza el envío.
Para envíos masivos que no sean transaccional puro, no uses Exchange Online: Microsoft aplica límites estrictos (2.000 destinatarios/día por buzón en estándar, distinto en E5/Enterprise) y la reputación se asocia con el tenant entero. Para campañas, ESPs específicos.
Cuándo Microsoft 365 firma con onmicrosoft.com
Si DKIM no está activado para tu dominio, Microsoft puede firmar con <tenant>.onmicrosoft.com. Esto produce dkim=pass header.d=<tenant>.onmicrosoft.com. Es válido técnicamente pero no aligna con header.from=tudominio.com para DMARC.
Resultado: con DMARC estricto, los envíos pueden quedar como dmarc=fail aunque pasen DKIM y SPF, porque el dominio firmado y el From: no coinciden.
La solución es siempre activar DKIM con tu dominio.
Ajustes adicionales
Envíos de calendario y compartidos
Cuando un usuario envía como otro (delegación, mailbox compartido), Exchange a veces firma con el dominio del propietario, no con el del que envía. Verifica casos concretos en cabeceras antes de subir DMARC.
MTA-STS y TLS-RPT
Microsoft 365 soporta MTA-STS tanto entrante como saliente. Publicar tu propio MTA-STS para tu dominio es independiente de Exchange Online; lo gestionas en tu DNS y en un endpoint HTTPS.
BIMI
Una vez DMARC esté en quarantine o reject, puedes publicar BIMI. Microsoft Outlook aplica BIMI gradualmente; verifica en tu propio entorno.
Diagnóstico
Cabeceras de un envío
Manda un correo desde una cuenta de Exchange Online a Gmail:
Authentication-Results:
spf=pass smtp.mailfrom=tudominio.com
dkim=pass header.d=tudominio.com header.s=selector1
dmarc=pass (p=...) header.from=tudominio.comSi dkim no es pass header.d=tudominio.com, la activación de DKIM no está aplicada al envío.
Microsoft 365 Defender
El centro de Defender muestra estado de SPF, DKIM y DMARC por dominio. Útil pero a veces tarda en reflejar cambios; confirma siempre con dig y con una cabecera real.
Reportes DMARC
Tras unos días, los reportes RUA muestran:
- Servidores que envían con tu dominio.
- Tasas de éxito de SPF y DKIM por origen.
- Flujos no esperados que tienes que investigar.
Errores frecuentes
Activar DKIM antes de propagar CNAME
Microsoft falla con un error específico. Publica los CNAME, espera 15-30 minutos, comprueba con dig, y entonces activa.
Dejar DKIM desactivado y subir DMARC a reject
Receta para perder envíos legítimos. DMARC estricto sin DKIM alineado bloquea cualquier mensaje que solo pase SPF si la organización del Return-Path no aligna con From.
SPF con +all o muy laxo
Algunas organizaciones heredan SPF antiguos con ?all o +all. Eso anula el sentido de SPF. Pasa a ~all (softfail) durante diagnóstico y a -all cuando confirmes que todos los remitentes están listados.
Conectores mal configurados que abren relay abierto
Si configuras un conector de entrada para una IP de aplicación, restringe a IP exacta y, si es posible, exige TLS y autenticación. Un conector laxo se convierte en relay abierto.
Olvidar dominios secundarios
En tenants con múltiples dominios verificados, cada uno necesita su propia activación de DKIM. Si solo activas el principal, los envíos desde otros dominios siguen sin firma.
Usar Exchange Online para newsletter
Microsoft aplica límites por buzón y trata el tenant como una unidad de reputación. Una campaña a 50.000 destinatarios desde un buzón normal te enviará al “throttled” rápido. Para newsletters, ESP dedicado.
Recursos relacionados
Si quieres profundizar, prueba estas herramientas gratuitas: Domain Health, mail tester, validador SPF y validador DMARC.
¿Necesitas que alguien lleve tu canal de email entero? Abalola Mail es la agencia de retención y email marketing de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.