Compauth=fail en Microsoft 365: entender la autenticación compuesta y corregir los reason codes

⚡Lo esencial

• compauth es el veredicto de autenticación compuesta de Microsoft 365: combina SPF, DKIM, DMARC y señales internas (reputación, historial, PTR); no es un estándar RFC
• El campo se escribe compauth=<pass|softpass|fail|none> reason=<code> en la cabecera Authentication-Results; el reason indica por qué
• compauth=fail no bloquea automáticamente un mensaje en el caso general: Microsoft aplica una evaluación holística (SCL, CAT, SFTY) antes de decidir bandeja de entrada, correo no deseado o cuarentena. Salvedad: desde 2023, un fallo DMARC explícito frente a p=reject puede ser rechazado en la pasarela (NDR 550 5.7.509) cuando el MX apunta directamente a Microsoft 365
• La corrección duradera pasa casi siempre por la alineación de SPF + DKIM + DMARC en el dominio del From:
• Los códigos 604, 605 y 703 citados por algunas herramientas de terceros no están documentados por Microsoft: no bases un diagnóstico en ellos

Inspeccionas las cabeceras de un mensaje en Microsoft 365 y te encuentras con compauth=fail reason=001. El correo viene de un remitente conocido, SPF parece correcto y, sin embargo, el mensaje aterriza en correo no deseado o en cuarentena. El campo compauth es uno de los más incomprendidos de Exchange Online, porque no corresponde a ningún protocolo estándar: es un mecanismo propietario de Microsoft.

Esta guía es una referencia exhaustiva. Explica qué es la autenticación compuesta, cómo Microsoft 365 calcula este veredicto a partir de SPF, DKIM, DMARC y señales internas, la diferencia esencial entre autenticación implícita y explícita, y después aporta la tabla completa de reason codes verificada con la documentación oficial de Microsoft. Por último, encontrarás un plan de diagnóstico y corrección organizado por familia de códigos.

Se dirige a los administradores de Microsoft 365 y Exchange Online cuyos mensajes legítimos se marcan como suplantación o se ponen en cuarentena, así como a los responsables de entregabilidad que necesitan leer e interpretar una cabecera de autenticación de Microsoft.

¿Qué es la autenticación compuesta (compauth) de Microsoft 365?

La autenticación compuesta es un veredicto propietario de Microsoft. A diferencia de SPF (RFC 7208), DKIM (RFC 6376) y DMARC (RFC 7489), compauth no está definido por ninguna norma. Es una capa de evaluación que Microsoft 365 añade por encima de estos tres protocolos para producir un juicio global sobre la autenticidad de un remitente.

En concreto, Exchange Online Protection (EOP) no se limita a retransmitir los resultados SPF, DKIM y DMARC. Los agrega con señales adicionales: la reputación de la dirección IP emisora, el historial de los mensajes ya recibidos de esa infraestructura, el registro PTR (DNS inverso) de la IP y los patrones de comportamiento derivados del análisis masivo del tráfico de Microsoft. El resultado de esta agregación se inscribe en el campo compauth de la cabecera Authentication-Results.

La unidad básica de la evaluación es el dominio del From: visible para el destinatario, es decir, la dirección de la cabecera 5322.From (también llamada dominio P2). Es ese dominio el que Microsoft trata de proteger contra la suplantación, y sobre él recaen la alineación y el veredicto compuesto. Esta precisión no es trivial: un mensaje puede perfectamente superar SPF en el dominio del sobre (5321.MailFrom) y, aun así, fallar la autenticación compuesta, porque ese dominio del sobre no coincide con el dominio mostrado en el From:. El usuario final nunca ve el sobre, solo el From:; por tanto, es lógico que la protección contra la suplantación recaiga sobre esta dirección.

¿Por qué Microsoft creó esta capa adicional en lugar de atenerse a DMARC? Porque la adopción de DMARC sigue siendo parcial. Una parte importante de los dominios legítimos no tiene ninguna política DMARC, o publica un p=none que no da ninguna instrucción de aplicación. Sin señal compuesta, Microsoft tendría que confiar ciegamente en esos dominios (y dejar pasar la suplantación) o penalizarlos sistemáticamente (y bloquear correo legítimo). La autenticación compuesta es la respuesta a este dilema: permite evaluar un remitente incluso cuando los protocolos estándar no proporcionan un veredicto claro, apoyándose en señales observables del lado de Microsoft.

El campo aparece normalmente con esta forma en una cabecera:

Authentication-Results: spf=pass (sender IP is 40.107.0.1)
 smtp.mailfrom=captaindns.com; dkim=pass (signature was verified)
 header.d=captaindns.com; dmarc=pass action=none
 header.from=captaindns.com; compauth=pass reason=100

La sintaxis general es compauth=<resultado> reason=<code>. El resultado toma uno de cuatro valores, y el código de tres cifras precisa la razón exacta del veredicto.

compauth=pass / softpass / fail / none: ¿qué significa cada valor?

El resultado compuesto no se limita a éxito o fallo. Microsoft distingue cuatro estados, cada uno con un significado preciso.

