Pasar DMARC no garantiza la colocación en la bandeja de entrada.

Esa es una de las realidades más importantes en la entrega de correo electrónico moderna.

DMARC indica a un servidor de correo receptor si un mensaje se alinea con la política de autenticación publicada del remitente. Ayuda a los receptores a identificar si un mensaje que afirma provenir de un dominio está correctamente autenticado mediante SPF o DKIM.

Pero Gmail y Microsoft no toman decisiones de entrega basándose únicamente en DMARC.

También evalúan la reputación del remitente, el comportamiento del destinatario, las tasas de quejas, señales de contenido, indicadores de phishing, contexto de reenvío, reglas a nivel de tenant y sistemas internos anti-abuso.

Eso significa que dos mensajes pueden pasar DMARC y aún así ser manejados de manera diferente por Gmail y Outlook. Uno puede llegar a la bandeja de entrada. Otro puede ser filtrado, limitado en tasa, colocado en spam o rechazado basándose en otras señales.

Para las organizaciones que envían tanto a ecosistemas de Google como de Microsoft, la lección es clara:

DMARC es necesario, pero no es toda la historia de la entregabilidad.

I. Por Qué Gmail y Outlook Manejan la Autenticación de Manera Diferente

Gmail y Microsoft soportan tanto SPF, DKIM como DMARC.

Ambos esperan que los remitentes serios autentiquen su correo.

Ambos usan la autenticación como parte de una prevención de abuso más amplia.

Pero sus ecosistemas, herramientas, políticas y capas de filtrado no son idénticos.

Los requisitos públicos de remitente de Google son más prescriptivos para remitentes masivos. Google requiere que todos los remitentes autentiquen el correo con SPF o DKIM, y los remitentes masivos deben usar SPF, DKIM y DMARC. Google también establece que DMARC pasa cuando SPF o DKIM autentica y se alinea con el dominio From visible.

Microsoft también se ha movido hacia requisitos de remitente más estrictos. En 2025, Microsoft anunció nuevos requisitos para remitentes de alto volumen a direcciones Outlook.com, Hotmail y Live.com, incluyendo SPF, DKIM y DMARC. Microsoft 365 también utiliza lo que llama autenticación implícita de correo electrónico, donde SPF, DKIM y DMARC tradicionales se combinan con señales como reputación del remitente, historial del remitente, historial del destinatario, análisis de comportamiento y otras técnicas.

La diferencia práctica no es que un proveedor «se preocupe» por DMARC y el otro no.

La diferencia es operativa.

La guía pública de Gmail ofrece a los remitentes una línea base más clara para el cumplimiento de correo masivo. El entorno de filtrado de Microsoft a menudo incluye más variación específica del tenant porque Exchange Online Protection, Defender para Office 365, políticas de buzón, reglas de permitir/bloquear y configuraciones empresariales pueden influir en cómo se maneja un mensaje.

Para los remitentes, esto crea una realidad simple:

Necesitas autenticación que satisfaga a ambos proveedores, y una reputación lo suficientemente sólida como para sobrevivir el filtrado más allá de la autenticación.

II. Repaso de DMARC: Lo Que Realmente Tiene Que Pasar

DMARC a menudo se malinterpreta.

Un mensaje no pasa DMARC solo porque SPF pasa.

Un mensaje no pasa DMARC solo porque DKIM pasa.

Un mensaje pasa DMARC solo cuando al menos un identificador autenticado se alinea con el dominio From visible.

Eso significa:

• SPF debe pasar y el dominio autenticado por SPF debe alinearse con el dominio From visible.
• O DKIM debe pasar y el dominio de firma DKIM debe alinearse con el dominio From visible.

Esto es especialmente importante para plataformas de terceros.

Una herramienta de marketing, plataforma de soporte, CRM, sistema de facturación o servicio de correo electrónico transaccional puede pasar SPF o DKIM usando su propio dominio. Eso es útil para el proveedor, pero puede no ayudar a tu resultado DMARC a menos que el dominio autenticado se alinee con tu dominio From visible.

