이메일 날짜 조작: 가능하지만 반드시 탐지된다

이메일 날짜 조작이란 정확히 무엇인가요?

시스템 관리 포럼이나 MSP Slack 그룹에서 반복적으로 등장하는 질문이 있습니다. 발송 후 이메일 날짜를 수정하는 것이 가능한가요? 짧게 답하자면, 기술적으로는 가능합니다. 하지만 불순한 목적으로 이를 시도하려는 사람에게 전체 답변은 훨씬 불편한 내용을 담고 있습니다.

이메일은 단일 파일이 아닙니다. 텍스트 헤더들의 집합에 메시지 본문이 이어지는 구조입니다. 이 헤더들 중 여러 개가 날짜 정보를 담고 있으며, 수정하기 쉬운 것과 어려운 것이 있습니다.

모든 이메일에는 세 가지 날짜 레이어가 공존합니다:

• Date: 헤더 (RFC 2822): 발송 시점에 메일 클라이언트가 기록
• Received: 헤더: 메시지를 중계한 각 서버가 추가
• IMAP INTERNALDATE: 메시지 내용과 별개로 서버 측에 저장되는 메타데이터

이 세 레이어는 모두 수정 가능합니다. 하지만 흔적을 남기지 않고 수정할 수 있는 것은 하나도 없습니다.

Date: 헤더 수정: 가장 명백한 조작

Date: 헤더는 .eml 파일의 일반 텍스트입니다. 기술적으로 어떤 헥스 에디터나 Python 스크립트로도 몇 초 만에 덮어쓸 수 있습니다. Gmail에서 이메일의 원본 헤더를 열어본 적이 있다면("원본 보기" 메뉴), 누구나 읽을 수 있는 형태라는 것을 알 것입니다.

문제는 뭘까요? 2004년 이후 대다수의 메일 서버는 발송 이메일에 DKIM(DomainKeys Identified Mail) 서명을 적용합니다. 이 암호화 서명은 Date:, From:, Subject:, 그리고 메시지 본문을 포함한 여러 헤더를 명시적으로 커버합니다. 서명은 DKIM-Signature: 헤더에 저장됩니다.

서명 후 Date:를 수정하면 DKIM 검증이 자동으로 무효화됩니다. 수신 서버는 발신 도메인의 DNS에서 공개 키를 조회해 서명을 확인할 수 있습니다. 서명이 더 이상 일치하지 않으면 메시지는 변조된 것으로 표시됩니다. Gmail, Outlook.com, 모든 주요 공급자가 이 검증을 자동으로 수행합니다.

(참고로, DKIM 서명이 실제로 어떻게 생겼는지 보고 싶다면 Gmail이나 Office 365에서 받은 이메일의 원본 헤더를 열어보세요. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=...로 시작하는 줄을 찾을 수 있는데, 노이즈처럼 보이지만 실제로는 전체 메시지의 암호화 해시입니다.)

결론: DKIM 서명된 이메일의 Date:를 수정하는 것은 봉인을 깨는 행위입니다. 방법을 아는 관리자라면 누구나 이 수정을 확인할 수 있습니다.

Received: 헤더 재작성: 위조하기 어려운 체인

Received: 헤더는 발신자에서 수신자까지 이메일이 이동한 경로를 추적합니다. 메시지를 처리하는 각 SMTP 서버는 자신의 이름, IP 주소, 타임스탬프를 담은 헤더를 하나씩 추가합니다. 두세 개의 릴레이를 거친 이메일에는 두세 개의 Received: 헤더가 쌓이게 됩니다.

수정이 가능한가요? 기술적으로, 자신이 갖고 있는 메시지 사본에 한해서는 가능합니다. 하지만 함정이 있습니다. 수신자도 사본을 갖고 있습니다. 그리고 수신자 서버가 마지막으로 자신의 Received: 헤더를 추가했습니다. 이 헤더는 발신자가 아닌 수신자의 통제 하에 있으며, 외부에서는 절대 위조할 수 없습니다.

체인의 일관성은 검증 가능합니다. 연속된 Received:의 타임스탬프가 일치하지 않으면(예를 들어 중간 릴레이가 발신자가 보내기 전에 메시지를 받았다면) 즉시 의심스럽습니다. MXToolbox 같은 이메일 포렌식 분석 도구나 보안 팀의 내부 도구가 정확히 이 부분을 확인합니다.

