Cómo configurar DMARC correctamente en Office 365

Desde febrero de 2024, los requisitos de envío masivo de Gmail exigen un registro DMARC publicado para cada dominio que envíe a través de correos electrónicos 5,000 por día a los usuarios de Gmail. Yahoo aplica la misma regla bajo su mejores prácticas del remitente. A partir de 2025 de mayoMicrosoft ha comenzado a rechazar los correos electrónicos que no cumplen con las normas, provenientes de remitentes con un alto volumen de envíos, a las cuentas de Outlook, Hotmail y Live.

DMARC ha pasado de ser opcional a obligatorio para cualquier inquilino de Microsoft 365 que opere a gran escala, y actualmente estadísticas de spam de correo electrónico Explique claramente el motivo: los proveedores están endureciendo las normas de autenticación porque el correo no autenticado supone un riesgo tanto para los remitentes como para los destinatarios.

Por eso es importante aprender a configurar correctamente DMARC en Office 365, desde confirmar los requisitos previos y crear el registro hasta publicarlo en el DNS, elegir una política inicial segura, verificar que funcione y avanzar hacia su aplicación completa sin bloquear el correo legítimo.

Requisitos previos para configurar DMARC en Office 365

DMARC no es un protocolo independiente. Es una capa de políticas sobre FPS y DKIM Esto indica a los servidores de correo receptores qué hacer cuando fallan esas comprobaciones. Si SPF o DKIM están mal configurados o no están alineados, la aplicación de DMARC comenzará a actuar en función de esa desalineación en el momento en que se pase de p=none.

Confirme los cuatro requisitos previos que se indican a continuación antes de publicar su registro DMARC:

• Registro SPF publicado y aprobado: Para los inquilinos de Microsoft 365, el registro SPF debe incluir include:spf.protection.outlook.com, además de cualquier remitente externo adicional (SendGrid, Mailchimp, HubSpot, etc.) que envíe correos en nombre de su dominio.
• Firma DKIM habilitada para cada dominio personalizado: Microsoft 365 no habilita DKIM automáticamente para dominios personalizados. Abra el portal de Microsoft Defender, vaya a la página de DKIM en Correo electrónico y colaboración → Directivas y reglas → Directivas de amenazas y confirme que la firma esté activada para el dominio personalizado.
• Acceso de administrador global o administrador de seguridad al inquilino de Microsoft 365 para cualquier paso de verificación dentro del portal de Defender.
• Acceso DNS para el dominio personalizado para publicar el registro DMARC TXT en _dmarc.yourdomain.com en el panel de control de su proveedor de DNS.

Cómo configurar DMARC en Office 365: Paso a paso

Los cinco pasos que se describen a continuación requieren entre 10 y 15 minutos de trabajo activo, más el tiempo de propagación del DNS (que puede variar desde unos pocos minutos hasta 48 horas, dependiendo de su proveedor de DNS y la configuración del TTL).

La configuración de DMARC se realiza completamente en el DNS, no en el portal de Microsoft Defender. Microsoft 365 gestiona automáticamente las comprobaciones de DMARC entrantes mediante Exchange Online Protection, pero no existe ninguna opción en el portal de Defender para configurar el DMARC saliente en su dominio personalizado. Ese registro reside en su zona DNS.

Paso 1: Confirmar que SPF y DKIM funcionan correctamente.

Envía un correo electrónico de prueba desde tu dominio personalizado a una dirección externa de Gmail o Yahoo. Abre el correo electrónico y consulta los encabezados completos del mensaje (en Gmail: menú de tres puntos → “Mostrar original”).

En el encabezado Authentication-Results, confirme:

• spf=pass — SPF está autorizado y se está pasando
• dkim=pass — DKIM está firmando correctamente y la firma está verificada.

Si alguno de los resultados muestra fallo o neutralidad, deténgase aquí y solucione primero el problema de autenticación. Publicar un registro DMARC sobre un SPF o DKIM defectuoso provocará que los correos electrónicos legítimos se pongan en cuarentena o se rechacen en cuanto cambie la política a p=none.

Paso 2: Decidir la política inicial de DMARC.

Para cada nueva implementación de DMARC, comience con p=none. Esta política recopila informes agregados de DMARC sin afectar la entrega de correo electrónico. Los mensajes que fallan se entregan igualmente, pero los servidores de correo receptores informan los resultados de la autenticación a la dirección especificada en la etiqueta rua=. Estos datos le indican qué fuentes de envío están alineadas y cuáles no antes de que comience la aplicación de la política.

El uso directo de p=quarantine o p=reject es la causa más común de pérdida de correos electrónicos legítimos durante la implementación de DMARC. Si una plataforma de envío de terceros aún no está alineada, una política estricta pondrá en cuarentena o rechazará inmediatamente los correos legítimos provenientes de esa fuente. La etapa p=none existe precisamente para evitar esto.

Paso 3: Crear el registro DMARC

El registro DMARC básico para una nueva implementación tiene este aspecto:

v = DMARC1; p = ninguno; rua = mailto:sales@costex.com; pct=100;

Esto es lo que significa cada etiqueta:

