search
홈
네트워크
경로 추적내 공개 IP블랙리스트 검사기서브넷 계산기이메일 헤더cURL 변환기DNS 조회HTTP 헤더IP 지리적 위치IPv4에서 IPv6로MAC OUI 조회PingSPF, DKIM, DMARCSSL 인증서Whois 조회
변환
날짜 및 시간데이터 형식색상숫자 진법저장 용량 단위지리 참조 파일 변환기chmod 권한cron 표현식cURL 변환기IPv4에서 IPv6로JSON을 모델로PHP ↔ JSONSVG → CSS
암호화
대칭 암호화비대칭 암호화비밀 공유비밀번호 생성기해시 함수JSON 웹 토큰(JWT)SSL 인증서UUID 생성기WordPress
이미지
색상 추출기압축기이미지를 Base64로크기 조정 및 자르기형식 변환기BlurHash 및 LQIPEXIF 메타데이터favicon 생성기OCR: 이미지·PDF를 텍스트로SVG → PNG / JPG
인코딩
백슬래시 이스케이프 / 언이스케이프Base64 문자열Base64 이미지HTML 엔티티SVG → CSSURL 인코딩 / 디코딩URL 파서
지도
내 공개 IP지도 편집기지리 참조 파일 변환기IP 지리적 위치
참조
ASCII 표chmod 권한cron 표현식DNS 레코드HTML 엔티티HTTP 상태 코드MAC OUI 조회MIME 유형PCI 식별자(공급업체/장치)TCP 및 UDP 포트USB 식별자(VID/PID)
코드 포맷팅
최소화CSS / SCSS / LESSHTMLJavaScript / TSJS/TS 난독화JSONSQLXML
텍스트
글자 수 세기정규 표현식텍스트 비교기텍스트 스타일 변환기텍스트 클리너ASCII 아트 생성기Lorem Ipsum 생성기OCR: 이미지·PDF를 텍스트로
하드웨어 및 기기
마우스 테스트마이크 및 스피커 테스트블루투스(BLE) 스캐너센서 테스트스크린 테스트장치 정보카메라 테스트키보드 테스트파워 서플라이 및 UPS 소비 전력NFC 리더 및 라이터PCI 식별자(공급업체/장치)RAID 계산기USB 식별자(VID/PID)WebUSB 검사기
QR 및 바코드
리더바코드 생성기QR 생성기
약관·개인정보
Scientia

이메일 헤더 분석기

IT Tools
forward_to_inbox메시지 헤더
info_outline
메일 헤더를 붙여 넣으면 어떤 서버를 거쳤고 각 서버에서 얼마나 걸렸는지, SPF·DKIM·DMARC 결과가 어떤지, 다른 도메인의 Reply-To 같은 위조 징후가 있는지 확인할 수 있습니다. 분석은 브라우저에서 이루어지며 헤더는 어떤 서버로도 전송되지 않습니다.
Gmail: ⋮ → 원본 보기. Outlook: 파일 → 속성 → 인터넷 헤더.

작동 방식

메일을 처리한 서버는 이전 헤더들 위에 자신의 이름, 메시지를 넘겨준 서버의 이름, 프로토콜, 시각을 담은 Received 헤더를 추가합니다. 아래에서 위로 읽으면 메시지를 만든 애플리케이션부터 내 메일함까지의 전체 여정을 알 수 있습니다. 분석기는 이를 순서대로 정렬하고 모든 시각을 같은 시간대로 맞춘 뒤 각 홉에 걸린 시간을 계산합니다. 메일이 어디서 지연됐는지 알아내는 가장 직접적인 방법입니다.

또한 메시지를 받은 서버가 SPF·DKIM·DMARC 결과를 기록하는 Authentication-Results 헤더를 읽고, 보이는 발신자, Return-Path, Reply-To, DKIM 서명의 도메인을 비교합니다. 발송 플랫폼은 자체 도메인으로 서명하므로 불일치가 항상 나쁜 것은 아니지만, 다른 도메인의 Reply-To는 피싱의 가장 흔한 징후 중 하나입니다.

헤더에는 주소, 내부 IP, 조직의 서버 이름이 들어 있을 수 있습니다. 그래서 분석은 전부 브라우저에서 이루어지며, 붙여 넣은 텍스트는 공유 링크에 저장되지 않습니다.

예시

