Configurar correctamente SPF, DKIM y DMARC en Microsoft 365 y verificarlos con herramientas de diagnóstico

En esta entrada describimos de forma práctica cómo configurar correctamente, comprobar y supervisar en producción SPF, DKIM y DMARC para Microsoft 365. Está dirigida a la dirección de TI, administradores y proveedores de servicios técnicos que buscan conseguir flujos de correo seguros, sin interrupciones y con un mínimo de falsos positivos. Incluye inventario de remitentes, configuración de DNS, pruebas con herramientas de diagnóstico locales, errores típicos, estrategias de contingencia y ciclos operativos de verificación.

Kurzüberblick: Warum SPF, DKIM und DMARC zusammengehören

SPF (Sender Policy Framework) es un registro TXT en DNS que indica qué servidores están autorizados a enviar correos electrónicos en nombre de su dominio. DKIM (DomainKeys Identified Mail) añade una firma criptográfica a los mensajes salientes; la firma se puede verificar con una clave pública publicada en DNS. DMARC (Domain‑based Message Authentication, Reporting & Conformance) es una capa de política que consolida los resultados de SPF y DKIM, comprueba la alineación (Alignment) y define cómo deben tratarlo los sistemas receptores los mensajes no autenticados, así como a qué direcciones se envían los informes (rua/ruf).

Voraussetzungen und Inventarisierung

Antes de realizar cambios en DNS o en Exchange Online, compruebe:

• ¿Qué sistemas envían correos para su dominio? (Exchange Online, Exchange local, dispositivos multifunción, plataformas de marketing, CRM, servicios de envío de terceros)
• ¿Quién gestiona el DNS? (equipo interno de DNS, proveedor externo, CDN/proveedor de DNS). El acceso al DNS es imprescindible.
• ¿Hay subdominios implicados? Algunos servicios envían desde sub.domain.tld y requieren entradas propias.
• ¿Tiene acceso al Microsoft 365 Admin Center y a Exchange Online PowerShell?

Un inventario limpio reduce fallos posteriores: registre cada IP de envío, cada servicio y la persona de contacto responsable en una tabla; documente además si un servicio firma (DKIM) o si sólo está autorizado mediante SPF.

SPF für Microsoft 365: Praktische Umsetzung

Recomendación estándar para Microsoft 365 (Exchange Online): el dominio debe incluir Outlook/Exchange Online como remitente autorizado. El SPF mínimo típico es:

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

Explicación: include:spf.protection.outlook.com permite los servidores de salida de Microsoft. El -all es una política estricta (Fail). Durante la fase de pruebas se recomienda ~all (SoftFail), para que los servicios legítimos aún no inventariados no sean rechazados de inmediato.

SPF mit Drittanbietern und das 10‑Lookup‑Limit

SPF tiene una limitación técnica: máximo 10 búsquedas DNS (includes, a, mx, ptr, exists). Si tiene muchos proveedores externos (por ejemplo herramientas de marketing, servicios de envío, correos de autenticación), las búsquedas se acumulan. Soluciones:

• Agrupe servicios en IPs de envío propias o utilice subdominios dedicados para marketing, para mantener entradas SPF separadas.
• Use SPF‑Flattening con cautela: algunos proveedores sustituyen los includes por listas de IPs (reduce búsquedas, pero puede dar lugar a registros TXT más grandes).
• Compruebe si el proveedor externo ofrece IPs dedicadas o un relay que pueda incluir directamente en el SPF.

Beispiel: SPF mit mehreren Sendern

v=spf1 include:spf.protection.outlook.com include:spf.sendermarketing.example include:_spf.thirdparty.com ~all

Consejo: Pruebe los cambios primero con ~all, observe los informes agregados de DMARC (rua) y tras un periodo de funcionamiento estable cambie a -all. Herramientas de seguimiento y registros (logs) ayudan a identificar remitentes ocultos.

DKIM en Microsoft 365: conceptos y configuración

DKIM funciona con pares de claves: una clave privada firma el mensaje saliente, una clave pública (como TXT DNS bajo el nombre del selector) permite verificar la firma. Un selector es un prefijo que posibilita claves distintas para la rotación y para subdominios (p. ej. selector1._domainkey.example.com).

Microsoft 365: ¿automático o manual?

Microsoft 365 puede gestionar DKIM para su dominio personalizado. En el portal Microsoft 365 Defender / Security & Compliance encontrará dos registros CNAME que debe crear en el DNS. Estos CNAME delegan las claves DKIM a Microsoft; Microsoft firma los correos automáticamente. Los valores CNAME de destino aparecen en el Centro de administración bajo «DKIM» para el dominio correspondiente — copie los valores sugeridos 1:1 en el DNS.

Procedimiento recomendado

1. Recopilar: Localice en el Centro de administración los destinos CNAME requeridos para su dominio.
2. DNS: Cree los dos registros CNAME (para selector1 y selector2).
3. Activar: Habilite DKIM para el dominio en el portal Defender/Microsoft 365.
4. Probar: Envíe correos de prueba y verifique en los encabezados la presencia de una firma DKIM válida.