El usuario ve tu dominio.

DMARC verifica si el resultado de autenticación se conecta de vuelta a ese dominio.

III. Lo Que Gmail Requiere Que Los Remitentes Hagan Bien

Las pautas de remitente de Google hacen de la autenticación un requisito básico.

Para los remitentes, esto significa que Gmail espera:

• SPF o DKIM para todos los remitentes.
• SPF, DKIM y DMARC para remitentes masivos.
• Alineación DMARC con el dominio From visible.
• Bajas tasas de quejas de spam.
• Manejo adecuado de suscripciones y requisitos de cancelación de suscripción para correo de marketing.

Google también proporciona visibilidad a través de Postmaster Tools. Su panel de Autenticación muestra el porcentaje de correo que pasa SPF, DKIM y DMARC para mensajes que usan el dominio From del remitente. Google señala que los remitentes típicamente logran altas tasas de éxito de DKIM y DMARC cuando estos métodos están configurados correctamente, mientras que el éxito de SPF puede ser menor cuando participan remitentes de terceros.

Esto importa porque Gmail ofrece a los remitentes una forma más clara de observar la salud de la autenticación.

Sin embargo, Gmail Postmaster Tools no explica cada decisión de filtrado individual. Un mensaje puede pasar la autenticación y aún así ser filtrado si otras señales indican riesgo.

Los problemas comunes de entrega en Gmail incluyen:

• Mala reputación de dominio o IP.
• Altas tasas de quejas de spam.
• Picos repentinos en el volumen de envío.
• Contenido sospechoso o patrones similares al phishing.
• Remitentes de terceros mal configurados.
• Fallos de DKIM después de cambios de clave.
• Fallos de alineación SPF causados por dominios Return-Path de terceros.

Para Gmail, la autenticación es la línea base. Te pone en la conversación de confianza. No garantiza la colocación en la bandeja de entrada.

IV. Lo Que Microsoft Requiere Que Los Remitentes Hagan Bien

El ecosistema de Microsoft incluye Outlook.com, Hotmail, Live.com, Microsoft 365, Exchange Online Protection y Microsoft Defender para Office 365.

Eso crea más variación en cómo se evalúan los mensajes.

Microsoft anunció públicamente requisitos para remitentes de alto volumen a direcciones de Outlook.com, Hotmail y Live.com que incluyen SPF, DKIM y DMARC. Para Microsoft 365, la autenticación entrante se evalúa mediante SPF, DKIM, DMARC y señales de autenticación implícita adicionales como reputación del remitente, historial del remitente, historial del destinatario, análisis de comportamiento y otras técnicas avanzadas.

Esto significa que la autenticación importa, pero es parte de un sistema de decisión más amplio.

Un mensaje enviado a un entorno de Microsoft puede verse afectado por:

• Resultados de SPF, DKIM y DMARC.
• Reputación del remitente.
• Historial del destinatario o tenant.
• Políticas de Defender para Office 365.
• Reglas de transporte de Exchange.
• Listas de permitir o bloquear específicas del tenant.
• Inteligencia de suplantación.
• Reportes de usuarios.
• Análisis de contenido y archivos adjuntos.
• Detección de URL y phishing.

Es por esto que los remitentes a veces ven diferencias entre tenants de Microsoft.

Un mensaje puede ser aceptado por una organización y filtrado por otra porque el tenant receptor tiene diferentes políticas, configuraciones de seguridad, listas de permitir o relación histórica con el remitente.

Eso no significa que Microsoft ignore DMARC.

Significa que el entorno de filtrado de Microsoft tiene más capas que solo DMARC.

V. Gmail vs Outlook: Diferencias Prácticas para los Remitentes

La comparación más segura no es «qué proveedor aplica DMARC más».

La mejor comparación es cómo los remitentes experimentan los dos ecosistemas.

