Microsoft 365 / DNS del correo: comprobar MX, SPF, DKIM y DMARC

Para el correo de Microsoft 365, los registros DNS (Sistema de Nombres de Dominio) dirigen el correo entrante y respaldan la autenticación del correo saliente. Un registro de intercambiador de correo (MX) identifica el servidor receptor; Marco de Políticas de Remitentes (SPF), Correo Identificado por Claves de Dominio (DKIM), y Autenticación, Informes y Conformidad de Mensajes Basados en Dominio (DMARC) proporcionan diferentes verificaciones de autenticación e información de políticas. Verifique la propiedad del dominio e inventarie los servicios de envío de Microsoft 365 y externos antes de cambiar estos registros.

Roles de los cuatro registros

La guía de implementación de autenticación de correo de Microsoft recomienda SPF, DKIM y DMARC para los dominios personalizados. DMARC no pasa solo porque SPF o DKIM tengan éxito: también debe cumplirse la alineación con el dominio remitente mostrado.

SPF declara qué fuentes de envío están autorizadas. Con DKIM, el remitente usa una clave privada para firmar partes del mensaje, y el destinatario usa una clave pública publicada a través de DNS para verificar la firma. DMARC verifica la alineación con el dominio visible en el campo From (De) y publica la política de fallo solicitada y el destino de los informes. Estas capacidades de autenticación están incluidas en la protección integrada para buzones de correo en la nube; otras funciones de Defender pueden tener requisitos adicionales de licencia.

SPF verifica el dominio utilizado en MAIL FROM, la dirección del remitente del sobre utilizada entre servidores de correo. Esto puede diferir de la dirección From que se muestra al lector. Un dominio que firma DKIM también puede pertenecer al proveedor del servicio. Por lo tanto, un servicio de gestión de relaciones con clientes (CRM) podría pasar SPF y DKIM con el dominio de su proveedor, pero aún así fallar DMARC para el dominio de la empresa que se muestra en From. El requisito clave es que al menos un resultado alineado de SPF o DKIM pase.

La alineación puede ser relajada (el mismo dominio organizacional, permitiendo subdominios) o estricta (una coincidencia exacta del nombre de dominio). Las etiquetas opcionales aspf y adkim controlan la alineación de SPF y DKIM por separado; ambas usan de forma predeterminada la alineación relajada (r). Verifique estos modos cuando un servicio de envío utilice un subdominio.

Investigue la ruta de envío antes de la configuración

• Correos electrónicos enviados por empleados desde Exchange Online
• Correos electrónicos enviados por sistemas externos como formularios de consulta en sitios web, CRM, servicios de marketing y dispositivos multifuncionales
• Servicios de envío que usan subdominios por separado
• La ruta a través de un gateway de seguridad de correo o servidor de retransmisión

Si se omite la fuente de envío, los correos electrónicos legítimos pueden ser rechazados después de fortalecer SPF, DKIM y DMARC. Elimine las fuentes de envío que no se usan y autentique los servicios requeridos según la guía oficial del proveedor respectivo.

Orden de verificación en Microsoft 365

1. En el centro de administración de Microsoft 365, abra el dominio objetivo en [Configuración] → [Dominios] y verifique el estado de la configuración de DNS. Utilice los valores MX que se muestran en el asistente de dominio para ese dominio.

2. Verifique los registros TXT SPF actuales con su proveedor de hospedaje de DNS. Si es necesario incluir fuentes de envío fuera de Microsoft 365, intégrelas en los valores existentes.
3. En la configuración de autenticación de correo del portal de Microsoft Defender, verifique el estado de DKIM del dominio personalizado y los registros DNS requeridos. Después de agregar los valores sugeridos al DNS, verifique que la firma esté activada.

4. Introduzca DMARC gradualmente. Analice los remitentes reales y los fallos de autenticación a través de informes, luego decida sobre el fortalecimiento de la política. Si solo agrega la declaración de política sin leer los informes, es difícil detectar problemas.
5. Envíe un correo electrónico de prueba a una dirección externa fuera de la organización y verifique los resultados de SPF, DKIM y DMARC y su alineación en los encabezados recibidos. Incluso si el estado del DNS es normal, debe probar la ruta de envío real.

Condiciones bajo las cuales se puede usar el ejemplo de SPF tal cual

Para un dominio personalizado cuyo DNS público usted administra, el siguiente valor TXT es un ejemplo básico cuando Microsoft 365 es el único servicio de envío. Este ejemplo se aplica al servicio comercial mundial de Microsoft; las nubes especiales para gobierno o operadas en China pueden requerir dominios distintos para incluir. Use los valores específicos del servicio en su centro de administración y documentación. Si un sitio web o servicio de marketing también envía directamente usando el mismo dominio, no reemplace su política actual solo con este ejemplo. Compare el asistente de dominios y la guía de configuración oficial de cada remitente.

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

