Source: https://once-email.com/ko/blog/read-received-headers

전달 및 인증  · 2026년 8월 3일업데이트 2026년 8월 9일

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

수신된 헤더 필드를 올바른 순서로 따르고, 타임스탬프를 안전하게 비교하고, 호스트 이름, IP 주소 및 신뢰할 수 없는 추적 데이터의 한계를 인식하세요.

[Once Email 편집팀, Once Email author Once Email 편집팀](<https://once-email.com/ko/about>)

검토 Once Email 한국어 편집 검토

이 가이드로 할 수 있는 일

독자는 타임스탬프가 표시된 전달 경로를 구축하고, 그럴듯한 지연 지점을 찾아내고, 호스트 이름, 주소 및 비동기화 시계의 한계를 설명할 수 있습니다.

글 안내

이 글을 읽을 가치

**독창적 분석**

추적 방법은 신뢰할 수 있는 수신 경계에서 뒤로 홉을 읽고 신뢰할 수 없는 발신자가 조작할 수 있는 라인에서 관찰된 릴레이 증거를 분리합니다.

**동향 설명**

클라우드 릴레이, 필터링 게이트웨이 및 개인 정보 보호 프록시는 더 많은 홉과 재작성을 추가하지만 자체 추적을 추가하는 신뢰할 수 있는 각 수신자는 여전히 유용한 앵커로 남아 있습니다.

**실용적 가치**

독자는 타임스탬프가 표시된 전달 경로를 구축하고, 그럴듯한 지연 지점을 찾아내고, 호스트 이름, 주소 및 비동기화 시계의 한계를 설명할 수 있습니다.

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

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

## [수신 필드에 기록되는 내용](<https://once-email.com/ko/blog/read-received-headers#%EC%88%98%EC%8B%A0-%ED%95%84%EB%93%9C%EC%97%90-%EA%B8%B0%EB%A1%9D%EB%90%98%EB%8A%94-%EB%82%B4%EC%9A%A9>)

[RFC 5321 섹션 4.4](<https://www.rfc-editor.org/rfc/rfc5321#section-4.4>) 에는 배달을 위해 메시지를 수신하거나 추적 정보 앞에 추가 처리를 수행하는 SMTP 서버가 필요합니다. 일반적인 필드는 다음과 같습니다.

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

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

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

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

## [경로를 아래에서 위로 읽어보세요.](<https://once-email.com/ko/blog/read-received-headers#%EA%B2%BD%EB%A1%9C%EB%A5%BC-%EC%95%84%EB%9E%98%EC%97%90%EC%84%9C-%EC%9C%84%EB%A1%9C-%EC%9D%BD%EC%96%B4%EB%B3%B4%EC%84%B8%EC%9A%94>)

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 ` 서버에 전달했습니다.

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

## [지연을 신중하게 계산하세요](<https://once-email.com/ko/blog/read-received-headers#%EC%A7%80%EC%97%B0%EC%9D%84-%EC%8B%A0%EC%A4%91%ED%95%98%EA%B2%8C-%EA%B3%84%EC%82%B0%ED%95%98%EC%84%B8%EC%9A%94>)

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

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

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

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

[개발자 이메일 테스트 체크리스트](<https://once-email.com/ko/blog/email-testing-checklist>) 에서는 하나의 받은 편지함 관찰을 전체 전달 시스템으로 처리하지 않고 요청 도착 타임라인을 기록하는 방법을 설명합니다.

## [신뢰할 수 있는 홉을 결정하세요](<https://once-email.com/ko/blog/read-received-headers#%EC%8B%A0%EB%A2%B0%ED%95%A0-%EC%88%98-%EC%9E%88%EB%8A%94-%ED%99%89%EC%9D%84-%EA%B2%B0%EC%A0%95%ED%95%98%EC%84%B8%EC%9A%94>)

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

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

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

## [수신된 필드는 인증을 대체하지 않습니다.](<https://once-email.com/ko/blog/read-received-headers#%EC%88%98%EC%8B%A0%EB%90%9C-%ED%95%84%EB%93%9C%EB%8A%94-%EC%9D%B8%EC%A6%9D%EC%9D%84-%EB%8C%80%EC%B2%B4%ED%95%98%EC%A7%80-%EC%95%8A%EC%8A%B5%EB%8B%88%EB%8B%A4>)

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

인증 결과를 별도로 해석하려면 [SPF, DKIM 및 DMARC 가이드](<https://once-email.com/ko/blog/read-spf-dkim-dmarc-results>) 를 사용하세요. 보이는 ` From ` 주소가 경로의 모든 호스트를 제어하거나 친숙한 릴레이가 콘텐츠를 안전하게 만든다고 추론하지 마세요.

## [과도한 공유 없이 로컬 헤더 분석기를 사용하세요](<https://once-email.com/ko/blog/read-received-headers#%EA%B3%BC%EB%8F%84%ED%95%9C-%EA%B3%B5%EC%9C%A0-%EC%97%86%EC%9D%B4-%EB%A1%9C%EC%BB%AC-%ED%97%A4%EB%8D%94-%EB%B6%84%EC%84%9D%EA%B8%B0%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%84%B8%EC%9A%94>)

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

결과를 공유하기 전에 문제를 재현하는 데 필요한 순서와 시간 오프셋을 유지하면서 개인 주소, 공용 IP 주소, 대기열 ID 및 내부 호스트 이름을 바꾸십시오. [테스트 증거 편집 가이드](<https://once-email.com/ko/blog/safe-email-test-evidence>) \]는 보다 안전한 보고 패턴을 제공합니다.

## [신뢰할 수 있는 통역 체크리스트](<https://once-email.com/ko/blog/read-received-headers#%EC%8B%A0%EB%A2%B0%ED%95%A0-%EC%88%98-%EC%9E%88%EB%8A%94-%ED%86%B5%EC%97%AD-%EC%B2%B4%ED%81%AC%EB%A6%AC%EC%8A%A4%ED%8A%B8>)

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

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

## 관련 가이드

확인 이메일이 도착하지 않습니까? 안전한 문제 해결 체크리스트

반복적으로 코드를 요청하거나 계정 보안을 약화시키지 않고도 주소 실수, 발신자 지연, 재시도, 필터링 및 사서함 제한을 해결합니다.

[확인 이메일이 도착하지 않습니까? 안전한 문제 해결 체크리스트](<https://once-email.com/ko/blog/anxiety>)

이메일 헤더에서 SPF, DKIM 및 DMARC 결과를 읽는 방법

SPF, DKIM 및 DMARC가 인증하는 내용, 정렬이 중요한 이유, 통과 결과가 메시지가 안전하다는 증거가 아닌 유용한 증거인 이유를 이해하세요.

[이메일 헤더에서 SPF, DKIM 및 DMARC 결과를 읽는 방법](<https://once-email.com/ko/blog/read-spf-dkim-dmarc-results>)

Postfix와 Dovecot의 차이: 수신 메일 서버의 역할과 진단

Postfix, Dovecot, LMTP, 큐, IMAP의 경계를 이해하고 증거로 수신 실패 지점을 판단합니다.

[Postfix와 Dovecot의 차이: 수신 메일 서버의 역할과 진단](<https://once-email.com/ko/blog/corecomponent>)

## 개인정보 보호 중심 이메일 도구

이메일 헤더 분석기

전달 경로와 SPF, DKIM, DMARC 증거를 설명하며 절대적인 진위 여부를 단정하지 않습니다.

[이메일 헤더 분석기](<https://once-email.com/ko/tools/email-header-analyzer>)

[일부 웹사이트가 일회용 이메일 주소를 거부하는 이유 일회용 이메일 제한의 이면에 있는 계정 복구, 남용, 지원 및 위험 이유와 합법적인 사용자가 이를 회피하는 대신 무엇을 해야 하는지 이해하십시오.](<https://once-email.com/ko/blog/why-sites-reject-disposable-email>) [이메일 첨부 파일을 다운로드하기 전 안전한 체크리스트 첨부 파일을 다운로드하기 전에 요청, 보낸 사람, 파일 이름, 유형 및 처리 환경을 확인하고 이메일 미리 보기 및 스캐너가 증명할 수 없는 것이 무엇인지 알아보세요.](<https://once-email.com/ko/blog/attachment-safety-checklist>)