Valor	Significado
pass	El mensaje superó la autenticación compuesta, por vía explícita (SPF/DKIM/DMARC alineados) o implícita (señales internas suficientes).
softpass	El mensaje superó parcialmente la autenticación implícita. Las señales son positivas pero débiles (alineación por PTR o por subred, por ejemplo).
fail	El mensaje falló la autenticación compuesta, explícita o implícita. No es un veredicto de bloqueo, sino un factor de riesgo.
none	El mensaje no fue evaluado para la autenticación compuesta, o la eludió (enrutamiento particular, mensaje ya procesado aguas arriba).

El matiz entre fail y none es importante. fail señala un fallo activo de autenticación: Microsoft evaluó el mensaje y concluyó que no podía garantizar la identidad del remitente. none señala una ausencia de evaluación, a menudo debida a un enrutamiento complejo o a un mensaje que ya atravesó otra pasarela.

Autenticación implícita frente a explícita: la clave para entender compauth

Es la distinción más importante de todo el artículo. Microsoft 365 evalúa la autenticación de un mensaje por dos vías, y el reason code indica cuál se tomó.

La autenticación explícita se basa en los registros DNS publicados por el dominio remitente: SPF, DKIM y la política DMARC. Es la autenticación estándar. Si el dominio publica un DMARC estricto (p=quarantine o p=reject) y el mensaje se alinea correctamente, el veredicto es explícito.

La autenticación implícita es una extensión propia de Microsoft. Cuando un dominio no publica DMARC, o publica una política permisiva (p=none, SPF en ~all o ?all), Microsoft no puede apoyarse en una intención declarada. Aplica entonces sus propias señales para decidir: reputación IP, historial de envío, alineación por PTR, MX del dominio. Esta vía permite que un mensaje legítimo sin DMARC pase (por ejemplo el reason 109), pero también expone a un fallo implícito (reason 001 o 6xx) cuando las señales son insuficientes.

Este mecanismo explica dos situaciones que a menudo desconciertan a los administradores. Un mensaje de un dominio sin ninguna autenticación puede obtener compauth=pass si su IP tiene una excelente reputación y un historial limpio (autenticación implícita superada). A la inversa, un mensaje de un dominio con un DMARC estricto pero mal alineado obtiene compauth=fail reason=000 (autenticación explícita fallida), aunque la IP emisora goce por lo demás de buena reputación.

La vía explícita siempre tiene prioridad. Si el dominio publica un DMARC utilizable, Microsoft aplica su política antes de recurrir a las señales implícitas. Por eso publicar un DMARC correctamente alineado es la palanca de control más potente de la que dispone un remitente sobre su veredicto compuesto.

¿Dónde encontrar compauth=fail en tus cabeceras?

El veredicto compuesto se lee en la cabecera Authentication-Results, pero el análisis completo exige cruzar varias cabeceras de Microsoft.

La cabecera Authentication-Results reúne los veredictos SPF, DKIM, DMARC y compauth. Es el punto de partida. Pero para entender el impacto real de un compauth=fail, hay que leer también la cabecera X-Forefront-Antispam-Report, que contiene los campos de decisión de EOP.

En X-Forefront-Antispam-Report, varios campos son útiles:

Campo	Función
CAT	Categoría de veredicto de EOP (SPM para spam, PHSH para phishing, SPOOF para suplantación, BULK, etc.).
SFV	Veredicto del filtro (por ejemplo SKS para regla de transporte, SPM para spam).
SCL	Spam Confidence Level, de -1 a 9. Cuanto más alto es el valor, más se considera el mensaje no deseado.
SFTY	Indicador de seguridad, en particular 9.x para los mensajes de tipo suplantación o phishing: 9.19 suplantación de dominio, 9.20 suplantación de usuario, 9.25 aviso de seguridad de «primer contacto».

Aquí tienes un ejemplo de cabecera real, comentado, donde la autenticación compuesta falla:

Authentication-Results: spf=none (sender IP is 203.0.113.20)
 smtp.mailfrom=marketing.captaindns.com; dkim=none (message not signed)
 header.d=none; dmarc=none action=none header.from=captaindns.com;
 compauth=fail reason=001
X-Forefront-Antispam-Report: CIP:203.0.113.20; CTRY:US;
 CAT:SPOOF; SFV:SPM; SCL:5; SFTY:9.19

Aquí, el dominio no publica ni SPF utilizable, ni DKIM, ni DMARC: la autenticación explícita es imposible y la implícita falla (reason=001). EOP clasifica el mensaje como CAT:SPOOF con un SCL:5 y un indicador SFTY:9.19, lo que lo destina al correo no deseado. Es el cruce de compauth=fail con estos campos de decisión lo que determina el destino real del mensaje.

Falta saber dónde recuperar estas cabeceras. En Outlook para la web, abre el mensaje, luego el menú de opciones y «Ver los detalles del mensaje» para copiar el origen sin procesar. En el cliente Outlook de escritorio, abre el mensaje en su propia ventana, luego Archivo y después Propiedades: el campo «Encabezados de Internet» contiene el conjunto. Del lado del administrador, el seguimiento de mensajes (message trace) del centro de administración de Exchange permite recuperar el veredicto de EOP de un mensaje entregado sin siquiera acceder al buzón del destinatario. Para un diagnóstico a escala, los informes agregados DMARC (RUA) recopilan las fuentes de envío que fallan y complementan de forma útil la lectura de una cabecera individual.