• v=DMARC1 — la versión del protocolo. Obligatorio como primera etiqueta en cada registro DMARC.
• p = ninguno — La política aplicada a los mensajes que no cumplen con la alineación DMARC. Se empieza sin ninguna, y luego se avanza a cuarentena y rechazo a medida que la alineación se estabiliza.
• rua=mailto:address — el buzón donde se envían los informes agregados. Utilice un buzón dedicado como sales@costex.como bien, puede enviar los informes a un analizador DMARC de terceros si prefiere una vista de panel.
• pct=100 — el porcentaje de mensajes fallidos a los que se aplica la política. Establézcalo en 100 desde el principio. Los despliegues graduales de porcentajes rara vez son necesarios en las implementaciones modernas de DMARC y añaden complejidad innecesaria.

Para obtener la referencia completa de etiquetas, incluidas las etiquetas opcionales como ruf (informes forenses), sp (política de subdominio), adkim y aspf, consulte DMARC.orgdocumentación oficial del protocolo.

Paso 4: Publicar el registro DMARC en DNS

Inicie sesión en el proveedor DNS de su dominio. Cree un nuevo registro TXT con los siguientes valores:

• Host / Nombre: _dmarc (algunos proveedores solicitan _dmarc.yourdomain.com; introduzca exactamente lo que requiere la interfaz de usuario de DNS).
• Valor / Contenido: El registro DMARC completo creado en el Paso 3, exactamente como está escrito.
• TTL: 3600 (una hora) es el estándar; los valores más bajos se propagan más rápido durante las pruebas.

Guarda el registro. La propagación de DNS suele completarse en unas pocas horas, pero puede tardar hasta 48 horas. Durante ese tiempo, es posible que el registro no sea visible de forma consistente para todos los servidores DNS.

Paso 5: Verifique que el registro DMARC esté activo.

Una vez que el registro se haya propagado, verifíquelo de dos maneras:

• Búsqueda de DNS: Acceda a la herramienta de búsqueda DMARC de MXToolbox, introduzca su dominio y confirme que el registro se muestra correctamente analizado y válido. Si la búsqueda falla o devuelve un error, revise el formato de su registro DNS, ya que la falta de un punto y coma o un nombre de host incorrecto suelen ser la causa.
• Verificación del encabezado de autenticación: Envía otro correo electrónico de prueba desde tu dominio personalizado a Gmail, Yahoo o una dirección externa de Outlook. Abre los encabezados completos y confirma que la sección Authentication-Results ahora muestra dmarc=pass para el dominio remitente.

Los informes agregados de DMARC comienzan a llegar al buzón rua= entre 24 y 72 horas después de que el registro se publique. Revise cuidadosamente el primer lote antes de considerar la posibilidad de adoptar una política más estricta.

Comprensión de las opciones de política de DMARC: Ninguna, Cuarentena y Rechazar

Cada implementación exitosa de DMARC pasa por las tres etapas de la política a lo largo de semanas o meses. Omitir etapas conlleva el riesgo de rechazar correo legítimo antes de que todas las fuentes de envío estén correctamente alineadas. El enfoque por etapas es la forma de proteger el flujo de correo mientras se avanza hacia la aplicación completa de la política.

Modo de monitorización: p=ninguno

v = DMARC1; p = ninguno; rua = mailto:sales@costex.com; pct=100;

Con p=none, los servidores de correo receptores recopilan los resultados de DMARC y los envían de vuelta a tu dirección rua=, pero los mensajes que fallan se siguen entregando con normalidad. Nada se pone en cuarentena ni se rechaza.

Manténgase en p=none durante un mínimo de 2 a 4 semanas. Aproveche ese tiempo para revisar los informes agregados y confirmar que todas las fuentes de envío legítimas, como Microsoft 365, plataformas de marketing, remitentes transaccionales y CRM, cumplen con la alineación DMARC. Cualquier fuente que presente fallos debe corregirse antes de que la política se endurezca.

Pase a p=cuarentena solo cuando los informes muestren consistentemente tasas de aprobación superiores al 95 % para todos los remitentes legítimos durante varios ciclos de informes.

Aplicación suave de la ley: p=cuarentena

v=DMARC1; p=cuarentena; rua=mailto:sales@costex.com; pct=100;

Con p=quarantine, los servidores de correo receptores envían los mensajes con errores a la carpeta de spam o correo basura en lugar de a la bandeja de entrada. El correo legítimo, aunque no esté alineado, sigue llegando, solo que en una ubicación menos visible para los destinatarios.

Esta etapa de la política es un punto de control intermedio útil. Impone consecuencias para los correos mal alineados sin los rebotes permanentes que genera p=reject. Permanezca aquí durante 2 a 4 semanas más y supervise atentamente los informes para detectar cualquier correo legítimo que se esté redirigiendo incorrectamente.

Cambie a p=reject solo cuando los informes DMARC confirmen una alineación consistente en todas las fuentes y no se esté poniendo en cuarentena ningún correo legítimo.

Aplicación total: p=rechazar

v=DMARC1; p=rechazar; rua=mailto:sales@costex.com; pct=100;