La conclusión operativa es directa:

Si tu correo se autentica limpiamente, se alinea correctamente, mantiene bajas quejas y usa patrones de envío estables, estás mejor posicionado tanto en Gmail como en Microsoft.

Si tu correo falla en alineación, usa remitentes de terceros mal configurados o tiene débil reputación, los problemas de autenticación pueden aparecer de manera diferente en los dos ecosistemas.

VI. Los Remitentes de Terceros Son el Punto de Falla Común

La mayoría de las organizaciones no envían todo el correo desde un solo sistema.

Utilizan:

• Plataformas de automatización de marketing.
• Sistemas CRM.
• Herramientas de helpdesk.
• Plataformas de ticketing.
• Servicios de correo electrónico transaccional.
• Sistemas de facturación.
• Plataformas de eventos.
• Herramientas de RRHH.
• Plataformas regionales o de unidades de negocio.

Cada remitente debe estar autenticado y alineado.

Aquí es donde los programas DMARC a menudo fallan.

Una plataforma de terceros puede estar incluida en SPF, pero SPF puede no alinearse porque el dominio Return-Path pertenece al proveedor.

Otra plataforma puede firmar el mensaje con DKIM, pero el dominio DKIM d= puede pertenecer al proveedor en lugar de tu dominio.

En ambos casos, el mensaje puede tener autenticación, pero aún así fallar en la alineación DMARC.

Esto puede afectar a Gmail y Microsoft de manera diferente porque cada proveedor combina la autenticación con otras señales de filtrado. Pero la solución es la misma:

Configura cada remitente de terceros para pasar SPF alineado o DKIM alineado.

En muchos casos, DKIM alineado es el camino más confiable porque SPF puede romperse en escenarios de reenvío e infraestructura de envío compartida.

VII. Cuando DMARC Pasa pero la Entrega Aún Falla

Pasar DMARC no es lo mismo que colocación en la bandeja de entrada.

Un mensaje puede pasar DMARC y aún así ser filtrado debido a:

• Altas tasas de quejas.
• Bajo engagement.
• Baja reputación de dominio.
• Baja reputación de IP.
• Contenido sospechoso.
• Indicadores de phishing.
• URLs inseguras.
• Picos repentinos de volumen.
• Mala higiene de listas.
• Filtrado a nivel de destinatario.
• Reglas a nivel de tenant.

Esto es cierto tanto para Gmail como para Microsoft.

La autenticación prueba que el mensaje está autorizado para usar el dominio.

No prueba que el mensaje sea deseado, seguro o de alta calidad.

Esa distinción importa.

Un remitente puede tener SPF, DKIM y DMARC perfectos y aún así tener un mal desempeño si los destinatarios marcan mensajes como spam, ignoran el correo o si el contenido activa sistemas de filtrado.

VIII. Cuando DMARC Falla pero el Correo Aún Parece Entregarse

También puede suceder lo contrario.

Un mensaje puede fallar DMARC y aún así parecer que se entrega.

Las posibles razones incluyen:

• El proveedor receptor aplica contexto adicional.
• El mensaje se reenvía y se evalúa con señales de autenticación adicionales.
• El destinatario o tenant ha incluido al remitente en lista blanca.
• El mensaje se coloca en spam en lugar de ser rechazado.
• El receptor trata la política publicada del dominio de manera diferente en escenarios específicos.
• El mensaje es juzgado de bajo riesgo por otros sistemas de filtrado.

Esto no significa que DMARC sea irrelevante.

Significa que DMARC es una señal en una decisión más grande del lado receptor.

Los remitentes no deben usar la entrega ocasional de correo fallido como prueba de que la autenticación está saludable.

Si los reportes DMARC muestran fallos, esos fallos deben investigarse incluso cuando los usuarios no están reportando problemas de entrega.

IX. Modos de Falla Silenciosos a Vigilar

Los problemas más peligrosos son los que no crean tickets de soporte inmediatos.