Para extraer y leer estas cabeceras sin error, copia el origen completo del mensaje y pásalo por un analizador dedicado. El tema de la lectura de cabeceras se detalla en nuestra guía Cómo leer las cabeceras de un email.

La tabla completa de los reason codes compauth

Aquí está la referencia central de este artículo. La tabla siguiente está verificada con la documentación oficial de Microsoft (página «Anti-spam message headers» de Microsoft Learn, actualizada al 8 de octubre de 2025). Cada fila da el código, el resultado compuesto asociado, el significado exacto según Microsoft, la causa típica y la resolución.

Código	compauth	Significado (Microsoft)	Causa típica	Resolución
000	fail	Fallo de autenticación explícita. DMARC falla con una política p=quarantine o p=reject. Desde 2023, un p=reject respetado por defecto puede provocar un rechazo en la pasarela (NDR 550 5.7.509), no solo una clasificación en No deseados.	El dominio publica un DMARC estricto pero el mensaje no se alinea (SPF/DKIM rompen la alineación, a menudo en reenvío o fuente no autorizada).	Alinear SPF y DKIM con el From:; autorizar la fuente de envío; configurar un ARC sealer de confianza en caso de reenvío.
001	fail	Fallo de autenticación implícita. Sin registros de autenticación publicados, o política débil.	El dominio no tiene (o tiene poca) autenticación: SPF en ~all/?all, o DMARC en p=none. Microsoft carece de señal.	Publicar SPF + DKIM + DMARC alineados; endurecer progresivamente hacia ~all y luego -all.
002	fail	Una política del tenant prohíbe explícitamente esta pareja remitente/dominio.	Entrada manual de administrador (Tenant Allow/Block List, bloqueo de suplantación).	Verificar y retirar la entrada de bloqueo si el remitente es legítimo.
010	fail	DMARC falla con p=reject/p=quarantine, y el dominio remitente es un dominio aceptado de tu organización.	Suplantación intra-organización: un servicio de terceros envía «en nombre de» tu propio dominio sin estar autorizado.	Autorizar la fuente en SPF/DKIM o a través de la Tenant Allow/Block List.
1xx	pass	El mensaje superó la autenticación explícita o implícita.	Éxito.	Ninguna acción.
100	pass	SPF tuvo éxito o DKIM tuvo éxito, y MAIL FROM y From están alineados.	Éxito nominal.	Ninguna acción.
101	pass	El mensaje está firmado con DKIM por el dominio del From:.	Éxito DKIM alineado.	Ninguna acción.
102	pass	MAIL FROM y From alineados, y SPF tuvo éxito.	Éxito SPF alineado.	Ninguna acción.
103	pass	El From: está alineado con el PTR (DNS inverso) de la IP de origen.	Éxito vía PTR.	Ninguna acción.
104	pass	El PTR de la IP de origen está alineado con el dominio del From:.	Éxito vía PTR.	Ninguna acción.
108	pass	DKIM falló a causa de una modificación del cuerpo por un salto legítimo anterior.	Tolerado (entorno on-premises, por ejemplo).	Vigilar las modificaciones en tránsito; considerar ARC.
109	pass	Sin DMARC, pero el mensaje pasaría igualmente la evaluación.	Tolerado.	Publicar DMARC para formalizar la intención.
111	pass	A pesar de un temperror o permerror DMARC, SPF o DKIM está alineado con el From:.	Tolerado a pesar de un error DNS.	Corregir el registro DMARC.
112	pass	Un timeout DNS impidió recuperar el DMARC.	Error DNS transitorio.	Verificar la resolución DNS del dominio.
115	pass	El mensaje viene de una organización Microsoft 365 donde el From: es un dominio aceptado.	Tolerado (Microsoft 365 hacia Microsoft 365).	Ninguna acción.
116	pass	El MX del From: está alineado con el PTR de la IP de conexión.	Tolerado.	Ninguna acción.
130	pass	El resultado ARC de un ARC sealer de confianza reemplazó un fallo DMARC.	Reenvío a través de un servicio de confianza ARC.	Configurar ARC sealers de confianza.
2xx	softpass	El mensaje superó parcialmente la autenticación implícita.	Señales parciales.	Reforzar SPF/DKIM/DMARC.
201	softpass	El PTR del From: está alineado con la subred del PTR de la IP de conexión.	Alineación débil (subred).	Reforzar la autenticación.
202	softpass	El From: está alineado con el dominio del PTR de la IP de conexión.	Alineación débil (PTR).	Reforzar la autenticación.
3xx	none	El mensaje no fue verificado para la autenticación compuesta.	No evaluado.	Ninguna.
4xx	none	El mensaje eludió la autenticación compuesta.	Elusión.	Ninguna.
501	(n/a)	DMARC no aplicado: NDR (informe de no entrega) válido, contacto establecido previamente.	Tolerancia NDR.	Ninguna acción.
502	(n/a)	DMARC no aplicado: NDR válido para un mensaje enviado por esta organización.	Tolerancia NDR.	Ninguna acción.
6xx	fail	Fallo de autenticación email implícita.	Fallo implícito.	Publicar y alinear SPF, DKIM, DMARC.
601	fail	El dominio remitente es un dominio aceptado de tu organización (envío a uno mismo / suplantación intra-org).	Aplicación o servicio interno o de terceros que envía «como tú» sin autenticación.	Autorizar la fuente (SPF/DKIM, relé autenticado, Tenant Allow/Block List).
7xx	pass	El mensaje superó la autenticación implícita.	Éxito implícito.	Ninguna acción.
701-704	pass	DMARC no aplicado gracias a un historial de mensajes legítimos desde esta infraestructura.	Reputación e historial.	Ninguna acción.
9xx	none	El mensaje eludió la autenticación compuesta.	Elusión.	Ninguna.
905	none	DMARC no aplicado a causa de un enrutamiento complejo (on-premises o servicio de terceros antes de Microsoft 365).	Enrutamiento híbrido.	Configurar ARC o un relé autenticado.

