실패한 것을 결정하기 전에 경로를 분류하십시오.
수신자는 전달 홉 이후 또는 메일링 목록이 메일을 수정한 후에 원래 서비스에서 직접 메일을 볼 수 있습니다. 원본 IP 및 인증 실패 자체로는 이러한 경로와 가장을 구분하지 않습니다. 조사자는 보고된 결과를 특정 경로에 연결하고 경로가 누락된 부분의 불확실성을 유지해야 합니다. 그렇지 않으면 합법적인 발신자를 위한 수리로 인해 관련 없는 인프라가 승인될 수 있습니다.
이 가이드에서는 RFC 9989 그리고 RFC 9990 2026년 5월부터, SPF RFC 7208 및 실험 ARC 사양 RFC 8617 . 공급자 지침은 2026년 11월 8일에 검토되었습니다. 모든 경로 예시는 허구의 종이 사례입니다. 메시지가 전송되거나 가져오거나 확인되지 않았고 DNS 쿼리가 실행되지 않았으며 전달 또는 수신자 신뢰 설정이 변경되지 않았습니다.
수신 경계를 기준으로 직접 전송 정의
이 조사에서 직접 전송은 의도한 아웃바운드 서비스가 조사 중인 경로에서 중간 전달 서비스 없이 수신 경계로 전달되는 것을 의미합니다. 이는 원래 조직이 하나의 내부 서버만 사용한다는 의미는 아닙니다. 내부 릴레이와 아웃바운드 게이트웨이가 관찰된 연결보다 앞에 있을 수 있으므로 라벨을 적용할 때 사용된 경계를 기록하세요.
RFC 7208 정의된 SMTP ID에 대해 연결 호스트를 평가합니다. 직접 경로에서 실패는 구성 문제, 예상치 못한 경로 또는 무단 사용을 나타낼 수 있습니다. 결과만으로 원인을 밝히는 것만으로는 충분하지 않습니다. 인증에 대한 변경을 제안하기 전에 평가된 도메인, 연결 컨텍스트 및 오류 상태를 보존하십시오.
전달이 SPF 증거를 변경할 수 있는 이유 설명
전달자가 원본 메시지를 계속 전달하면 다음 수신자는 전달자의 연결 주소를 보게 됩니다. 원래 봉투 ID가 유지되는 경우 해당 주소는 원래 도메인의 SPF 정책에 따라 승인되지 않을 수 있습니다. 봉투가 다시 작성되면 SPF 대신 전달자의 신원을 인증할 수 있습니다. 두 가지 상황 모두 아래의 도메인에서 표시되는 원본에 대해 정렬된 SPF 경로를 자동으로 제공하지 않습니다. RFC 9989.
그렇기 때문에 관찰된 모든 전달자를 원래 도메인의 SPF 에 추가하는 것은 건전한 기본 응답이 아닙니다. 실제 경로나 다른 인증 경로를 다루지 않고도 인증을 확대할 수 있습니다. 먼저 전달이 발생했는지, 수신자가 예상했는지, 어떤 ID가 변경되었는지 확인합니다. 전달과 유사한 패턴은 대표적인 경로 증거가 이를 뒷받침할 때까지 가설입니다.
원래 DKIM 서명이 남아 있는지 검사
메시지는 유효한 정렬을 유지할 수 있습니다. DKIM 서명 서명된 자료가 검증과 호환되는 경우 전달을 통해. RFC 6376 서명이 다루는 내용과 확인 방법을 정의합니다. 서명된 헤더나 본문 내용을 변경하면 해당 서명이 손상될 수 있습니다. 단지 다른 서버를 통해 메시지를 이동한다고 해서 반드시 그렇게 되는 것은 아닙니다. 하나의 전달 제품을 모든 경로로 일반화하지 마세요.
메일링 리스트는 콘텐츠를 변경하거나, 바닥글을 추가하거나, 재배포 전에 메시지를 변형할 수 있습니다. 목록의 새로운 유효한 서명은 원래 보낸 사람 도메인과 정렬되지 않은 상태로 유지하면서 목록의 도메인을 인증할 수 있습니다. A가 신고했다 DKIM 따라서 pass에는 서명 ID가 필요하며 조정 문맥. 원저작자의 도메인이 통과되었다는 증거로 읽을 수 없습니다. DMARC.
신뢰에 여전히 결정이 필요한 증거로 ARC 사용하십시오.
RFC 8617 메시지 처리 단계 전반에 걸쳐 인증 평가를 수행하기 위한 실험적인 프로토콜입니다. ARC 체인 검증과 봉인 당사자에 대한 신뢰는 별개의 질문입니다. 암호화된 유효한 체인은 메시지를 안전하게 만들거나 모든 봉인자를 신뢰할 수 있음을 입증하지 않습니다. 누락되거나 끊어진 체인은 메시지가 위조되었음을 입증하지 못합니다.
수신자는 지역 처분 결정에 ARC 정보를 사용할 수 있습니다. ARC 기본 SPF 또는 DKIM 정렬 실패를 프로토콜 통과로 바꾸는 보편적인 규칙으로 이를 다시 작성하지 마십시오. 관찰된 인증 결과와 보고된 정책 재정의를 별도로 보존합니다. RFC 9990 DMARC 평가 필드를 원시 인증 결과와 구별하고 정책 재정의 보고에 대한 컨텍스트를 제공합니다. 수신자 수락과 인증 결과는 여전히 다른 사실입니다.
과도하게 분류하지 않고 4개의 가상 경로를 비교합니다.
보관된 문서 연습에서는 네 가지 가능성을 대조합니다: 의도된 직접 서비스; 정렬된 DKIM 유지하는 변경되지 않은 전달자; 원래 서명이 더 이상 확인되지 않는 수정 목록 알려진 인증 경로 없이 보낸 사람 도메인을 가장하는 보낸 사람. 이는 테스트된 네 가지 메시지가 아닌 설명적 대안입니다. 실제 호스트, 계정 또는 비즈니스 소유자가 할당되지 않았습니다.
처음 세 가지 가능성은 합법적으로 관찰된 트래픽으로 처리되기 전에 경로별 구성 및 메시지 증거가 필요합니다. 네 번째는 여전히 의심된다 스푸핑 사용 가능한 증거와 보안 검토가 해당 분류를 뒷받침할 때까지. 인증 실패만으로는 목록 수정 사례와 가장을 구별할 수 없습니다. 반대로, 인증을 통과해도 무해한 콘텐츠나 현재 승인된 비즈니스 목적을 설정할 수 없습니다.
수신자의 실제 신뢰 구성을 존중합니다.
마이크로소프트의 신뢰할 수 있는 ARC 실러 지침 공급자별 예입니다. Microsoft 365 수신 동작에 대해 합법적이고 필요한 중개자를 선택하는 방법을 설명합니다. 범용 허용 목록, 다른 공급자의 정책 또는 고객 테넌트 구성을 설정하지 않습니다. 이 초안은 실러를 추가하지 않으며 단지 이름이 익숙하다는 이유만으로 중개자를 신뢰하도록 권장하지 않습니다.
향후 조사를 위해 대표 메시지, 신뢰할 수 있는 수신 추적, 관련 서비스 구성 및 수신자의 예상 경로를 보관하십시오. Authentication-Results 필드는 다음과 같이 설정된 수신 신뢰 경계 내에서 해석되어야 합니다. RFC 8601 설명합니다. 신뢰할 수 없는 복사된 헤더는 무엇이든 주장할 수 있습니다. 메시지 공개, 수신자 보안 변경 및 프로덕션 DNS 작업을 자체 승인에 따라 유지하세요.
입증된 해결책을 호출하기 전에 관찰된 경로가 필요합니다.
정확한 흡입 게이트는 계속 열려 있습니다. 현재 기본 사양을 검증하고 초안 작성 전에 작업 사례를 유지합니다. 주요 소스와 허구적 비교는 유지되었지만 의뢰된 원본 증거는 아직 없습니다. 즉, 현재 공급자 증거와 통제된 테스트 메시지가 포함된 요구 사항 경로 맵이 없습니다.
최종 제어 테스트는 승인된 수신자와 경로를 사용해야 하며 관련 진단을 유지하고 전달, 인증 및 로컬 정책 처리를 구별해야 합니다. 보편적인 전달 호환성을 약속하기보다는 특정 불확실성을 해결해야 합니다. 해당 증거가 존재할 때까지 후보 분류와 다음 조사 단계를 보존합니다. 문서 사례만으로 성공적인 교정, 확인된 스푸핑 또는 승인된 발신자를 주장하지 마세요.