수신된 헤더를 읽고 이메일 전달 경로를 추적하는 방법

이메일은 받은 편지함에 도달하기 전에 애플리케이션 서버, 아웃바운드 릴레이, 필터링 서비스 및 수신자의 메일 교환기를 통과할 수 있습니다. 각 수신 SMTP 서버는 일반적으로 Received 필드를 추가합니다. 이러한 필드를 읽으면 지연을 찾고, 메일을 공급자에게 전달한 서버를 식별하고, 배달 타임라인을 구축하는 데 도움이 됩니다.

해당 필드는 완전한 관리 연속성이 아닌 진단 증거입니다. 발신자는 전송 전에 가짜 라인을 추가할 수 있고, 시계는 불일치할 수 있으며, 개인 인프라는 세부 정보를 숨기거나 다시 쓸 수 있습니다. 공급자 로그, 인증 결과 및 메시지 컨텍스트와 함께 추적을 사용합니다.

수신 필드에 기록되는 내용

RFC 5321 섹션 4.4에는 배달을 위해 메시지를 수신하거나 추적 정보 앞에 추가 처리를 수행하는 SMTP 서버가 필요합니다. 일반적인 필드는 다음과 같습니다.

Received: from outbound.example.com (outbound.example.com [192.0.2.10])
        by mx.example.net with ESMTPS id ABC123
        for <[email protected]>;
        Mon, 03 Aug 2026 10:30:04 +0000

공통절은 다양한 질문에 답합니다:

• from는 송신 측에서 제공하는 호스트를 설명하며 네트워크 연결에서 관찰된 주소를 포함할 수 있습니다.
• by는 이 홉을 수락하고 필드를 작성한 서버를 식별합니다.
• with는 ESMTP 또는 암호화된 SMTP와 같은 전송 또는 프로토콜 변형을 설명합니다.
• id는 관리자가 해당 서버의 로그를 검색할 수 있을 때 유용한 대기열 또는 트랜잭션 식별자입니다.
• for는 한 명의 봉투 수신자를 식별할 수 있지만 이는 선택 사항이며 개인 정보 보호를 위해 제거될 수 있습니다.
• 숫자 시간대 오프셋을 포함하여 수신 서버가 메시지를 수락한 세미콜론 기록 뒤의 날짜입니다.

모든 필드에 모든 절이 포함되는 것은 아닙니다. 게이트웨이 및 비 SMTP 시스템은 익숙하지 않은 형식을 생성할 수 있습니다. RFC 5321은 단지 추적선이 비정상적으로 보인다는 이유로 메시지를 거부하는 대신 예상치 못한 추적 형식을 사용하여 견고하게 수신 시스템을 유지하도록 명시적으로 지시합니다.

경로를 아래에서 위로 읽어보세요.

SMTP 서버는 기존 필드 위에 새로운 Received 필드를 추가합니다. 따라서 최신 수신 홉은 헤더 블록의 맨 위에 있습니다. 가장 먼저 기록된 홉은 일반적으로 맨 아래에 있습니다.

다음과 같은 단순화된 추적을 고려해보세요.

Received: from filter.example.net by mx.recipient.example;
        Mon, 03 Aug 2026 10:30:07 +0000
Received: from outbound.sender.example by filter.example.net;
        Mon, 03 Aug 2026 10:30:04 +0000
Received: from app.internal.example by outbound.sender.example;
        Mon, 03 Aug 2026 10:29:59 +0000

다음과 같이 읽어보세요:

1. app.internal.example가 outbound.sender.example에게 메시지를 전달했습니다.
2. 아웃바운드 서버가 이를 filter.example.net에 전달했습니다.
3. 필터는 이를 수신자의 mx.recipient.example 서버에 전달했습니다.

표시되는 타임스탬프를 기준으로 필드를 정렬하지 마세요. 서버 시계가 잘못되었거나 동기화되지 않을 수 있으므로 프로토콜 정의 필드 순서가 더 유용합니다. 지연을 추정하는 경우에만 각 타임스탬프를 하나의 시간대로 변환하고 모든 증거 기록에서 원래 값을 보존합니다.

지연을 신중하게 계산하세요

인접한 각 쌍에 대해 숫자 오프셋을 적용한 후 나중 쌍에서 이전 수신 시간을 뺍니다. 큰 양수 격차는 대기, 속도 제한, 일시적인 네트워크 오류 또는 다음 서비스 처리를 나타낼 수 있습니다. 그 자체로는 원인을 알 수 없습니다.

부정적인 격차는 일반적으로 시계 왜곡, 구문 분석 실수 또는 신뢰할 수 없는 필드를 가리키며, 시간 여행이나 자동 위조 증명이 아닙니다. 오프셋이 올바르게 처리되었는지, 제어하는 ​​시스템에서 두 줄을 기록했는지 확인하세요.