Recuadro de exactitud: los códigos 604, 605 y 703

Algunas herramientas de terceros (entre ellas analizadores DMARC comerciales) citan los códigos 604, 605 y 703 como reason codes compauth diferenciados. Estos códigos no aparecen en la documentación oficial actual de Microsoft. En la familia 6xx, Microsoft solo documenta el código 601. En la familia 7xx, la documentación cubre el rango 701-704 sin aislar 703 con un significado propio. No se define ningún 604 ni 605.

Por tanto, no les inventamos ningún significado. Si te encuentras con uno de estos códigos, trátalo según su familia: un 6xx es un fallo implícito (a corregir como un 601), un 7xx es un éxito implícito. No bases un diagnóstico en una definición sin fuente.

Códigos de fallo: 000, 001, 002, 010 y 6xx/601

Son los códigos que llevan a un administrador a leer este artículo. Se reparten en dos lógicas.

Los códigos 000 y 010 corresponden al fallo explícito: el dominio publica un DMARC estricto, pero el mensaje no se alinea. El 010 es el caso particular en el que el dominio que falla es un dominio aceptado de tu propia organización. El 000, por su parte, concierne a cualquier dominio externo con DMARC estricto mal alineado.

Los códigos 001, 6xx y 601 corresponden al fallo implícito: Microsoft no pudo apoyarse en una política declarada y sus señales internas no fueron suficientes. El 601 es el subcaso del dominio aceptado de la organización. El 002, por último, es un caso aparte: no refleja un defecto técnico, sino una decisión de administrador (una entrada de bloqueo manual).

Códigos de éxito (1xx, 7xx) y softpass (2xx)

La familia 1xx agrupa los éxitos, sean explícitos (100, 101, 102) o tolerados a pesar de una debilidad (108, 109, 111, 112). El 130 merece una atención particular: indica que un ARC sealer de confianza permitió recuperar un mensaje que habría fallado en DMARC a causa de un reenvío.

La familia 7xx agrupa los éxitos implícitos basados en la reputación y el historial. La familia 2xx (softpass) señala un éxito débil: la alineación se apoya en señales tenues como el PTR o la subred. Un softpass no es un fallo, pero conviene reforzarlo publicando una autenticación explícita.

Códigos none / bypass (3xx, 4xx, 9xx, 905) y NDR (501/502)

Las familias 3xx, 4xx y 9xx corresponden a mensajes no evaluados o que eludieron la autenticación compuesta. El 905 es el más instructivo: señala un enrutamiento complejo (paso por un servidor on-premises o un servicio de terceros antes de Microsoft 365) que impide la aplicación normal de DMARC. La respuesta a un 905 suele ser la implantación de ARC o de un relé autenticado.

Los códigos 501 y 502 conciernen a los NDR (informes de no entrega) legítimos: Microsoft no les aplica DMARC porque responden a un contacto establecido previamente.

Diagnóstico y resolución por familia de códigos

La tabla da la visión de conjunto. Esta sección profundiza en los casos más frecuentes y en los pasos concretos a seguir.

reason=000: un DMARC estricto roto por la alineación

El reason=000 significa que el dominio remitente publica un DMARC en p=quarantine o p=reject, pero que el mensaje no respeta la alineación DMARC. La alineación DMARC exige que SPF o DKIM tenga éxito y que el dominio verificado coincida con el dominio del From:. A tener en cuenta: desde mediados de agosto de 2023, cuando el destinatario apunta su MX directamente a Microsoft 365, un reason=000 frente a un p=reject ya no se limita a degradar el mensaje, puede provocar un rechazo a nivel de la pasarela (NDR 550 5.7.509). Lo que está en juego con la corrección ya no es solo la bandeja de entrada frente a los No deseados, sino la entrega sin más.

La causa más frecuente es el reenvío de email. Cuando un mensaje se retransmite, la IP emisora cambia (la IP del servidor de reenvío reemplaza a la IP de origen), lo que rompe la alineación SPF. Si DKIM no está presente o si el cuerpo se modifica en tránsito, DKIM también falla, y DMARC falla por tanto por completo.

La segunda causa es el envío desde una fuente no autorizada: un proveedor de emailing que no ha sido declarado en el SPF ni configurado para firmar con DKIM con tu dominio.

