Microsoft 결과로 복합 인증 읽기
Microsoft의 compauth 필드는 다음의 철자가 아닙니다. DMARC. 이는 인증 및 기타 메시지 신호를 사용하는 종합 평가이며 해당 해석은 Microsoft의 문서화된 처리에 속합니다. 따라서 메시지에는 본질적으로 모순되는 헤더 없이 다르게 보이는 DMARC 와 복합 결과가 포함될 수 있습니다. 올바른 작업은 결과가 무엇인지 결정하기 전에 각 필드, 해당 ID 컨텍스트 및 관련 이유 코드를 읽는 것입니다.
이 문서에서는 2026년 11월 8일에 보관된 Microsoft 기본 문서를 사용합니다. 스팸 방지 헤더 페이지는 2026년 7월 27일 업데이트를 식별합니다. 원본 메시지나 테넌트 추적이 제공되지 않았으며 아래 예는 수정된 헤더가 아니라 명시적으로 허구입니다. 카탈로그에는 운영 결론이 공개되기 전에 실제 원본 메시지 예제가 필요합니다.
신원을 눈에 띄게 유지하세요
Microsoft는 header.from을 눈에 보이는 보낸 사람 도메인으로, smtp.mailfrom을 봉투로 정의합니다. 메일 보낸 사람 도메인 및 header.d를 DKIM 존재하는 경우 도메인에 서명합니다. 이러한 필드는 다를 수 있습니다. 결과를 읽을 때 관계를 유지하십시오. SPF 하나의 도메인에 대한 패스가 자동으로 설정되지 않습니다. 조정 보이는 발신자와 DKIM 패스가 설명하는 서명 및 도메인과 연결되어야 합니다. Microsoft 인증 헤더 필드
DMARC 의 프로토콜 결정은 해당 규칙에 따라 표시되는 From 도메인과의 정렬에 관한 것입니다. Microsoft 복합 인증은 SPF , DKIM , DMARC 및 기타 정보를 결합하는 동안 해당 From 도메인을 기반으로 사용합니다. 규정 준수 설명이나 DNS 문제 해결 결론에서 별도의 DMARC 결과를 compauth로 대체하지 마세요. 관련되어 있지만 동일하지 않은 질문에 답합니다. RFC 9989 Microsoft 복합 필드
결과와 이유를 함께 해석
Microsoft 문서에서는 compauth 값을 통과, 실패, 소프트패스 및 없음으로 세 자리 이유를 설명합니다. 전체 쌍을 유지하십시오. 이유 코드는 해당 숫자가 다른 진단과 유사하더라도 SMTP 응답 코드가 아닙니다. 일반 SMTP 테이블을 사용하여 reason=130 디코딩하거나 한 메시지 값에서 테넌트 전체 조건을 추론하지 마세요. 관찰된 컨텍스트에 대해 현재 Microsoft 테이블을 사용합니다. Microsoft 복합 인증
헤더 참조는 이유 000을 DMARC 실패 및 격리 또는 거부 정책을 통한 명시적인 인증 실패로 설명하고, 001은 문서화된 약하거나 정책이 없는 상황에서 암시적인 인증 실패와 관련이 있습니다. 109가 없는 경우로 설명합니다. DMARC 레코드 존재하지만 그렇지 않으면 메시지가 전달됩니다. 이는 범위가 지정된 공급업체 정의이며 헤더를 제조하라는 지침이나 그러한 메시지가 여기에서 관찰되었다는 증거가 아닙니다. Microsoft 이유 코드
게시된 정책을 주장하지 않고도 bestguesspass를 이해합니다.
Microsoft의 dmarc=bestguesspass 라벨은 DMARC 없음을 의미합니다. TXT 레코드 존재하지만 도메인에 메시지가 있으면 메시지가 전달됩니다. 도메인이 유효한 DMARC 정책을 게시했거나 실제 표준 DMARC 평가가 통과했다는 증거로 보고되어서는 안 됩니다. 공급업체 라벨을 그대로 유지하고 제한된 의미를 설명합니다. Microsoft DMARC 필드 값
그러한 결과를 검토하는 발신자는 여전히 실제 공개 정책과 의도된 인증 구성을 확인해야 합니다. 복합적인 성공으로 인해 명시적인 도메인 정책이 필요하지 않거나 다른 수신자가 동일한 평가를 할 것이라고 보장하지 마십시오. 수신자별 휴리스틱 또는 추론은 도메인에 게시된 컨트롤을 대체할 수 없습니다.
ARC 및 암시적 신호는 기본 사실을 다시 작성하지 않습니다.
Microsoft는 이유 130을 신뢰할 수 있는 문서로 기록했습니다. ARC 실러의 결과가 DMARC 실패를 무시합니다. 이는 전달 또는 중재 경로의 복합적인 결과를 설명할 수 있지만 근본적인 DMARC 실패가 증거 기록에서 삭제되어야 한다는 의미는 아닙니다. 원래 결과, ARC 컨텍스트, 이유 및 최종 처리를 구별 가능하게 유지하세요. 임의의 ARC 헤더로 충분하다고 주장하지 마십시오. 문서화된 사건은 신뢰할 수 있는 봉인자에 관한 것입니다. 마이크로소프트 이유 130
마찬가지로 Microsoft는 복합 오류가 직접적으로 차단을 초래하지 않는다는 다른 암시적 신호와 참고 사항을 설명합니다. 전반적인 평가에서는 실패에도 불구하고 메시지를 허용할 수 있으며, 다른 보호 기술은 인증된 메일의 위험을 식별할 수 있습니다. 결과적으로 compauth=pass는 받은 편지함 배치나 콘텐츠 안전을 보장하지 않으며 compauth=fail 자체는 거부를 증명하지 않습니다. Microsoft 취급 설명
헤더 신뢰 경계 설정
관련 수신자로부터 승인된 원본 메시지를 얻고 어떤 신뢰할 수 있는 시스템이 결과를 생성했는지 식별합니다. RFC 8601 그 이유를 설명합니다. Authentication-Results 어설션에는 신뢰 경계가 필요합니다. 메시지 경로를 따라 여러 헤더가 나타날 수 있으며 신뢰할 수 없는 보낸 사람이 신뢰할 수 있는 것처럼 보이는 텍스트를 삽입할 수 있습니다. 출처를 추적하지 않고 원하는 결론과 가장 일치하는 항목을 선택하지 마십시오. RFC 8601
내부 확인을 위해 원본을 그대로 유지하고 별도의 수정된 설명 사본을 보관하십시오. 주소나 서명된 콘텐츠를 변경하면 독립적인 암호화 재검증이 방지될 수 있으므로 이에 맞게 사본에 레이블을 지정하세요. 주석은 논의를 위해 ID 관계를 보존할 수 있지만 새로 확인할 수 있는 원본 메시지는 아닙니다. 수령인에게 더 강력한 증거가 필요한 경우 조용히 공개 범위를 넓히는 대신 승인된 보안 이전 프로세스를 사용하세요.
원본 종합 결과 워크시트
다음 제안된 워크시트는 현장 해석을 재현 가능하게 만듭니다. 실제 메시지로 채워지지 않으며 완료된 인증 분석으로 취급되어서는 안 됩니다.
- 증거 출처: 수신된 메시지 참조, 수신자, 타임스탬프 및 신뢰할 수 있는 검증자.
- 표시되는 ID: header.from 및 비즈니스 발신자와의 관계.
- SPF : 정확한 결과, smtp.mailfrom 및 관찰된 소스 컨텍스트.
- DKIM : 각 관련 서명 및 해당 헤더에 대한 결과.d.
- DMARC : 정확한 공급업체 필드 값과 별도로 검증된 정책 컨텍스트입니다.
- 복합: compauth 값, 3자리 이유 및 인용된 Microsoft 정의.
- 중재: 실제로 사용 가능한 전달, 신뢰할 수 있는 ARC 또는 기타 경로 증거.
- 결과: 관찰된 처리, 뒷받침되지 않는 결론 및 다음 증거가 필요합니다.
종합적인 전체 통과 기록을 생성하기 위해 서로 다른 메시지의 결과를 결합하지 마십시오. 성공적인 직접 전달 샘플과 전달된 실패 샘플은 경로 차이를 드러낼 수 있지만 각각 고유한 ID와 타임스탬프가 필요합니다. 필드나 원본 메시지를 사용할 수 없는 경우 알 수 없는 항목을 보존합니다.
가상의 예: 추론된 성공은 정책 배포로 오해됩니다.
Fictional Seabright Desk는 dmarc=bestguesspass 및 compauth=pass reason=109. 제안된 검토에서는 문서화된 의미가 게시된 DMARC 기록을 확립하지 않는다고 설명합니다. 메일 소유자는 복합 결과만으로 도메인을 완료로 표시하는 대신 실제 정책을 검사하고 의도한 배포를 확인합니다.
이 작업에는 Seabright Desk 헤더, DNS 응답 또는 테넌트 결과가 없습니다. 이 값은 조작된 확인 증거가 아닌 Microsoft의 문서화된 해석을 설명하기 위해서만 사용됩니다. 실제 분석에는 원본 메시지와 신뢰할 수 있는 소스 컨텍스트가 필요합니다.
카탈로그에는 최신 Microsoft 필드 정의와 수정된 원본 메시지 예가 필요합니다. 정의는 소스 기반이지만 원본 메시지 증거는 없습니다. 원본 증거, 인간 SME, 소스 적용 가능성, 생산 경로, 시각적 접근성 및 소유자 공개는 계속 열려 있습니다. 본 초안은 검증된 임차인 평가가 아닌 해석 가이드입니다.