Leer la autenticación compuesta como resultado de Microsoft
El campo compauth de Microsoft no es otra ortografía de DMARC. Es una evaluación compuesta que utiliza autenticación y otras señales de mensajes, y su interpretación pertenece al procesamiento documentado de Microsoft. Por lo tanto, un mensaje puede contener DMARC de aspecto diferente y resultados compuestos sin que el encabezado sea inherentemente contradictorio. La tarea correcta es leer cada campo, su contexto de identidad y el código de motivo asociado antes de decidir qué establece el resultado.
Este artículo utiliza la documentación principal de Microsoft conservada el 8 de noviembre de 2026. La página de encabezado antispam identifica una actualización del 27 de julio de 2026. No se proporcionó ningún mensaje original ni seguimiento del inquilino y el siguiente ejemplo es explícitamente ficticio en lugar de un encabezado redactado. El catálogo requiere un ejemplo real del mensaje original antes de que se puedan publicar conclusiones operativas.
Mantenga las identidades visibles
Microsoft define header.from como el dominio De visible, smtp.mailfrom como el sobre CORREO DE dominio y header.d como el DKIM dominio de firma cuando esté presente. Estos campos pueden diferir. Preservar su relación al leer los resultados: un SPF el pase para un dominio no se establece automáticamente alineación con el remitente visible, y un pase DKIM debe estar asociado con la firma y el dominio que describe. Campos de encabezado de autenticación de Microsoft
La decisión del protocolo de DMARC se refiere a la alineación con el dominio visible De acuerdo con sus reglas. La autenticación compuesta de Microsoft utiliza el dominio Desde como base mientras combina SPF , DKIM , DMARC y otra información. No reemplace el resultado DMARC separado con compauth en una declaración de cumplimiento o una conclusión de solución de problemas DNS . Responden preguntas relacionadas pero no idénticas. RFC 9989 Campos compuestos de Microsoft
Interpretar el resultado y razonar juntos.
Microsoft documenta que los valores de comparación pasan, fallan, pasan suavemente y ninguno, con un motivo de tres dígitos. Quédate con el par completo. Un código de motivo no es un código de respuesta SMTP , incluso cuando sus dígitos se parecen a otro diagnóstico. No decodifique reason=130 utilizando una tabla SMTP genérica ni infiera una condición para todo el inquilino a partir del valor de un mensaje. Utilice la tabla actual de Microsoft para el contexto observado. Autenticación compuesta de Microsoft
La referencia del encabezado describe la razón 000 como una falla de autenticación explícita con una falla DMARC y una política de cuarentena o rechazo, mientras que 001 se refiere a una falla de autenticación implícita en circunstancias documentadas débiles o de ausencia de política. Describe el 109 como un caso en el que no Registro DMARC existe pero el mensaje pasaría de lo contrario. Estas son definiciones de proveedores con alcance, no instrucciones para fabricar un encabezado o prueba de que dicho mensaje se observó aquí. Códigos de motivo de Microsoft
Comprenda bestguesspass sin reclamar una política publicada
La etiqueta dmarc=bestguesspass de Microsoft significa que no hay DMARC registro TXT existe pero el mensaje pasaría si el dominio tuviera uno. No debe reportarse como prueba de que el dominio publicó una política DMARC válida o que la evaluación DMARC estándar real arrojó aprobación. Conserve la etiqueta del proveedor palabra por palabra y explique su significado limitado. Valores de campo de Microsoft DMARC
Un remitente que revise dicho resultado aún debe verificar la política pública real y la configuración de autenticación prevista. No asuma que el éxito compuesto elimina la necesidad de una política de dominio explícita o garantiza que otros receptores harán la misma evaluación. Una heurística o inferencia específica del receptor no es un reemplazo portátil de los controles publicados del dominio.
ARC y las señales implícitas no reescriben los hechos subyacentes
Los documentos de Microsoft consideran 130 como confiable ARC El resultado del sellador anula una falla DMARC . Eso puede explicar un resultado compuesto en una ruta reenviada o mediada, pero no significa que la falla subyacente DMARC deba borrarse del registro de evidencia. Mantenga distinguibles el resultado original, el contexto ARC , el motivo y el manejo final. No afirme que cualquier encabezado ARC arbitrario es suficiente; el caso documentado se refiere a un sellador de confianza. Razón de Microsoft 130
De manera similar, Microsoft describe otras señales implícitas y señala que una falla compuesta no resulta directamente en un bloqueo. La evaluación general puede permitir un mensaje a pesar de ese error, mientras que otras tecnologías de protección pueden identificar riesgos en el correo autenticado. En consecuencia, compauth=pass no es garantía de ubicación en la bandeja de entrada o seguridad del contenido, y compauth=fail no es por sí solo una prueba de rechazo. Explicación del manejo de Microsoft
Establecer el límite de confianza del encabezado
Obtenga un mensaje original autorizado del receptor correspondiente e identifique qué sistema confiable produjo los resultados. RFC 8601 explica por qué Authentication-Results Las afirmaciones necesitan un límite de confianza. Pueden aparecer varios encabezados a lo largo de la ruta del mensaje y un remitente que no es de confianza puede insertar texto que parezca autorizado. No seleccione el suceso que mejor coincida con la conclusión deseada sin rastrear su procedencia. RFC 8601
Guarde un original intacto para verificación interna y una copia explicativa redactada por separado. Cambiar direcciones o contenido firmado puede impedir la revalidación criptográfica independiente, así que etiquete la copia en consecuencia. Una anotación puede preservar las relaciones de identidad para la discusión, pero no es un mensaje original recientemente verificable. Si el destinatario necesita pruebas más sólidas, utilice un proceso de transferencia segura aprobado en lugar de ampliar la divulgación silenciosamente.
Hoja de trabajo original de resultados compuestos
La siguiente hoja de trabajo propuesta hace que la interpretación de campo sea reproducible. No contiene un mensaje real y no debe tratarse como un análisis de autenticación completo.
- Origen de la evidencia: referencia del mensaje recibido, receptor, marca de tiempo y verificador confiable.
- Identidad visible: header.from y su relación con el remitente comercial.
- SPF : resultado exacto, smtp.mailfrom y contexto de origen observado.
- DKIM : resultado para cada firma relevante y encabezado correspondiente.d.
- DMARC : valor exacto del campo del proveedor y contexto de política verificado por separado.
- Compuesto: valor de comparación, motivo de tres dígitos y definición citada de Microsoft.
- Mediación: reenvío, ARC confiable u otra ruta de evidencia realmente disponible.
- Resultado: manipulación observada, conclusiones no fundamentadas y próxima evidencia necesaria.
No combine resultados de diferentes mensajes para crear un registro sintético de todos los pases. Una muestra de entrega directa exitosa y una muestra de falla reenviada pueden revelar una diferencia de ruta, pero cada una necesita su propia identidad y marca de tiempo. Conservar las incógnitas cuando un campo o mensaje original no está disponible.
Ejemplo ficticio: el éxito inferido se confunde con la implementación de políticas
Fictional Seabright Desk ve un informe hipotético que contiene dmarc=bestguesspass y compauth=pass reason=109. La revisión propuesta explica que el significado documentado no establece un registro DMARC publicado. El propietario del correo aún inspeccionaría la política real y confirmaría la implementación prevista en lugar de marcar el dominio como completo únicamente a partir del resultado compuesto.
En este trabajo no existe ningún encabezado de Seabright Desk, respuesta DNS ni resultado de inquilino. Los valores se utilizan únicamente para ilustrar la interpretación documentada de Microsoft, no como evidencia de verificación inventada. Un análisis real requiere el mensaje original y el contexto de la fuente confiable.
El catálogo requiere definiciones de campos de Microsoft actuales y un ejemplo de mensaje original redactado. Las definiciones se basan en las fuentes, pero falta la evidencia del mensaje original. La evidencia original, la PYME humana, la aplicabilidad de la fuente, las rutas de producción, la accesibilidad visual y la autorización del propietario permanecen abiertas. Este borrador es una guía de interpretación, no una evaluación verificada del inquilino.