Si prefiere claves autogestionadas

Algunas organizaciones prefieren usar claves privadas propias en sus gateways de correo. Es posible, pero requiere publicar la clave pública como TXT bajo el selector y configurar correctamente la firma en el gateway. Valore el esfuerzo, la rotación de claves y la gestión de claves (p. ej. KMS/HSM) y documente el proceso de forma estricta.

Política DMARC: estructura, informes y estrategia de migración

DMARC regula la respuesta y el reporte. Una entrada DMARC típica como TXT es:

v=DMARC1; p=quarantine; rua=mailto:dmarc-aggregate@yourdomain.example; ruf=mailto:dmarc-forensic@yourdomain.example; pct=100; adkim=r; aspf=r

Breve explicación: p es la política (none/quarantine/reject). rua son los informes agregados (XML), enviados periódicamente; ruf son los informes forenses (sensibles y con frecuencia relevantes para la protección de datos). adkim y aspf controlan el alignment de DKIM y SPF: r = relaxed (permite coincidencias parciales), s = strict (dominio exacto). Normalmente empiece con p=none para recopilar datos, luego p=quarantine y finalmente p=reject.

Extracción y análisis de informes

Los informes agregados son archivos XML. Para análisis rápidos en un Linux/Bash puede usar xmlstarlet para extraer IPs y volúmenes. Ejemplo: extraer todas las IP de origen de un agregado DMARC:

xmlstarlet sel -t -m '//record' -v 'row/source_ip' -n dmarc_report.xml | sort | uniq -c | sort -nr

Esto produce una lista de IPs de origen con su frecuencia. Para entornos productivos se recomienda una plataforma especializada de análisis DMARC o un parser propio con almacenamiento en un SIEM/DB para análisis de tendencias.

Herramientas de diagnóstico y secuencia de comprobación

Verifique con herramientas locales disponibles y servicios en la nube. Escenario de prueba recomendado:

1. Comprobaciones DNS para SPF/DKIM/DMARC
2. Envíe correos de prueba y analice los encabezados del correo
3. Utilice Message Trace en Exchange Online
4. Analice los informes agregados de DMARC

Comprobaciones DNS (PowerShell / Bash)

Windows PowerShell con Resolve‑DnsName:

Resolve-DnsName -Name "example.com" -Type TXT
Resolve-DnsName -Name "selector1._domainkey.example.com" -Type TXT
Resolve-DnsName -Name "_dmarc.example.com" -Type TXT

Bash con dig:

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Análisis de cabeceras

Abra un correo de prueba recibido y busque Authentication-Results. Ejemplo:

Authentication-Results: mx.protection.outlook.com; spf=pass (sender IP is x.x.x.x) smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass (p=none) header.from=example.com

Un procedimiento práctico: siga cronológicamente desde abajo (Envelope‑From / smtp.mailfrom) hacia arriba (Header‑From) y verifique si DKIM o SPF muestran un ‚pass‘ con alineación.

Message Trace en Exchange Online

Message Trace ayuda a verificar flujos de correo y resultados de autenticación. Ejemplo de búsqueda (Exchange Online PowerShell):

Connect-ExchangeOnline -UserPrincipalName admin@yourtenant.onmicrosoft.com
Get-MessageTrace -StartDate 2026-07-01 -EndDate 2026-07-02 -SenderAddress sender@example.com | Select Received,SenderAddress,RecipientAddress,Subject,MessageTraceId

Message Trace proporciona el estado de entrega y permite, con Get-MessageTraceDetail, análisis más profundos. Utilice Trace combinado con análisis de cabeceras e informes DMARC.

SPF, DKIM y DMARC para Microsoft 365: conocimientos operativos y runbook

Para la operación continua es importante automatizar las comprobaciones, definir responsabilidades y establecer vías claras de escalado. A continuación encontrará complementos prácticos que puede incorporar de inmediato en su runbook.

Comprobación automatizada de integridad DNS

Un simple cron job puede verificar la existencia y la integridad básica de los registros DNS más importantes. Ejemplo: cuente las apariciones de include: en el SPF para supervisar el riesgo de lookups:

#!/bin/bash
SPF=$(dig +short TXT example.com | tr -d '"')
echo "$SPF"
INCLUDES=$(echo "$SPF" | grep -o 'include:' | wc -l)
if [ "$INCLUDES" -gt 8 ]; then
  echo "Warnung: SPF includes = $INCLUDES" | mail -s "SPF Lookup Alert" ops-team@example.com
fi

Esto es una alerta temprana; debería comprobar regularmente en el monitoring que no se supere el límite de 10 lookups.

Comprobar el estado de DKIM con PowerShell

Compruebe si Microsoft 365 ha activado DKIM para su dominio:

Connect-ExchangeOnline -UserPrincipalName admin@yourtenant.onmicrosoft.com
Get-DkimSigningConfig -Identity example.com | Format-List