La resolución depende del caso. Para una fuente de envío legítima, autorízala: añade su mecanismo include: al SPF y configura la firma DKIM alineada con tu dominio. Para el reenvío, la única respuesta robusta es ARC: el servidor de reenvío debe aplicar una firma ARC, y el destinatario Microsoft 365 debe reconocer ese sealer como de confianza (lo que produce entonces un reason=130).

Tomemos un ejemplo concreto de reenvío que produce un reason=000. Un mensaje sale de compta@captaindns.com, debidamente firmado con DKIM con d=captaindns.com y emitido desde una IP autorizada por el SPF del dominio. Todo está alineado en el origen. El destinatario ha configurado una redirección automática hacia un buzón alojado en Microsoft 365. El servidor de redirección reenvía el mensaje desde su propia IP, que no está en el SPF de captaindns.com: SPF falla del lado de Microsoft. Si el servidor de redirección, además, añadió un aviso de «mensaje reenviado» al cuerpo, el hash DKIM ya no coincide y DKIM también falla. El From: ha permanecido como compta@captaindns.com con un DMARC estricto: DMARC falla, por tanto, por completo, y Microsoft inscribe compauth=fail reason=000. Sin embargo, el mensaje es perfectamente legítimo. Solo ARC, al preservar los resultados de autenticación de origen a lo largo de toda la cadena, permite recuperar este caso sin flexibilizar la política del dominio emisor.

reason=001: autenticación ausente o demasiado débil

El reason=001 es el fallo implícito por excelencia. El dominio no proporciona a Microsoft con qué decidir: sin DMARC utilizable, SPF en ~all o ?all, sin DKIM alineado. Microsoft intenta una autenticación implícita, pero las señales (reputación IP, historial) no bastan para concluir positivamente.

La resolución es estructural. Publica los tres pilares de la autenticación email. Un SPF correcto que declare todas tus fuentes de envío, firmas DKIM alineadas con tu dominio, y un registro DMARC. Empieza DMARC en p=none correctamente alineado para observar sin bloquear, luego endurece hacia p=quarantine una vez que controles tus fuentes. Del lado de SPF, haz evolucionar el mecanismo final de ~all hacia -all cuando tengas la certeza de la exhaustividad de tus fuentes.

Un matiz importante: un dominio en p=none o un SPF en ~all no está «roto», solo es permisivo. Microsoft interpreta esa permisividad como una ausencia de intención clara y pasa a la autenticación implícita. El reason=001 no es, por tanto, la sanción de un error de sintaxis, sino la constatación de que el dominio no le da a Microsoft con qué concluir positivamente por la vía estándar. Precisamente por eso reforzar las políticas hace desaparecer el código: pasas la evaluación de la vía implícita (incierta) a la vía explícita (determinista).

reason=010 y reason=601: la suplantación intra-organización

Estos dos códigos comparten una característica: el dominio remitente es un dominio aceptado de tu propia organización Microsoft 365. Dicho de otro modo, un mensaje afirma venir de tu dominio, pero Microsoft no puede confirmar que fue realmente emitido por una fuente autorizada. El 010 corresponde a la vertiente explícita (DMARC estricto fallido), el 601 a la vertiente implícita.

Es un escenario extremadamente común en la práctica: una impresora de red, una aplicación de negocio, un CRM, una herramienta de facturación o un proveedor de marketing envía emails «en nombre de» tu dominio sin haber sido declarado en tu SPF ni configurado en DKIM. Microsoft lo interpreta como una potencial suplantación interna. Este mecanismo está ligado al aviso «via» que Microsoft 365 muestra a veces; lo detallamos en nuestro artículo sobre la suplantación intra-organización y el aviso de Microsoft.

La resolución consiste en autorizar explícitamente la fuente legítima. Tres opciones, por orden de preferencia: añadir la fuente a tu registro SPF y configurarla para firmar con DKIM con tu dominio; hacer transitar sus envíos por un relé SMTP autenticado de tu tenant; en último recurso, crear una entrada en la Tenant Allow/Block List. Evita apoyarte de forma duradera en la lista de autorización: es un parche provisional, no una autenticación.

reason=002: un bloqueo manual por la política del tenant

El reason=002 no traduce ningún defecto técnico. Señala que un administrador ha bloqueado explícitamente esta pareja remitente/dominio, generalmente a través de la Tenant Allow/Block List o una regla anti-suplantación. Si el remitente es legítimo, la resolución es sencilla: retirar la entrada de bloqueo. Antes de eso, verifica por qué se puso el bloqueo, para no reabrir una puerta cerrada por una buena razón.

reason=130: un ARC sealer reemplazó legítimamente el fallo DMARC

El reason=130 es un éxito, no un problema. Indica que un mensaje habría fallado en DMARC (típicamente a causa de un reenvío), pero que un ARC sealer de confianza preservó los resultados de autenticación de origen, lo que Microsoft aceptó. Es exactamente el comportamiento buscado para el reenvío legítimo. Si ves este código, tu cadena ARC funciona. El funcionamiento de ARC se detalla en nuestra guía Qué es ARC (Authenticated Received Chain).

¿Significa compauth=fail que mi email está bloqueado?