자신의 애플리케이션을 조사할 때 추적을 다음과 연관시키십시오.

• 애플리케이션이 메시지를 요청한 UTC 시간
• 발신자의 대기열 ID 및 배달 로그
• 귀하가 신뢰하는 인프라에 의해 작성된 첫 번째 Received 필드
• 수신 제공자가 이를 수락하거나 표시한다고 보고한 시간
• 전송 시스템에 의해 기록된 재시도 상태 또는 SMTP 응답.

개발자 이메일 테스트 체크리스트에서는 하나의 받은 편지함 관찰을 전체 전달 시스템으로 처리하지 않고 요청 도착 타임라인을 기록하는 방법을 설명합니다.

신뢰할 수 있는 홉을 결정하세요

최상위 Received 필드는 현재 보고 있는 사서함에 가장 가까운 서버에 의해 추가되었습니다. 해당 사서함 공급자를 신뢰할 수 있는 경우 일반적으로 이 필드가 가장 강력한 출발점이 됩니다. 공급자가 실제로 메시지를 수락한 네트워크 주소를 보고할 수 있습니다.

필드가 귀하가 인식하는 인프라와 일관되게 유지되는 한 하향 작업하세요. 신뢰할 수 있는 공급자에게 메시지가 입력되기 전에 생성된 줄은 보낸 사람이 조작할 수 있습니다. 악의적인 발신자는 일반적으로 수신자의 시스템에서 나중에 이미 추가한 필드를 다시 쓸 수 없지만 해당 시스템이 보기 전에 그럴듯해 보이는 추적 텍스트를 메시지에 배치할 수 있습니다.

호스트 이름에도 컨텍스트가 필요합니다. from 이름은 SMTP 인사말, 역방향 DNS 또는 로컬 구성에서 나올 수 있습니다. 10.0.0.0/8와 같은 개인 주소는 내부 홉을 설명할 수 있지만 공용 인터넷을 통해 직접 추적할 수는 없습니다. IP 지리적 위치 결과는 대략적인 것이며 작성자의 신원이나 물리적 위치를 설정하지 않습니다.

수신된 필드는 인증을 대체하지 않습니다.

Received 필드는 전송 홉을 설명합니다. SPF, DKIM 및 DMARC는 도메인 승인, 서명 및 정렬에 대한 다양한 증거를 평가합니다. 평범해 보이는 경로가 악성 메시지를 전달할 수 있고, 합법적으로 전달된 메시지의 경로가 복잡할 수 있습니다.

인증 결과를 별도로 해석하려면 SPF, DKIM 및 DMARC 가이드를 사용하세요. 보이는 From 주소가 경로의 모든 호스트를 제어하거나 친숙한 릴레이가 콘텐츠를 안전하게 만든다고 추론하지 마세요.

과도한 공유 없이 로컬 헤더 분석기를 사용하세요

Once Email 이메일 헤더 분석기는 Received 홉, 인증 결과 및 브라우저의 반복 필드를 추출합니다. 헤더 필드만 붙여넣으세요. 비밀번호, 확인 코드, 메시지 본문 또는 첨부 파일은 붙여넣을 수 없습니다. 이 도구는 나열된 서버에 접속하지 않으며 로그를 확인하거나 필드가 진짜인지 증명하지 않습니다.

결과를 공유하기 전에 문제를 재현하는 데 필요한 순서와 시간 오프셋을 유지하면서 개인 주소, 공용 IP 주소, 대기열 ID 및 내부 호스트 이름을 바꾸십시오. 테스트 증거 편집 가이드]는 보다 안전한 보고 패턴을 제공합니다.

신뢰할 수 있는 통역 체크리스트

상단에서 시작하여 최종 수신 시스템을 식별한 다음 하단에서 위쪽으로 경로를 재구성합니다. 시계보다 현장 순서를 신뢰하십시오. 시간대를 표준화하고, 음수이거나 비정상적으로 긴 간격을 표시하고, 신뢰할 수 있는 인프라와 발신자 제어 인프라 사이의 경계를 표시합니다. 가능한 경우 대기열 ID를 승인된 서버 로그와 연관시키십시오.

가장 중요한 것은 결론의 한계를 명시하는 것입니다. 추적은 "수신 공급자가 현재 이 릴레이에서 이 연결을 수락했습니다"를 지원할 수 있습니다. 일반적으로 누가 메시지를 작성했는지, 모든 이전 홉이 진짜인지 또는 해당 링크와 첨부 파일이 안전한지 여부를 증명할 수 없습니다.