=?UTF-8?B?Q29uZmlybWFjacOzbiBkZSBwZWRpZG8gIzEwMjQ=?=Confirmación de pedido #1024RFC 2047에 따른 인코딩된 단어입니다. 헤더는 ASCII만 허용하므로, ASCII가 아닌 문자가 든 제목은 Base64(B)나 quoted-printable(Q)로 전송되고 메일 클라이언트가 이를 디코딩합니다.
with ESMTPSAESMTP + TLS + AUTHwith 절은 해당 홉의 프로토콜을 나타냅니다(RFC 3848). 끝의 S는 연결이 TLS로 암호화됐다는 뜻이고, A는 클라이언트가 인증했다는 뜻입니다. 공개 서버 사이에서 S가 없는 SMTP라면 그 구간은 평문으로 전송된 것입니다.
13:21:12 +0000 → 10:22:39 -0300+87 s각 서버는 자기 시간대로 시각을 기록합니다. 빼기 전에 모두 UTC로 바꿔야 합니다. UTC−3의 10:22:39는 13:22:39 UTC로, 이전 홉보다 87초 뒤입니다.

활용 사례

  • 몇 시간 늦게 도착한 메일이 어느 서버에서 지연됐는지 알아내기.
  • 클릭하기 전에 의심스러운 메시지 확인하기: 실제 발신자, SPF·DKIM·DMARC 통과 여부, 답장이 갈 곳.
  • 발송 플랫폼 설정 후 내 도메인의 메일이 DKIM 서명과 DMARC 정렬을 갖춰 나가는지 확인하기.
  • 메일을 배달한 서버의 IP를 찾아 블랙리스트를 조회하거나 악용을 신고하기.
  • 경로 중 암호화되지 않은 구간이 있었는지 확인하기.
  • 시스템이 =?UTF-8?B?…?=로 보여 주는 인코딩된 제목과 이름 읽기.

자주 묻는 질문

메일의 전체 헤더는 어떻게 복사하나요?

Gmail에서는 메시지를 열고 점 세 개 메뉴에서 "원본 보기"를 선택하세요. 데스크톱 Outlook에서는 메시지를 열고 파일 → 속성 → 인터넷 헤더로 이동하고, 웹용 Outlook에서는 메시지 메뉴에서 "메시지 세부 정보 보기"를 찾으세요. Apple Mail에서는 보기 → 메시지 → 모든 헤더입니다. 본문 위의 블록 전체를 복사해 여기에 붙여 넣으세요.

Received 헤더를 위조할 수 있나요?

내 공급자의 서버가 추가한 헤더, 즉 가장 위쪽의 헤더는 신뢰할 수 있습니다. 아래쪽은 메시지를 보낸 사람이나 내가 통제하지 못하는 서버가 쓴 것이라 공격자가 혼란을 주려고 지어낼 수 있습니다. 그래서 신뢰할 수 있는 첫 홉은 내 공급자가 처음 받은 홉이며, 거기에 적힌 IP가 실제로 메일을 배달한 IP입니다.

SPF는 통과했는데 DMARC가 실패하면 무슨 뜻인가요?

SPF는 사용자에게 보이지 않는 Return-Path 도메인을 검증하지만, DMARC는 그 도메인이나 DKIM 서명 도메인이 보이는 발신자와 일치하도록 요구합니다. 플랫폼이 자체 Return-Path로 보내면서 내 도메인으로 서명하지 않으면, SPF는 플랫폼 기준으로 통과하지만 내 도메인과 정렬되지 않아 DMARC가 실패합니다. 보통은 그 플랫폼에서 내 도메인으로 DKIM을 설정해 해결합니다.

왜 어떤 홉의 시각이 이전 홉보다 이른가요?

서버마다 자기 시계를 쓰는데, NTP로 동기화되지 않은 서버가 있으면 시각이 맞지 않기 때문입니다. 몇 초 차이는 정상이지만, 음수의 분이나 시간이 보이면 그 서버의 시계가 틀린 것이므로 그 구간의 지연은 믿을 수 없습니다.

업무 메일의 헤더를 여기 붙여 넣어도 안전한가요?

분석은 브라우저에서 이루어지며 텍스트는 어떤 서버로도 전송되지 않고 공유 링크에도 저장되지 않습니다. 그래도 헤더에는 조직의 내부 IP, 서버 이름, 주소가 드러날 수 있으니 다른 사람과 공유할 때는 주의하세요.

관련 항목

  • 도메인의 SPF, DKIM, DMARC 확인
  • IP를 블랙리스트에서 조회
  • 서버 IP의 위치 확인
  • Base64 텍스트 디코딩