1. Deriva de Autenticación

Un proveedor cambia infraestructura. Un selector DKIM se rota incorrectamente. Las inclusiones de SPF cambian. Un equipo de negocios agrega una nueva herramienta de envío.

El correo puede continuar entregándose por un tiempo, pero los reportes DMARC comienzan a mostrar fallos.

Sin monitoreo, el problema permanece oculto hasta que la entregabilidad cae o el riesgo de suplantación aumenta.

2. Enmascaramiento de Reputación

Un remitente con fuerte reputación puede no ver impacto inmediato en la entrega por algunos problemas de autenticación.

Eso puede crear falsa confianza.

La brecha de autenticación aún existe, y puede volverse visible más tarde cuando cambie la reputación, haya picos de volumen o cambien los umbrales de filtrado del proveedor.

3. Diferencias de Entrega Específicas del Tenant

Los entornos de Microsoft pueden variar según la configuración del tenant.

Un cliente puede recibir el mensaje. Otro puede ponerlo en cuarentena. Otro puede bloquearlo debido a reglas locales o política de Defender.

Esto hace que la resolución de problemas sea más difícil porque los resultados de autenticación por sí solos no explican cada resultado de entrega.

4. Reenvío y Listas de Correo

El reenvío puede romper SPF porque el servidor de reenvío no está autorizado en el registro SPF del remitente original.

DKIM puede sobrevivir al reenvío si el mensaje no se modifica. Si DKIM también falla, DMARC puede fallar.

ARC puede ayudar a los receptores a evaluar el contexto de correo reenviado, pero los remitentes aún deben apuntar a una fuerte alineación DKIM para reducir la dependencia del comportamiento de reenvío.

X. Guía de Implementación para Gmail y Microsoft

Un programa de autenticación sólido no debe diseñarse solo para un proveedor.

Debe funcionar en ambos ecosistemas.

1. Publicar DMARC y Monitorear Reportes

Comienza con monitoreo para identificar remitentes legítimos y fallos.

Un registro estático básico puede verse así:

v=DMARC1; p=none; rua=mailto:[email protected]

Un mejor enfoque es usar un registro de monitoreo DMARC administrado a través de Skysnag para que los reportes se recopilen, analicen y conviertan en inteligencia de remitente accionable.

Comienza el monitoreo DMARC con Skysnag y obtén tu registro DMARC gratuito.

2. Autenticar Cada Remitente Legítimo

Para cada remitente, confirma:

• SPF está autorizado donde sea necesario.
• DKIM está habilitado.
• Al menos un método se alinea con el dominio From visible.
• El remitente está documentado.
• El dueño del negocio es conocido.
• La autenticación se monitorea a lo largo del tiempo.

3. Preferir DKIM Alineado para Plataformas de Terceros

Donde sea posible, configura plataformas de terceros para firmar DKIM usando tu dominio.

Esto reduce la dependencia de la alineación SPF, que puede ser frágil cuando el correo pasa a través de infraestructura compartida o rutas de reenvío.

4. Separar Flujos de Correo

Usa dominios o subdominios apropiados para diferentes categorías de correo.

Por ejemplo:

• Correo transaccional.
• Correo de marketing.
• Correo de soporte.
• Notificaciones de seguridad.
• Sistemas internos.

Esto hace que la autenticación sea más fácil de gestionar y la reputación más fácil de proteger.

5. Moverse Hacia la Aplicación con Cuidado

No te quedes en p=none para siempre.

Después del descubrimiento y la remediación, mueve los dominios maduros hacia cuarentena y luego rechazo.

Un enfoque por etapas debe basarse en:

• Preparación del dominio.
• Madurez del subdominio.
• Estabilidad del grupo de remitentes.
• Criticidad del negocio.
• Tasas de paso de autenticación.
• Estado de remediación.