No en el caso general, pero con una salvedad importante desde 2023. La documentación de Microsoft sigue siendo explícita sobre el principio: un compauth=fail no provoca, por sí solo, un rechazo ni una puesta en cuarentena automática. El veredicto compuesto es un factor entre otros en la evaluación holística de EOP. Esto es cierto en particular para un fallo implícito (reason=001) y para los dominios sin DMARC estricto: el mensaje se evalúa entonces de forma global y a menudo aterriza en correo no deseado, no se rechaza.

La salvedad concierne al fallo explícito frente a una política DMARC estricta. Desde mediados de agosto de 2023, cuando el dominio destinatario apunta su MX directamente a Microsoft 365, Exchange Online Protection respeta por defecto la política DMARC publicada por el dominio remitente. Un fallo DMARC frente a p=reject provoca entonces un rechazo a nivel de la pasarela (con un informe de no entrega, NDR), y p=quarantine una puesta en cuarentena, en lugar del antiguo comportamiento que lo clasificaba todo en No deseados. Este cambio proviene del ajuste anti-phishing «Respetar la política DMARC cuando un mensaje se detecta como suplantación», activo por defecto, con acciones configurables distintas para p=quarantine y para p=reject. En concreto, un fallo explícito de tipo reason=000 frente a un p=reject puede ahora ser rechazado en la pasarela, y ya no solo clasificado en No deseados. El NDR devuelto toma la forma: 550 5.7.509: Access denied, sending domain ... does not pass DMARC verification and has a DMARC policy of reject.

Una salvedad dentro de la salvedad: este rechazo por defecto se aplica cuando el MX del destinatario apunta directamente a Microsoft 365. Si el MX apunta a una pasarela de terceros colocada delante de Microsoft 365, EOP solo respeta la política DMARC si el «filtrado mejorado para conectores» (Enhanced Filtering for Connectors) está activado, ya que debe poder recuperar la IP de envío real detrás del relé.

Tras establecer el veredicto compuesto, EOP combina esta información con otras señales para decidir el destino del mensaje: el SCL (Spam Confidence Level), la categoría CAT, el indicador de seguridad SFTY, la reputación de la IP, el contenido del mensaje, y las políticas anti-spam y anti-phishing configuradas en el tenant. Un mensaje puede perfectamente obtener compauth=fail y llegar pese a todo a la bandeja de entrada si las demás señales son tranquilizadoras.

A la inversa, es cuando compauth=fail se combina con una categoría desfavorable cuando el mensaje se degrada. Un CAT:SPOOF acompañado de un SFTY:9.x orienta el mensaje hacia el correo no deseado o la cuarentena, a menudo con un banner de aviso de suplantación. Es, por tanto, el contexto global, no el compauth por sí solo, lo que determina la entrega.

En concreto, coexisten varios caminos de decisión. Un compauth=fail reason=001 que viene de una IP con buena reputación, sin contenido sospechoso, puede aterrizar en la bandeja de entrada con un simple SCL bajo. El mismo reason=001 que viene de una IP nueva o poco reputada, con enlaces o adjuntos sospechosos, hereda un SCL elevado y una categoría SPM o PHSH, y se va a correo no deseado. Por último, un compauth=fail con CAT:SPOOF y SFTY:9.19 (suplantación de dominio) activa la protección anti-suplantación y puede llevar directamente a la cuarentena. El mismo valor compauth=fail produce, por tanto, tres desenlaces diferentes según el entorno de señales que lo rodea.

Esta lógica tiene una consecuencia práctica. Corregir un compauth=fail no se reduce a hacer desaparecer una bandera: se trata de reducir el riesgo global percibido por Microsoft. Alinear SPF, DKIM y DMARC hace subir el veredicto compuesto hacia pass, pero también mejora la reputación de tu infraestructura a largo plazo, lo que actúa sobre el conjunto de las señales. Si tus mensajes se van a correo no deseado a pesar de una autenticación correcta, nuestra guía Por qué tus emails llegan a spam cubre las demás palancas de entregabilidad.

Plan de acción recomendado para corregir un compauth=fail

Aquí tienes los pasos a seguir, del diagnóstico a la verificación, aplicables sea cual sea el reason code.

Diagnóstico y corrección de la autenticación compuesta, del reason code a la verificación

1. Abre el origen completo del mensaje y anota el valor exacto de compauth=fail reason=<code> en la cabecera Authentication-Results. Anota también CAT, SCL y SFTY en X-Forefront-Antispam-Report. El reason code orienta todo el diagnóstico.

2. Comprueba que todas tus fuentes de envío figuran en el registro SPF y que se respeta la alineación MAIL FROM/From. Vigila el número de consultas DNS (límite de 10) que provoca un permerror.

3. Asegúrate de que tus mensajes están firmados con DKIM y de que el dominio de firma (header.d=) coincide con el dominio del From:. Sin alineación DKIM, DMARC no puede tener éxito por esta vía.

4. Comprueba la presencia y la coherencia del registro DMARC. Verifica la alineación y la política (p=). Una política estricta mal alineada provoca un reason=000; una política ausente o en p=none favorece un reason=001.

5. Si el fallo viene de un reenvío, implanta ARC. El servidor de reenvío debe sellar el mensaje, y Microsoft 365 debe reconocer el sealer como de confianza para producir un reason=130.

