모든 이메일에는 숨겨진 기술적 이력이 담겨 있다 — 메일 클라이언트가 평소에는 감춰 두지만, 메시지가 어떤 서버를 거쳐 왔는지, 그리고 발신자가 실제로 자신이 주장하는 사람이 맞는지를 정직하게 기록하는 헤더들이다.
제목이 "=?UTF-8?B?...?="처럼 보이는 이유
이메일 헤더는 수십 년 전 7비트 ASCII만을 전제로 설계되었기 때문에, "내일 회의 안건 공유드립니다" 같은 한글 제목은 헤더에 그대로 쓸 수 없다. RFC 2047은 이를 "인코딩된 단어(encoded word)" 문법으로 해결한다: =?UTF-8?B?7Jyu7J2867O07IucIOyViOydvA==?= 형태로, 먼저 문자셋(UTF-8)을 쓰고, Base64면 B, quoted-printable이면 Q를 넣은 뒤 인코딩된 바이트가 이어진다. 한글은 한 글자가 UTF-8에서 3바이트를 차지하기 때문에, 짧은 한글 제목도 인코딩하면 원문보다 훨씬 긴 문자열이 되며, 이것이 원본 헤더를 열었을 때 알아볼 수 없는 문자열처럼 보이는 이유다.
Received 헤더: 메시지 경로 지도
메시지가 거치는 각 메일 서버는 자신의 Received 헤더를 목록 맨 위에 추가한다 — 그래서 발신자부터 받은편지함까지 실제로 거쳐온 경로를 추적하려면, 헤더가 추가된 순서와 정반대로 아래에서 위로 읽어야 한다.
SPF, DKIM, DMARC: 세 가지 독립적인 신뢰 검증
SPF(Sender Policy Framework)는 도메인을 대신해 메일을 보낼 수 있는 서버 목록을 담은 DNS 레코드이며, Received-SPF 헤더는 발신 서버가 그 목록에 있었는지를 보여준다. DKIM은 메시지에 암호 서명을 추가해 발신자 DNS에 공개된 공개 키로 검증할 수 있게 하며, 전송 중 내용이 변조되지 않았음을 증명한다. DMARC는 SPF나 DKIM을 통과하지 못한 메일을 수신 서버가 어떻게 처리할지 지시한다 — 거부, 스팸 처리, 또는 경고와 함께 전달. 은행이나 택배사를 사칭한 피싱 메일에서는 이 세 검증 중 하나 이상이 실패하는 경우가 대부분이다.
이 도구가 유용한 상황
- 의심스러운 이메일이 발신자를 위조한 피싱 시도인지 확인할 때.
=?UTF-8?B?...?=같은 읽을 수 없는 문자열로 도착한 제목이나 발신자 이름을 디코딩할 때.- 내가 보낸 이메일이 왜 수신자의 스팸함으로 분류되는지 진단할 때.
Message-ID의 역할
Message-ID 헤더는 메일 클라이언트가 발송 시 부여하는 고유 식별자로, 이론상 전 세계 어떤 이메일에서도 중복되지 않는다. 대화를 "스레드"로 묶는 데 핵심적인 역할을 하는데, 메시지에 답장할 때 클라이언트가 원본 Message-ID를 In-Reply-To 헤더에 복사하고, 바로 이 연결 고리 덕분에 메일 서비스가 개별 메시지가 아닌 하나의 대화로 묶어 표시할 수 있다.