사실, Received: 헤더가 완전히 위조 불가능하다고 말하는 것은 정확하지 않습니다. 자체 메일 인프라를 통제하는 공격자라면 자신이 관리하는 릴레이에 대해 그럴듯한 헤더를 만들 수 있습니다. 하지만 마지막 연결 고리인 수신자 서버는 절대 통제할 수 없습니다.

IMAP INTERNALDATE: 가장 기술적인 케이스

INTERNALDATE는 서버 측에 저장되는 IMAP 메타데이터입니다. 메시지 자체의 헤더가 아니라 서버가 내부 데이터베이스에서 메시지와 연결하는 값입니다. 대부분의 메일 클라이언트가 받은 편지함에서 메시지를 정렬하는 데 사용하는 값이 바로 이것입니다.

IMAP APPEND 명령은 INTERNALDATE를 명시적으로 지정하여 서버에 메시지를 저장할 수 있습니다. RFC 3501에 문서화된 프로토콜의 정당한 기능입니다. 마이그레이션 도구들이 이를 상시 사용합니다. imapsync, BitTitan MigrationWiz, CloudM, GSMMO... 모두 INTERNALDATE를 지정하여 대상 서버에 이메일을 저장합니다.

이론적으로, 자신의 메일함에 IMAP 접근 권한이 있는 사람은 임의의 INTERNALDATE로 이메일을 저장할 수 있습니다. 하지만 이 조작은 메시지의 헤더를 변경하지 않습니다. 원본 Date:는 그대로이고, Received:도 그대로이며, DKIM 서명도 그대로입니다. 변경되는 것은 서버 측의 정렬 메타데이터뿐입니다.

원본 메시지를 검토하는 전문가에게는 INTERNALDATE와 Date: 사이의 불일치가 즉시 눈에 띕니다. 메시지에 DKIM 서명이 있다면 원본 날짜는 암호학적으로 증명됩니다.

Message-ID: 위조하기 어려운 지문

모든 이메일은 고유 식별자인 Message-ID: 헤더를 생성합니다. 이 식별자는 발신 SMTP 서버가 발송 시점에 타임스탬프, 임의 식별자, 서버 도메인 이름을 조합하여 만듭니다.

일반적인 Message-ID는 이런 형태입니다: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. 타임스탬프가 식별자에 직접 인코딩되는 경우가 많습니다. 날짜를 수정하면서 호환되지 않는 타임스탬프가 있는 Message-ID를 남기면 즉시 식별 가능한 불일치가 생깁니다.

또한 Message-ID는 주요 메시징 시스템에 의해 인덱싱됩니다. Google, Microsoft 등 주요 업체들은 메시지가 실제로 인프라를 통해 이동한 시점을 추적할 수 있는 로그를 유지합니다. 법적 또는 포렌식 맥락에서 이 로그는 법적 절차를 통해 접근 가능합니다.

실제로: 조작 시도를 누가 탐지할 수 있나요?

구체적으로 물어봅시다. 날짜가 수정되었다고 의심되는 이메일을 받았습니다. 최소한의 기술적 지식을 가진 IT 관리자나 법률 전문가는 무엇을 할 수 있을까요?

• DKIM 확인: Gmail에서 "원본 보기" 메뉴는 페이지 상단에 DKIM 검증 결과를 직접 표시합니다. "PASS"는 발송 이후 메시지 무결성을 확인합니다. "FAIL" 또는 "SOFTFAIL"은 변조를 나타냅니다.
• 헤더 분석: MXToolbox Header Analyzer나 Google Admin Toolbox 같은 도구는 Received: 체인을 자동으로 파싱하고 시간적 불일치를 표시합니다.
• Message-ID / Date 일관성: 분석가는 Message-ID에 인코딩된 타임스탬프와 선언된 Date: 값을 비교할 수 있습니다.
• 서버 로그: 이메일이 관리자 권한이 있는 서버를 거쳤다면, SMTP 로그에는 어떤 헤더와도 무관하게 메시지가 실제로 수신된 날짜와 시간이 담겨 있습니다.