Este cmdlet muestra si DKIM está activado y qué selectores se usan. Incorpórelo en sus comprobaciones nocturnas.

Estrategias de rollback y medidas de emergencia

Cualquier cambio en SPF/DKIM/DMARC requiere un plan de reversión probado. Buenas prácticas:

• Antes de los cambios: exporte los registros DNS actuales y guárdelos versionados en su repositorio de configuración.
• Si tras un cambio se produce una pérdida masiva de entrega: ponga DMARC inmediatamente en p=none, restaure SPF a la versión anterior y desactive, si es posible, los selectores DKIM recién activados.
• Comunicación: Informar a las áreas afectadas (Marketing, Soporte) y acordar una comunicación de la ventana de mantenimiento con SLA para la operación del servicio de correo.

Runbook práctico: Escalada DMARC (resumen)

1. Comprobar la alerta del analizador DMARC: volumen, IPs afectadas, ventana temporal.
2. Revisar el Message Trace para los periodos y remitentes afectados.
3. Si remitentes legítimos están afectados: restablecer inmediatamente DMARC a p=none y ajustar temporalmente los registros SPF/DKIM.
4. Tras la estabilización: retorno gradual a la aplicación de la política con monitorización.

Problemas típicos y cómo evitarlos

• Inventario incompleto: sistemas de envío no documentados provocan falsos positivos. Mantenga la lista de inventario actualizada.
• Subestimar la propagación DNS: los cambios requieren tiempo; planifique ventanas de mantenimiento.
• Descuidar la gestión de claves: sin rotación aumentan los riesgos de seguridad. Defina un ciclo de rotación (p. ej., anual o semestral).
• Informes forenses (ruf) sensibles desde el punto de vista de la protección de datos: revise la retención y el control de accesos.

Cumplimiento y protección de datos en los informes DMARC

Los informes agregados DMARC no contienen correos completos, pero los informes forenses pueden incluir información sensible. Asegure que el buzón para rua/ruf esté restringido, registrado y limpiado regularmente. Documente los plazos de retención y quién tiene acceso.

Conclusión

Una operación de correo segura con Microsoft 365 requiere trabajo coordinado sobre DNS, la configuración en Microsoft 365 y monitorización. Comience con un inventario completo, configure SPF de forma conservadora con ~all, delegue DKIM en Microsoft 365 mediante los valores CNAME indicados en el portal y recopile los informes DMARC bajo p=none. Solo cuando los informes y el Message Trace muestren resultados limpios, incremente la aplicación de la política de forma gradual. Planifique monitorización, rotación de claves y rutas de recuperación claras: eso reduce riesgos de indisponibilidad y protege su dominio frente a abusos.

Enlaces complementarios y documentación interna

Documentos internos que debería crear como complemento: operación de cambios DNS, runbook para fallos de correo, lista de inventario de todos los proveedores y un panel de informes DMARC. Estos artefactos permiten reacciones rápidas y un funcionamiento sostenible.

Indicaciones operativas de arquitectura e integración

Para un funcionamiento estable se recomienda un ajuste arquitectónico que separe lógicamente los flujos de envío: use subdominios dedicados (p. ej. mails.example.com para transacciones, news.example.com para marketing). Así puede gestionar por separado distintos niveles de aplicación de DMARC, conjuntos SPF y selectores DKIM sin poner en riesgo el dominio principal.

Integración de servicios externos y patrones de relay

• Si los proveedores externos no entregan una firma DKIM uniforme, reenvíe sus correos a través de un relay controlado (p. ej. un SMTP‑Gateway corporativo). Allí puede firmar de forma homogénea y evitar reescrituras de cabeceras.
• APIs en lugar de SMTP: muchos servicios de envío modernos ofrecen APIs HTTP con firma integrada o mecanismos de autenticación. Esto reduce la carga de SPF‑lookup y simplifica la gestión de IPs.

Operación, rotación y seguridad

• Rotación de claves: planifique la rotación DKIM con al menos dos selectores (active/next). Pruebe el cambio en un subdominio de staging antes de rotar en producción.
• Almacenamiento de claves: utilice KMS/HSM para las claves privadas DKIM; documente el acceso y los procedimientos de recuperación.

Monitorización, automatización y procedimiento de emergencia

Integre el parsing de agregados DMARC en su SIEM o en una pequeña canalización: reglas de etiquetado automatizadas (p. ej. nueva Sending‑IP con alto volumen) generan alertas. Antes de cambios DNS importantes reduzca los TTL, realice Canary‑Updates en un subdominio de prueba y mantenga una copia de seguridad versionada del DNS. En caso de emergencia: poner DMARC inmediatamente a p=none, revertir SPF a la versión TXT anterior y reactivar las entradas CNAME afectadas. Documente este procedimiento como un paso vinculante del runbook con los datos de contacto de los Service‑Owner y SLAs claros — eso reduce los tiempos de recuperación en casos críticos.

Para este tema también son importantes la autenticación de correo electrónico y el registro SPF. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que centrarse en la operativa diaria.