Con p=reject, los servidores de correo receptores rechazan directamente los mensajes que no cumplen con la alineación DMARC. Los mensajes que fallan rebotan al remitente; no llegan al destinatario.

Este es el objetivo de cada implementación de DMARC. La aplicación completa de p=reject proporciona una protección total contra la suplantación de dominio y satisface los requisitos de Gmail, Yahoo y Microsoft para remitentes de alto volumen. También protege su reputación de dominio e IP impidiendo que remitentes no autorizados utilicen su nombre de dominio para enviar correo.

Continúe supervisando los informes DMARC en p=reject. Las nuevas fuentes de envío, incluidos los nuevos proveedores, las herramientas de marketing y las integraciones, aún pueden provocar fallos de alineación y deben incorporarse con la autenticación correspondiente antes de su puesta en marcha.

Errores comunes de configuración de DMARC en Office 365 y cómo solucionarlos

La mayoría de los fallos de DMARC en entornos de Microsoft 365 se deben a problemas de alineación, no a errores de protocolo. Esto significa que el registro es técnicamente válido, pero el correo electrónico que se envía no coincide con el dominio de firma DKIM ni con las direcciones IP autorizadas por SPF.

Los informes DMARC están vacíos.

Diagnosticar: La dirección de correo rua= es incorrecta, el buzón está bloqueando los informes entrantes o el dominio no está enviando suficiente volumen como para que los principales proveedores hayan generado informes todavía.

Solución: Confirma que el buzón rua= existe, acepta correo externo y no está siendo filtrado por una regla de spam agresiva. Envía algunos correos electrónicos de prueba desde el dominio a direcciones de Gmail y Yahoo; estos proveedores suelen generar informes en un plazo de 24 a 48 horas si DMARC está configurado correctamente.

El correo electrónico legítimo está siendo puesto en cuarentena o rechazado.

Diagnosticar: Una plataforma de envío de terceros no está alineada. La causa más común es una herramienta de marketing, CRM o proveedor de correo electrónico transaccional que no se ha agregado a SPF o no se ha configurado para firmar con DKIM para el dominio personalizado.

Solución: Revise los informes agregados de DMARC para identificar qué origen está fallando. Agregue el origen a su registro SPF (include:thirdparty.com), configure la firma DKIM para ese origen a través de su configuración de plataforma o vuelva temporalmente a p=none hasta que se corrija la alineación. Nunca deje la política en p=reject mientras haya orígenes conocidos que estén fallando.

Fallos de alineación DMARC después del reenvío

Diagnosticar: Los correos electrónicos reenviados suelen romper la alineación SPF porque la IP del servidor de reenvío no figura en el registro SPF del remitente original. DKIM normalmente se mantiene intacto tras el reenvío, por lo que este escenario suele convertirse en un caso de alineación que solo requiere DKIM.

Solución: Asegúrese de que DKIM firma correctamente para el remitente original. El correo alineado con DKIM pasa DMARC incluso cuando SPF falla debido al reenvío. Si DKIM también falla después del reenvío, el sistema de reenvío está modificando el contenido del mensaje y rompiendo la firma DKIM. Esta situación generalmente requiere compatibilidad con ARC (Authenticated Received Chain) por parte del servidor de reenvío para resolverse.

Errores de formato de registro DMARC

Diagnosticar: Los errores tipográficos en el registro DMARC TXT pueden invalidar toda la política. Algunos problemas comunes incluyen la falta del prefijo v=DMARC1, la ausencia de punto y coma entre las etiquetas o que el registro se divida incorrectamente entre varias entradas DNS.

Solución: Analice el registro publicado con el validador DMARC de MXToolbox y confirme que se ha procesado correctamente y es válido. Compruebe que el registro existe como una única entrada TXT en _dmarc.yourdomain.com, sin estar dividido en dos registros, y que cada etiqueta está separada por un punto y coma.

DMARC bien implementado protege su dominio.

Configurar DMARC es más fácil si se siguen los pasos en orden. Verifique SPF y DKIM, cree el registro, publíquelo en DNS y avance lentamente por cada etapa de la política, con tiempo suficiente para leer los informes y corregir problemas de alineación antes de endurecer la aplicación de las normas.

Dado que DMARC es la capa final de autenticación de correo electrónico, depende de que SPF y DKIM funcionen correctamente. Si estos registros están mal configurados o no coinciden, la aplicación de DMARC podría bloquear el correo legítimo en lugar de proteger el dominio contra la suplantación de identidad.

Sin embargo, la autenticación no resuelve todos los problemas de entregabilidad. Un dominio debidamente autenticado que envía a una lista llena de direcciones inválidas, desechables o inactivas seguirá generando rebotes permanentes, y esos rebotes afectan a su reputación. reputación del remitente de correo electrónico independientemente de lo limpio que esté su registro DMARC.

Antes de tu próxima campaña, sube tu lista a DeBounce y realiza una validación completa. Validación de listas de correo electrónicoLa autenticación confirma que el correo electrónico proviene de usted, mientras que la verificación de la lista confirma que se dirige a un destinatario legítimo. Ambas son necesarias para que cada campaña tenga mayores probabilidades de llegar a la bandeja de entrada.