.eml 파일을 분석합니다. 헤더, Received 경로, 링크, 첨부 파일 해시, 발신자 불일치를 보여 줍니다.
신규
이메일 헤더 분석기
로컬에서 실행
도구 자체는 영어로 되어 있지만, 이 페이지에서는 귀하의 언어로 설명해 드립니다.
이메일 헤더 분석기을(를) 사용하세요
기능
의심스러운 메시지의 원본 헤더를 붙여넣으면 ‘From’, ‘To’, ‘Date’, ‘Subject’ 정보와 수신 서버가 기록한 SPF, DKIM, DMARC 결과, 가장 오래된 순서대로 나열된 모든 ‘Received’ 홉, 그리고 ‘Reply-To’와 ‘Return-Path’를 포함한 전체 헤더 표를 확인할 수 있습니다.
이 서비스는 전적으로 브라우저에서 실행되며, 사용자가 입력한 내용은 전혀 업로드되지 않습니다.
이메일 헤더 분석기 사용 방법
- 헤더 복사. 메시지 원본을 열고(Gmail의 Show original, Outlook의 View message source, Thunderbird의 View source) 첫 번째 빈 줄까지의 헤더 줄을 복사합니다.
- 붙여 넣고 분석. 이 내용을 ‘Raw’ 이메일 헤더에 붙여넣고 ‘Parse’를 누르세요. 본문도 함께 붙여넣으면 파서가 첫 번째 빈 줄에서 멈추고, 읽지 못한 줄의 수를 알려줍니다.
- 상단 필드 읽기. From, To, Date가 먼저 나오고, Subject가 있으면 그다음에 나옵니다. 값은 디코딩하지 않고 쓰인 그대로 표시됩니다.
- 인증 결과를 확인하세요. SPF, DKIM 및 DMARC는 수신 서버가 가장 상단의 Authentication-Results 헤더에 기록한 결과와 해당 서버의 이름을 표시합니다. 이 항목들은 여기서 다시 확인되지 않습니다.
- 홉의 흔적을 따라가 보세요. 수신된 홉은 EML Analyzer와 마찬가지로 가장 오래된 순서대로 나열됩니다. 홉 1은 발신자와 가장 가까운 홉이며, 마지막 홉은 메시지를 귀하에게 전달한 서버에 의해 추가된 것입니다.
- 전체 표를 스캔하세요. 'All headers'는 Reply-To 및 Return-Path를 포함한 모든 헤더를 나열합니다. 'Send to'는 구문 분석된 결과를, 예를 들어 EML Analyzer와 같은 프로그램으로 전달합니다.
예시
은행을 사칭한 알림
Return-Path: <bounce@mailer.example.net>
Received: from mail.example.net (mail.example.net [203.0.113.25])
by mx.example.com with ESMTPS id 4Xk2Lm; Mon, 19 Oct 2026 09:14:07 +0000
Received: from [198.51.100.10] (unknown [198.51.100.10])
by mail.example.net with ESMTPSA id 77QaZ1; Mon, 19 Oct 2026 09:14:05 +0000
Authentication-Results: mx.example.com; spf=pass smtp.mailfrom=mailer.example.net; dkim=none; dmarc=fail (p=reject) header.from=example.org
From: "Example Bank Security" <security@example.org>
Reply-To: <help-desk@example.net>
To: <alice@example.com>
Subject: Action required: verify your account
Date: Mon, 19 Oct 2026 09:14:03 +0000
Message-ID: <20261019091403.1234@mail.example.net>FROM
"Example Bank Security" <security@example.org>
TO
<alice@example.com>
DATE
Mon, 19 Oct 2026 09:14:03 +0000
SUBJECT
Action required: verify your account
Authentication-Results by mx.example.com (as written by that server, not verified here)
SPF
pass
DKIM
none
DMARC
fail
Received hops (2, oldest first)
HOP 1 · OLDEST, NEAREST THE SENDER
from [198.51.100.10] (unknown [198.51.100.10]) by mail.example.net with ESMTPSA id 77QaZ1; Mon, 19 Oct 2026 09:14:05 +0000
HOP 2 · NEWEST, ADDED BY THE RECEIVING SERVER
from mail.example.net (mail.example.net [203.0.113.25]) by mx.example.com with ESMTPS id 4Xk2Lm; Mon, 19 Oct 2026 09:14:07 +0000
All headers (10)
Return-Path <bounce@mailer.example.net>
Received from mail.example.net (mail.example.net [203.0.113.25]) by mx.example.com with ESMTPS id 4Xk2Lm; Mon, 19 Oct 2026 09:14:07 +0000
Received from [198.51.100.10] (unknown [198.51.100.10]) by mail.example.net with ESMTPSA id 77QaZ1; Mon, 19 Oct 2026 09:14:05 +0000
Authentication-Results mx.example.com; spf=pass smtp.mailfrom=mailer.example.net; dkim=none; dmarc=fail (p=reject) header.from=example.org
From "Example Bank Security" <security@example.org>
Reply-To <help-desk@example.net>
To <alice@example.com>
Subject Action required: verify your account
Date Mon, 19 Oct 2026 09:14:03 +0000
Message-ID <20261019091403.1234@mail.example.net>맨 위 필드에는 ‘보낸 사람’의 표시 이름과 주소가 표시되며, 그 다음에는 수신 서버가 기록한 인증 결과(spf=pass, dkim=none, dmarc=fail)와 두 개의 ‘Received’ 홉이 EML Analyzer와 마찬가지로 가장 오래된 순서대로 나열됩니다: 1단계(Hop 1)에서 mail.example.net은 198.51.100.10으로부터 메시지를 수신하고, 2단계(Hop 2)에서 mx.example.com은 mail.example.net으로부터 메시지를 수신합니다. 10개의 헤더 전체를 보여주는 표에는 다른 도메인의 'Reply-To'가 표시되어 있습니다. 여기에 dmarc=fail까지 더해지면, 이는 발신자가 스푸핑되었음을 나타내는 두 가지 징후입니다.
검증 대상
| 신호 | 그 의미는 무엇인가 |
|---|---|
| From | 표시 이름과 꺾쇠괄호 안의 주소를 비교하세요. 브랜드 이름 옆에 관련 없는 도메인이 있다면 흔한 사칭 징후입니다. |
| To | 본인 주소가 없다면 숨은 참조(Bcc)나 메일링 리스트로 받았을 가능성이 높습니다. 대량 피싱은 Bcc를 자주 사용합니다. |
| Date | 발신자의 소프트웨어가 쓰는 값이므로 위조될 수 있습니다. Received 홉의 시각과 비교하세요. |
| Subject | 원본 그대로 표시됩니다. =?UTF-8?B?...?= 같은 값은 인코딩된 텍스트이며, 이 분석기는 디코딩하지 않습니다. |
| SPF, DKIM, DMARC | 수신 서버의 판정 결과. 특정 브랜드 도메인에 대해 dmarc=fail이 표시되면 이는 스푸핑의 확실한 징후이며, 보고되지 않았다는 것은 해당 검사에 대한 결과를 서버가 기록하지 않았음을 의미합니다. |
| 수령한 홉 | 각 홉은 200자씩 잘려 있습니다. 목록의 맨 끝에 있는, 본인의 제공자가 추가한 홉만 신뢰할 수 있으며, 그 이전의 홉은 위조되었을 가능성이 있습니다. |
| 답장 주소 | 'From'과 다른 도메인의 회신 주소가 지정되어 있으면, 귀하의 답장이 다른 곳으로 전송됩니다. |
| Return-Path | SPF가 확인하는 반송 주소입니다. 메일 서비스의 경우 ‘From’ 필드와 도메인이 다른 것이 일반적이지만, 이 점은 유의할 필요가 있습니다. |
| Message-ID | @ 뒤 부분에는 메시지를 만든 시스템의 이름이 나오는 경우가 많습니다. From 도메인과 비교하세요. |
더 많은 예시
인코딩된 발신자 이름과 제목
Received: from mail.example.org (mail.example.org [192.0.2.44])
by mx.example.com with ESMTPS; Tue, 20 Oct 2026 10:02:11 +0000
From: =?UTF-8?B?UGF5cm9sbCBUZWFt?= <payroll@example.org>
To: staff@example.com
Subject: =?UTF-8?B?U2FsYXJ5IHVwZGF0ZQ==?=
Date: Tue, 20 Oct 2026 10:02:09 +0000보낸 사람, 받는 사람, 날짜 및 제목은 입력되어 있지만, 이름과 제목은 아무것도 디코딩되지 않아 =?UTF-8?B?...?=로 표시됩니다(실제로는 ‘Payroll Team’과 ‘Salary update’로 읽힙니다). ‘수신 홉’에는 접힌 홉이 한 줄로 나열되고, ‘모든 헤더’에는 모든 헤더가 나열됩니다.
헤더와 함께 붙여 넣은 본문
From: IT Support <it@example.net>
To: you@example.com
Subject: Password expires
Hello,
Action needed: confirm your password today.첫 번째 빈 줄 이전의 줄들만 헤더로 인식됩니다. 표 아래의 주석에 따르면, 그 이후의 줄들, 즉 메시지 본문은 헤더로 인식되지 않았습니다.
여러 줄로 접힌 Subject 줄
From: Example Shop <orders@example.com>
Subject: Your order
has shippedFrom에는 Example Shop과 주소 orders@example.com이, To와 Date에는 대시가 표시되고, Subject는 한 줄로 "Your order has shipped"가 됩니다. Received hops (0), All headers (2).
자주 묻는 질문
Received 홉은 어떻게 읽나요?
EML Analyzer에서와 마찬가지로 홉은 가장 오래된 것부터 순서대로 번호가 매겨집니다. 홉 1은 메시지를 처음 처리한 서버가 추가한 가장 하단의 ‘Received’ 헤더이며, 마지막 홉은 메시지를 귀하에게 전달한 서버가 추가한 가장 상단의 헤더입니다. 발신자가 그 아래에 있는 Received 줄을 위조할 수 있으므로, 사용자 본인의 메일 제공자가 추가한 홉만 신뢰할 수 있습니다.
SPF, DKIM, DMARC를 검사하나요?
아닙니다. 이 기능은 최상위 Authentication-Results 헤더의 SPF, DKIM 및 DMARC 결과를 표시하며, 수신 서버가 기록한 그대로 Received-SPF 및 DKIM-Signature를 나열할 뿐, 어떠한 검증도 수행하지 않고 =?UTF-8?B?...?= 수신자 이름을 디코딩하거나 본문을 읽지 않습니다(첫 번째 빈 줄에서 중단됨). 또한 긴 값은 축약됩니다(홉 수는 200자, 표 셀은 300자로 제한됨). 전체 .eml 파일을 확인하려면 EML Analyzer를 사용하십시오.
헤더가 업로드되나요?
아니요. 분석은 브라우저에서 이루어지며 아무것도 전송되지 않습니다. 헤더에는 개인 주소와 내부 IP가 들어 있을 수 있으므로 공유하기 전에 제거하세요.
본문을 포함한 메시지 전체를 붙여 넣어도 되나요?
네, 하지만 헤더 블록만 읽힙니다. RFC 5322에 정의된 대로 첫 번째 빈 줄에서 구문 분석이 중단되며, 해당 페이지에는 건너뛴 본문 줄 수가 표시됩니다. EML Analyzer는 첨부 파일을 포함하여 전체 메시지를 읽습니다.
여러 줄로 접힌 헤더 줄은 어떻게 처리되나요?
공백이나 탭으로 시작하는 줄은 공백 하나와 함께 위의 헤더에 이어 붙여지므로, 긴 Received나 Subject 헤더도 하나의 값으로 표시됩니다.
어떤 Authentication-Results 헤더가 사용됩니까?
가장 상단에 있는 헤더는, 귀하에게 메시지를 전달한 서버가 가장 마지막에 추가한 것입니다. 그 아래에 있는 Authentication-Results 헤더들은 이전 서버에서 온 것일 수도 있고, 발신자가 위조한 것일 수도 있습니다.