탐지 도구들은 접근 가능하고, 무료이며, 고급 포렌식 전문성이 필요하지 않습니다. 호기심 있는 IT 관리자라면 2분도 안 되어 이메일의 무결성을 확인할 수 있습니다.

날짜가 대량으로 달라지는 유일한 합법적 케이스: IMAP 마이그레이션

악의적인 의도 없이 수십만 개의 이메일 날짜가 잘못되는 시나리오가 하나 있습니다. 바로 IMAP 마이그레이션입니다.

Exchange 메일함 150개를 Google Workspace로 마이그레이션하는 작업을 막 마쳤습니다. 월요일 아침, 티켓이 들어오기 시작합니다. 사용자들은 예전 이메일이 모두 마이그레이션 주말 날짜로 표시된다고 보고합니다. 받은 편지함이 읽을 수 없는 상태가 됩니다.

무슨 일이 일어났는지는 문서화되어 있고 예측 가능합니다. 마이그레이션 도구(BitTitan, CloudM, imapsync, 뭐든 간에)가 IMAP APPEND를 통해 Google Workspace에 이메일을 저장했습니다. 원본 이메일 날짜가 아닌 마이그레이션 날짜에 해당하는 INTERNALDATE를 지정했습니다. 결과적으로, 기본적으로 INTERNALDATE로 정렬하는 Outlook에서는 모든 메시지가 마이그레이션 날짜로 표시됩니다. IMAP 마이그레이션 후 이메일 날짜가 바뀌는 이유에서 이 메커니즘을 자세히 설명합니다.

각 메시지의 원본 Date: 헤더는 그대로 있습니다. DKIM 서명도 그대로입니다. 내용도 변경되지 않았습니다. 잘못된 것은 서버 측 INTERNALDATE뿐입니다.

이 문제는 BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO, INTERNALDATE를 올바르게 보존하지 않고 IMAP APPEND를 사용하는 모든 도구에서 발생합니다. BitTitan MigrationWiz 관련 전용 글에서 이 도구의 특이점을 다루고 있습니다. 이메일 마이그레이션 체크리스트에서는 이런 문제를 예방하기 위해 마이그레이션 전후로 확인해야 할 사항을 정리했습니다.

수정과 위조의 차이

Redate.io의 수정은 위조 시도와 정반대입니다. 독점 수정 엔진은 각 메시지의 헤더 체인을 분석하고, 변경된 적이 없는 Date: 헤더(RFC 2822)에 인코딩된 원본 날짜를 식별하여, 이미 메시지 안에 존재하는 이 진본 정보와 일치하도록 날짜 메타데이터를 수정합니다.

Date: 헤더가 진실의 원천입니다. 발신자의 메일 클라이언트가 발송 시점에 기록했습니다. DKIM 서명에 의해 커버됩니다. Redate.io가 수정하는 것은 이 헤더가 아닙니다. 수정하는 것은 마이그레이션 도구가 도입한 불일치이지, 원본 날짜가 아닙니다.

47,000개의 이메일을 마이그레이션 실패 후에 하나도 잃지 않고, 대화 스레드를 깨뜨리지 않고, 첨부 파일을 손상시키지 않고, 새벽 3시에 Google API에서 429 오류를 발생시키지 않으면서 수정하는 것, 이것은 엣지 케이스(S/MIME, PGP, RFC 2047 비ASCII 인코딩, 복잡한 multipart 구조)를 처리하는 다단계 분석 파이프라인입니다. 다섯 줄짜리 Python 스크립트는 첫 번째 프로덕션 메일함에서 실패합니다. 마이그레이션 후 이메일 날짜를 수정할 수 있을까요?에서 실제 볼륨에서 DIY가 위험한 이유를 자세히 설명합니다.

Redate.io는 메일함을 무료로 스캔하고 잘못된 날짜의 이메일을 식별하며, 각 메시지를 개별적으로 검증하는 검증 파이프라인을 통해 수정합니다. 원본은 30일간 볼 수 있는 백업 폴더에 보관됩니다. 문제가 생기면 롤백이 가능합니다.

마이그레이션으로 이메일 날짜가 틀어졌나요? Redate.io에서 무료 스캔을 시작하세요. 어떻게 할지 결정하기 전에 먼저 문제의 규모를 파악해 보세요.