6. Para un reason=010 o 601, autoriza la fuente interna: añadido al SPF y firma DKIM alineada, relé SMTP autenticado, o en último recurso Tenant Allow/Block List.

7. Tras la corrección, envía un mensaje de prueba e inspecciona de nuevo la cabecera. El veredicto debe subir hacia compauth=pass (reason 100 o 130 según el caso).

Para los pasos SPF y DKIM, dos herramientas aceleran el diagnóstico: el verificador SPF confirma la alineación y cuenta las consultas DNS, y el verificador DKIM valida la publicación y la sintaxis de tu clave. Las causas detalladas de un fallo de firma se cubren en nuestra guía DKIM fail: causas y correcciones, y los errores SPF en SPF permerror: diagnóstico y resolución y SPF: demasiadas consultas DNS.

Los nuevos requisitos de Microsoft para los remitentes de gran volumen

El compauth de Exchange Online Protection concierne al correo recibido por las organizaciones Microsoft 365. En paralelo, Microsoft ha subido el listón para el correo entrante en sus buzones de consumidor Outlook. Estos dos mecanismos son distintos, pero convergen hacia la misma exigencia: autenticar el correo.

Desde el 5 de mayo de 2025, todo remitente de más de 5.000 mensajes al día hacia buzones de consumidor @outlook.com, @hotmail.com y @live.com debe publicar los tres pilares SPF, DKIM y DMARC, con una política DMARC de al menos p=none alineada con SPF o con DKIM. Este umbral retoma la lógica ya impuesta por Gmail y Yahoo en febrero de 2024.

Según Microsoft, los mensajes no conformes se encaminan primero hacia los No deseados, luego, tras una fase inicial de filtrado, se rechazan (no entregados). El rechazo asociado toma la forma: 550 5.7.515 Access denied, sending domain [dominio] does not meet the required authentication level.

Un punto esencial para evitar cualquier confusión con el resto de este artículo: estos requisitos apuntan a los buzones de consumidor Outlook, Hotmail y Live, y corresponden a un mecanismo distinto del compauth de Exchange Online Protection del lado empresarial Microsoft 365. Los propios códigos SMTP difieren: 5.7.515 señala un defecto de autenticación del lado consumidor de gran volumen, mientras que 5.7.509 corresponde a un rechazo DMARC respetado por EOP del lado empresarial (ver más arriba). No confundas ambos.

La buena noticia es que la puesta en conformidad resuelve también el problema de fondo tratado en esta guía. Publicar SPF, DKIM y DMARC alineados para superar esta barrera elimina por construcción las causas de un reason=001 (fallo implícito): la evaluación de Microsoft pasa entonces de la vía implícita (incierta) a la vía explícita (determinista). La trayectoria es clara: Microsoft respeta DMARC por defecto del lado EOP en 2023, luego impone la autenticación a los grandes remitentes de Outlook en 2025, en la estela de Gmail y Yahoo. La autenticación email ya no es opcional.

FAQ

¿Qué es la autenticación compuesta (compauth) de Microsoft?

Es un veredicto propietario de Microsoft 365 que agrega los resultados SPF, DKIM y DMARC con señales internas: reputación de la IP emisora, historial de los mensajes, registro PTR y patrones de comportamiento. El resultado se inscribe en el campo compauth de la cabecera Authentication-Results. No es un estándar RFC, sino una capa de evaluación propia de Exchange Online Protection.

¿Qué significa compauth=fail en una cabecera Authentication-Results?

El veredicto compauth=fail indica que Microsoft 365 no pudo confirmar la autenticidad del remitente, por vía explícita (SPF/DKIM/DMARC alineados) o implícita (señales internas). El reason que sigue precisa por qué. No es un veredicto de bloqueo en sí, sino un factor de riesgo en la evaluación global del mensaje.

¿Bloquea siempre mi email un compauth=fail?

No. Microsoft aplica una evaluación holística: el veredicto compuesto se combina con el SCL, la categoría CAT, el indicador SFTY y la reputación de la IP antes de cualquier decisión. Un mensaje en compauth=fail puede llegar a la bandeja de entrada si las demás señales son favorables. Acaba en correo no deseado o en cuarentena sobre todo cuando se acompaña de un CAT:SPOOF y de un SFTY:9.x.

¿Qué significa reason=000?

El reason=000 es un fallo de autenticación explícita: el dominio remitente publica un DMARC estricto (p=quarantine o p=reject), pero el mensaje no respeta la alineación DMARC. La causa más frecuente es el reenvío de email, que rompe la alineación SPF, o un envío desde una fuente no declarada. La corrección pasa por la alineación SPF/DKIM o la implantación de ARC para el reenvío.

¿Qué significa reason=001?

El reason=001 es un fallo de autenticación implícita: el dominio no publica autenticación utilizable (sin DMARC, SPF en ~all o ?all, sin DKIM alineado), y las señales internas de Microsoft no bastan para concluir. La resolución consiste en publicar SPF, DKIM y DMARC correctamente alineados, y luego endurecer progresivamente las políticas.

¿Qué significan reason=010 y reason=601?

