이메일 헤더 분석
RFC 5322 연속 라인 펼치기, From/To/Subject/Date/Message-ID 추출, 모든 Received 라인 파싱(시간 순으로 역배열)·인접 홉 간 실시간 지연 계산, Authentication-Results에서 spf/dkim/dmarc 결과 추출. 메일이 왜 스팸 처리됐는지 진단·위조된 Received 체인 발견·어느 MTA가 지연 일으켰는지 특정에 유용.
- 보낸이"Alice Sender" <alice@example.com>
- 받는이user@recipient.com
- 제목Hello there
- 날짜Mon, 02 Jun 2026 09:15:38 +0000
- Message-ID<abc123@example.com>
- #1from sender-host.example.com → by mail.example.comMon, 02 Jun 2026 09:15:40 +0000 (UTC)
- #2+2sfrom mail.example.com → by mx.recipient.comMon, 02 Jun 2026 09:15:42 +0000 (UTC)
모든 처리는 로컬 — 헤더가 브라우저를 떠나지 않음.
사용법
- 원본 헤더 전체 붙여넣기 (헤더와 본문 구분하는 빈 줄 이전 전부).
- 메타데이터 블록·인증 뱃지·홉 목록 확인.
자주 묻는 질문
- 원본 헤더는 어디서 얻음?
- Gmail: 메일의 ⋮ 메뉴 → "원본 보기". Outlook: 파일 → 속성 → 인터넷 헤더. 대부분의 다른 클라이언트도 "소스 보기" 또는 "원본 보기" 옵션 있음.
- 홉 지연이 가끔 음수로 나오는 이유?
- 서버 간 시계가 몇 초 어긋나는 경우 흔하고, 일부 MTA는 Received 라인을 소급 기록. 작은 음수는 정상; 큰 음수(또는 홉 누락)는 위조된 헤더 가능성.
- Received 체인은 어디까지 믿을 수 있나?
- 내가 통제하는 인프라가 붙인 부분까지만이다. 각 서버는 메시지를 받을 때 자기 줄을 맨 앞에 덧붙이므로, 신뢰할 수 있는 첫 홉보다 위에 있는 것은 내가 운영하지 않는 기계가 쓴 것이고 통째로 조작될 수 있다. 체인은 내 쪽에서 바깥으로 읽고, 가장 이른 홉들은 증거가 아니라 주장으로 취급하라.
- SPF를 통과했는데도 명백한 스팸인 이유는?
- SPF는 봉투 발신자의 도메인을 보내는 서버 주소와 대조할 뿐이고, 그 도메인이 수신자에게 보이는 도메인일 필요는 없다. 자기 소유의 도메인으로 SPF를 통과시키면서 화면에는 남을 흉내 낸 From 주소를 띄울 수 있다. 보이는 From이 실제로 인증된 SPF나 DKIM과 일치하도록 요구하기 위해 존재하는 것이 DMARC다.
관련 도구
SPF 레코드 빌더
메커니즘·IP·include로 SPF TXT 레코드 작성, 실시간 DNS 조회 카운트와 경고.
TXT 레코드 분할기 (255바이트 청크)
긴 SPF·DKIM·DMARC TXT 레코드를 DNS 프로토콜이 요구하는 255바이트 청크로 분할 — BIND·일반 zone 파일·Cloudflare·Route 53 문법 출력.
DKIM 레코드 빌더 & 파서
DKIM(DomainKeys Identified Mail) DNS TXT 레코드를 만들거나 분석 — 공개키 붙여넣고 selector·키 타입(RSA/Ed25519)·해시·플래그 설정 → 전체 레코드 + `selector._domainkey` 호스트명 + 255자 초과 시 DNS 청크 버전까지.
DMARC 레코드 빌더
`_dmarc` TXT 레코드 작성 — 정책·서브도메인 정책·퍼센트 롤아웃·정렬·rua/ruf 리포팅 — 안전 경고 포함.
mailto: 링크 빌더
받는사람·참조·숨은참조·제목·본문을 입력해서 RFC 6068 규격으로 퍼센트 인코딩된 mailto: URL을 만듭니다. <a> 태그에 바로 붙여서 쓸 수 있습니다.
Cache-Control 헤더 빌더
체크리스트로 HTTP Cache-Control 헤더 생성 — 프레시니스·재검증·immutable·자주 쓰는 프리셋.