Evita el despliegue basado en porcentaje como estrategia principal. Los programas DMARC actuales conscientes deben escalar la aplicación por dominio, subdominio, grupo de remitentes y unidad de negocio en lugar de depender de pct.

6. Monitorear Reputación Separadamente de la Autenticación

Los reportes DMARC muestran resultados de autenticación.

No explican completamente la colocación en la bandeja de entrada.

Usa herramientas de proveedor y métricas operativas donde estén disponibles, incluyendo:

• Google Postmaster Tools.
• Rastreo de mensajes de Microsoft 365 y reportes de seguridad donde sea aplicable.
• Datos de rebote.
• Tendencias de quejas.
• Métricas de engagement.
• Monitoreo de listas de bloqueo y reputación.
• Pruebas de entrega en proveedores de buzones.

La autenticación y la reputación deben monitorearse juntas.

XI. Implicaciones de Cumplimiento

La autenticación de correo electrónico soporta muchos programas de cumplimiento y gobernanza, pero debe describirse con precisión.

DMARC puede apoyar objetivos anti-phishing, protección de dominio, supervisión de proveedores e integridad de comunicación. También puede proporcionar evidencia de que la organización monitorea envíos no autorizados y fallos de autenticación.

Sin embargo, DMARC no satisface automáticamente GDPR, PCI DSS, HIPAA, SOC 2, NIS2 o cualquier otro marco por sí solo.

Mejor marco:

• DMARC apoya controles anti-phishing e integridad de comunicación.
• SPF y DKIM apoyan la autenticación del remitente.
• Los reportes DMARC apoyan el monitoreo y recopilación de evidencia.
• La aplicación apoya la protección contra la suplantación de dominio exacto.
• MTA-STS y TLS-RPT apoyan la visibilidad de transporte de correo seguro.

Skysnag Comply ayuda a las organizaciones a mantener visibilidad, informes y evidencia sobre la postura de autenticación de correo electrónico a través de fuentes y dominios de envío.

XII. Modelo Operativo Práctico

Para organizaciones que envían a Gmail y Microsoft, el modelo operativo debe ser simple:

1. Conoce cada remitente.
2. Autentica cada remitente.
3. Alinea al menos un método de autenticación con el dominio From visible.
4. Monitorea reportes DMARC continuamente.
5. Rastrea la reputación del proveedor y señales de quejas.
6. Separa flujos de correo por función y riesgo.
7. Muévete del monitoreo a la aplicación cuando estés listo.
8. Trata los problemas de entrega como problemas tanto de autenticación como de reputación.
9. Revisa remitentes de terceros regularmente.
10. Mantén documentación para auditoría y gobernanza.

Este modelo funciona porque no depende de adivinar exactamente cómo Gmail o Microsoft pesa cada señal internamente.

Se enfoca en los controles que los remitentes realmente pueden gestionar.

XIII. Conclusiones Clave

Tanto Gmail como Microsoft requieren una autenticación de correo electrónico robusta para remitentes serios, especialmente aquellos que envían grandes volúmenes.

Los requisitos públicos de Gmail para remitentes son más prescriptivos para los remitentes masivos, mientras que Microsoft combina la autenticación tradicional con señales de autenticación implícitas como reputación, historial del remitente, historial del destinatario, análisis de comportamiento y controles específicos del inquilino.

Pasar la validación DMARC no garantiza la ubicación en la bandeja de entrada.

Fallar en DMARC no siempre significa rechazo inmediato.

La autenticación debe gestionarse junto con la reputación, las tasas de quejas, la calidad del contenido, los patrones de envío y la visibilidad específica del proveedor.

El mayor riesgo operativo es la desalineación de remitentes externos. Cada plataforma que envía en nombre del dominio debe estar configurada para pasar SPF alineado o DKIM alineado.

La estrategia más segura no es optimizar para Gmail o Microsoft por separado. Es construir un programa de autenticación disciplinado que funcione en ambos.

Comienza a monitorear DMARC con Skysnag y obtén tu registro DMARC gratuito.