include hace referencia a los servidores de envío de Microsoft 365 y -all declara un fallo de SPF para las fuentes que no estén autorizadas. No cree dos registros TXT de SPF con el mismo nombre para separar Microsoft 365 de los servicios externos. Reúna las fuentes necesarias en una sola política y elimine las que ya no se usan. Los registros TXT de verificación de propiedad tienen otra finalidad y no deben eliminarse por este motivo. Consulte los escenarios de la guía oficial de configuración de SPF.

Al combinar servicios, también verifique el límite de SPF de 10 consultas DNS durante la evaluación. Los mecanismos anidados de inclusión también cuentan: tener menos de 10 proveedores o entradas include no garantiza que la evaluación se mantenga dentro del límite.

Valores para seleccionar al configurar DKIM y DMARC

En el portal de Defender, abra el dominio personalizado en Correo y colaboración → Políticas y reglas → Políticas de amenazas → Configuración de autenticación de correo → DKIM. Genere las claves si es necesario, luego ingrese los nombres y destinos de los dos registros CNAME (nombre canónico) que se muestran en los detalles del dominio en su proveedor de DNS. Un registro CNAME apunta un nombre de DNS a otro; en esta configuración conecta la búsqueda de DKIM con los registros de clave de Microsoft. Copie los nombres de selector y destinos suministrados para su inquilino en lugar de construirlos a partir de un blog antiguo. Microsoft introdujo un nuevo formato de destino para nuevos dominios personalizados en mayo de 2025, mientras que los dominios existentes pueden conservar el formato antiguo.

Después de que se propaguen los cambios de DNS, active la firma DKIM del dominio y compruebe que está firmando. Si falta un CNAME, revise el nombre introducido, el proveedor DNS que realmente administra la zona y el momento de detección. Guardar los dos registros no significa que la firma ya esté activa. Siga la configuración oficial de DKIM según el estado actual del dominio.

La política inicial de DMARC se puede establecer como una configuración enfocada en informes que pueda analizar remitentes legítimos. A continuación se muestra un ejemplo usando example.com como dominio de muestra. Publique el registro TXT en _dmarc para su propio dominio, y reemplace dmarc@example.com en el valor de rua=mailto: con un buzón de informes real controlado por su organización. La dirección de ejemplo no es un destino para usar sin cambios.

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

p=none es una política inicial que no solicita cuarentena ni rechazo por fallos de DMARC en sí mismos, y no desactiva otros filtros de spam o de seguridad. rua indica el destino de los informes agregados. Debe estar preparado para recibirlos y analizarlos en esa dirección, y si usa una dirección de servicio de informes externo, también debe verificar condiciones adicionales de aprobación de DNS. Después de verificar la alineación de los remitentes legítimos y la ruta de entrega, refuerce la política a los pasos quarantine y reject. Las condiciones detalladas siguen las directrices de implementación de DMARC.

Verifique los registros DNS y la autenticación en el correo recién enviado

Envíe nuevos correos electrónicos a una dirección de prueba para cada ruta de envío, como correo de empleados, formularios de consulta web, CRM, etc. En el lado receptor, abra el mensaje original y los encabezados de Internet para verificar los resultados de SPF, DKIM y DMARC en el Authentication-Results del sistema receptor, y también compare el dominio de firma DKIM con el From mostrado. Necesita los resultados de los mensajes recién enviados después de los cambios en lugar de "los correos antiguos eran normales."

Si el DNS es normal pero falla un CRM específico, primero verifique el dominio de envío y la configuración de firma para esa ruta. Si el cuerpo firmado cambia o el servidor de envío es diferente durante el proceso de entrega, los resultados pueden variar. Que la autenticación pase no garantiza la entrega en la bandeja de entrada, y la reputación, el spam y las políticas de contenido también tienen un impacto.

Los valores de los registros varían según el dominio y el momento de la configuración. El propósito de este artículo no es memorizar los valores, sino comparar los valores proporcionados por el centro de gestión , los valores reales en DNS y los resultados de autenticación en el lado receptor. Si hay problemas con la recepción o el envío de correos electrónicos, identifique el alcance del impacto basado en los registros DNS antes de los cambios. Si se ven afectados correos electrónicos legítimos, compare la política anterior y la configuración del remitente para restaurar solo los cambios problemáticos y pruebe nuevamente. No elimine todos los registros SPF, DKIM y DMARC ni mantenga una política estricta de DMARC sin conocer la causa. En el informe, distinga entre fallos de remitentes legítimos y envíos sospechosos falsificados, y determine las acciones de seguimiento en consecuencia.