Ambos códigos señalan que el dominio remitente es un dominio aceptado de tu propia organización: un servicio o una aplicación envía «en nombre de» tu dominio sin estar autorizado. El 010 es la vertiente explícita (DMARC estricto fallido), el 601 la vertiente implícita. La resolución consiste en autorizar la fuente legítima a través de SPF/DKIM, un relé autenticado, o la Tenant Allow/Block List.

¿Qué diferencia hay entre compauth=pass, softpass, fail y none?

pass significa que la autenticación compuesta tuvo éxito, explícita o implícitamente. softpass es un éxito parcial de la autenticación implícita, basado en señales débiles (PTR, subred). fail es un fallo de autenticación, factor de riesgo pero no bloqueo automático. none significa que el mensaje no fue evaluado o eludió la autenticación compuesta.

¿Es el compauth fail diferente de un fallo SPF, DKIM o DMARC?

Sí. SPF, DKIM y DMARC son protocolos estandarizados con veredictos independientes. El compauth es un veredicto compuesto propio de Microsoft, que agrega esos tres resultados con señales internas. Un mensaje puede tener dmarc=fail pero compauth=pass (por ejemplo a través de un ARC sealer de confianza, reason 130), o lo contrario según las señales implícitas.

¿Por qué un email legítimo obtiene compauth=fail?

Las causas más frecuentes son el reenvío de email (que rompe la alineación SPF y a menudo DKIM), una fuente de envío no declarada en el SPF, un dominio sin DMARC ni DKIM alineado, o un servicio interno que envía en nombre de tu dominio sin autorización. La autenticidad real del mensaje no está en duda: es la incapacidad de Microsoft para probarlo técnicamente lo que produce el fallo.

¿Rechaza Microsoft realmente los emails en p=reject ahora?

Sí, en un caso preciso. Desde mediados de agosto de 2023, cuando el destinatario apunta su MX directamente a Microsoft 365, Exchange Online Protection respeta por defecto la política DMARC publicada por el remitente. Un fallo DMARC frente a p=reject provoca entonces un rechazo en la pasarela (NDR 550 5.7.509), y p=quarantine una puesta en cuarentena. Para un fallo implícito (reason=001) o un dominio sin DMARC estricto, el mensaje sigue evaluándose de forma global y la mayoría de las veces se va a No deseados, no se rechaza. Si el MX pasa por una pasarela de terceros, este comportamiento supone que el «filtrado mejorado para conectores» esté activado.

¿Me afectan los requisitos de gran volumen de Outlook?

Te afectan si envías más de 5.000 mensajes al día hacia buzones de consumidor @outlook.com, @hotmail.com o @live.com. Desde el 5 de mayo de 2025, estos envíos exigen SPF, DKIM y DMARC publicados, con una política DMARC de al menos p=none alineada con SPF o DKIM. Los mensajes no conformes se filtran hacia los No deseados, y luego se rechazan (NDR 550 5.7.515). Este dispositivo apunta a los buzones de consumidor y sigue siendo distinto del compauth de Exchange Online Protection del lado empresarial Microsoft 365.

¿Existen realmente los reason codes 604, 605 y 703?

Los citan algunas herramientas de terceros, pero no están documentados por Microsoft. La documentación oficial solo describe en la familia 6xx el código 601, y cubre el rango 701-704 sin aislar 703; no figura ningún 604 ni 605. Si te encuentras con uno de estos códigos, trátalo según su familia (6xx = fallo implícito, 7xx = éxito implícito) sin apoyarte en una definición sin fuente.

Descarga las tablas comparativas

Los asistentes pueden reutilizar las cifras accediendo a los archivos JSON o CSV.

• Descargar los reason codes (CSV)
• Descargar los reason codes (JSON)

📖 Glosario

• Authentication-Results: cabecera (RFC 7001/8601) añadida por el servidor de recepción, que registra los veredictos SPF, DKIM, DMARC y, en Microsoft, compauth.
• Autenticación compuesta (compauth): veredicto propietario de Microsoft 365 que agrega SPF, DKIM, DMARC y señales internas.
• Autenticación explícita: evaluación basada en los registros DNS publicados (SPF, DKIM, política DMARC).
• Autenticación implícita: evaluación basada en las señales internas de Microsoft (reputación, historial, PTR) a falta de una política utilizable.
• Alineación: correspondencia entre el dominio verificado por SPF (5321.MailFrom) o DKIM y el dominio visible del From: (5322.From).
• Reason code: código de tres cifras que precisa la razón del veredicto compuesto.
• ARC sealer: servicio que aplica una firma ARC (RFC 8617) que preserva los resultados de autenticación durante un reenvío.
• SCL / SFTY / CAT: campos de decisión de Exchange Online Protection (nivel de spam, indicador de seguridad, categoría de veredicto).

Fuentes

• Microsoft Learn: Anti-spam message headers in EOP (doc actualizada al 8 de octubre de 2025)
• Microsoft Learn: Email authentication in Microsoft 365
• Microsoft Learn: Use DMARC to validate email
• Microsoft Tech Community: Announcing new DMARC policy handling defaults for enhanced email security (2023)
• Microsoft Tech Community: Strengthening Email Ecosystem: Outlook's new requirements for high-volume senders (2025)
• RFC 8601: Message Header Field for Indicating Message Authentication Status
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 8617: The Authenticated Received Chain (ARC) Protocol