짧게 답하자면: 아닙니다. 이메일 읽음 확인은 주요 이메일 클라이언트 어디에서도 안정적으로 작동하지 않습니다. 모든 이메일 추적 도구가 대안으로 내세우는 픽셀 추적도 마찬가지입니다. 이 글에서는 무엇이, 왜 작동하지 않는지, 그리고 실제로 원하는 데이터를 얻으려면 어떻게 해야 하는지를 구체적으로 다룹니다.
이메일 읽음 확인의 작동 원리
메커니즘 자체는 단순하며, RFC 8098이 발표된 이후로 변한 것이 없습니다. 발신자의 이메일 클라이언트가 발송 메시지에 Disposition-Notification-To 헤더를 추가합니다. 수신자의 이메일 클라이언트가 이 헤더를 인식하면 수신자에게 확인 여부를 묻고, 수신자가 동의하면 발신자에게 수신 확인 알림을 보냅니다.
사양서는 이를 명확히 밝히고 있습니다. 읽음 확인 요청은 "완전히 선택 사항"입니다. 수신자는 언제든지 거부할 수 있으며, 발신자는 그 사실조차 알 수 없습니다. 폴백도 없고, 재시도도 없으며, 자동 확인도 없습니다. 수신자가 거부하거나 이메일 클라이언트가 요청을 무시하면, 발신자는 아무것도 받지 못합니다.
Gmail 읽음 확인 — 전체 그림
개인 Gmail 계정
지원되지 않습니다. 작성 창에 해당 옵션이 없고, 숨겨진 설정도 없으며, Labs 확장 기능도 없습니다. Google이 이 기능을 추가할 계획이라는 징후도 없습니다. 무료 Gmail 계정에서는 읽음 확인을 요청할 수 없습니다.
Mailtrack이나 Streak 같은 서드파티 확장 프로그램은 기본 읽음 확인을 사용하지 않습니다 — 픽셀 추적을 사용하며, 이 역시 고유한 문제를 안고 있습니다(아래에서 설명).
Google Workspace 계정
읽음 확인은 기본적으로 비활성화되어 있습니다. 관리자가 Admin Console → 앱 → Google Workspace → Gmail → 사용자 설정 → 이메일 읽음 확인을 통해 명시적으로 활성화해야 합니다.
구성 단계는 네 가지입니다:
- 완전 비활성화 (기본값)
- 내부 전용 — 같은 조직 내에서만 읽음 확인 작동
- 내부 + 허용 목록 — 내부, 플러스 최대 100개의 특정 외부 주소
- 모든 이메일 주소 — 모든 수신자에게 요청 가능하지만, 수신자는 항상 확인 여부를 선택할 수 있음
활성화된 경우, 데스크톱에서의 사용 방법은 다음과 같습니다:
- 웹에서 Gmail 열기(데스크톱 전용 — iOS 또는 Android의 Gmail 모바일에서는 사용 불가)
- 새 이메일 작성
- 작성 창 하단의 점 세 개 "더보기" 메뉴 클릭
- "읽음 확인 요청" 선택
- 이메일 발송
수신자에게는 "영수증 보내기" 또는 "나중에"가 표시됩니다. "나중에"를 선택하면 다음에 이메일을 열 때 다시 묻습니다. 발신자는 요청이 거부되었다는 사실을 결코 알 수 없습니다.
읽음 확인은 메시지마다 개별 설정해야 합니다 — 전역 기본값이 없습니다. BCC나 메일링 리스트에서는 작동하지 않습니다. 이미 발송된 이메일에는 읽음 확인 요청을 추가할 수 없습니다.
모든 것이 정상적으로 작동하는 경우에도 — 관리자가 읽음 확인을 활성화하고, 요청을 잊지 않고, 수신자가 수락하더라도 — 알 수 있는 것은 이메일이 열렸다는 사실뿐입니다. 첨부 파일을 열었는지, 얼마나 읽었는지, 어떤 부분에 관심을 가졌는지는 알 수 없습니다.
Outlook 읽음 확인 — 2025년 모바일 지원 추가 포함
Outlook은 주요 이메일 클라이언트 중 읽음 확인 구현이 가장 풍부합니다. 동시에 가장 파편화되어 있기도 합니다.
Windows용 Classic Outlook
가장 완전한 경험을 제공합니다. 메시지별로 읽음 확인을 요청하거나 전역 기본값을 설정할 수 있습니다(옵션 → 추적 → "보낸 모든 메시지에 대해 읽음 확인 요청"). 관리자는 그룹 정책 및 Exchange 규칙을 통해 읽음 확인 처리를 자동화할 수 있습니다.
Windows용 New Outlook 및 웹용 Outlook(OWA)
메시지별 읽음 확인은 작동합니다. 하지만 전역 기본값 설정이 사라졌습니다 — Classic에서 광범위하게 보고된 기능 퇴행입니다. 매번 읽음 확인을 직접 요청해야 합니다.
Outlook 모바일(iOS/Android)
2025년 봄부터 Outlook 모바일이 읽음 확인과 배달 확인을 모두 지원합니다. 메시지 작성 → "+" 메뉴 탭 → 수신 확인 아이콘 선택 → 유형 선택. 최근에 추가된 기능으로, 대부분의 다른 글에서는 여전히 모바일에서 지원되지 않는다고 설명하고 있습니다.
읽음 확인 vs. 배달 확인
많은 사람들이 이 둘을 혼동합니다. 근본적으로 다릅니다:
- 배달 확인(DSN) 은 서버 측입니다. 메일 서버가 메시지가 수신자의 받은 편지함에 도달했음을 확인합니다. 수신자 개입이 필요 없습니다.
- 읽음 확인(MDN) 은 클라이언트 측입니다. 수신자의 이메일 앱이 메시지를 열었을 때 발동하며, 수신자는 언제든지 거부할 수 있습니다.
배달 확인은 이메일이 도착했음을 알려줍니다. 읽음 확인은 열렸음을 알려줍니다. 두 가지 모두 내용물에 대해서는 아무것도 알려주지 않습니다.
관리자 제어
테넌트 전체에 적용되는 단일 차단 스위치는 없습니다. 기업 IT 팀은 일반적으로 여러 방법을 조합합니다:
- Exchange 전송 규칙 —
Disposition-Notification-To헤더를 제거하는 것이 가장 효과적인 포괄적 접근 방식 - Set-MailboxMessageConfiguration — OWA 설정용
- 그룹 정책 — Classic 데스크톱용
- 원격 도메인 설정 — 외부 발신자 처리용
전송 규칙 방식은 조직 전체의 자동 거부에 가장 가까운 방법으로, 많은 기업 IT 팀이 실제로 이를 사용합니다. 수신자 조직이 서버 수준에서 읽음 확인 헤더를 제거하면, 요청은 아무도 보기 전에 자동으로 폐기됩니다.
결론은 Gmail과 같습니다: 최선의 경우에도, 이메일이 열렸다는 사실만 알 수 있습니다. 콘텐츠에 대해서는 아무것도 알 수 없습니다.
Apple Mail — 반전
Apple Mail은 읽음 확인을 요청하는 기능을 지원하지 않습니다. 하지만 진짜 이야기는 다른 사람의 추적에 무슨 일을 하는지에 있습니다.
Mail Privacy Protection(MPP)
2021년 9월 iOS 15 및 macOS Monterey와 함께 도입된 Mail Privacy Protection은 사용자가 실제로 이메일을 열었는지 여부와 관계없이 모든 이메일 콘텐츠를 백그라운드에서 미리 가져옵니다. 이미지가 로드되고, 추적 픽셀이 실행되며, 발신자는 거짓 "열림" 신호를 받습니다.
트래픽은 두 개의 별도 릴레이 프록시를 통해 라우팅됩니다. 첫 번째 프록시는 사용자의 IP 주소를 알지만 이메일 내용을 볼 수 없습니다. 두 번째 프록시는 내용을 볼 수 있지만 누구인지 알 수 없습니다. 이 이중 릴레이 구조로 인해 발신자는 IP 주소를 사용해 열람을 수신자와 연결하는 것이 불가능합니다.
Apple Mail 사용자 중 약 97%가 이를 사용하고 있습니다 — 기본으로 활성화되어 있으며 대부분의 사람들은 끄지 않습니다.
Link Tracking Protection(iOS 17+)
iOS 17부터 Apple Mail은 URL에서 UTM 매개변수와 클릭 추적 ID도 제거합니다. 이로 인해 열람 추적에 더해 클릭 어트리뷰션도 작동하지 않게 됩니다.
시장 점유율
Litmus의 이메일 클라이언트 시장 점유율 데이터에 따르면, 2026년 1월 기준 11억 건의 추적된 열람 중 Apple Mail이 약 47%를 차지합니다. 이 수치는 지난 12개월 동안 46%에서 67% 사이를 오갔습니다.
최솟값으로 잡아도 거의 절반의 이메일 열람이 MPP 미리 가져오기로 인해 신뢰할 수 없습니다. 이것이 "읽음 확인이 작동하지 않는다"에서 "픽셀 추적도 마찬가지"로 이어지는 연결 고리입니다.
이메일 픽셀 추적 — "더 나은 대안"도 사실 망가졌습니다
대부분의 이메일 추적 관련 글은 이쯤에서 이렇게 마무리합니다. "읽음 확인은 신뢰할 수 없으니, 우리 픽셀 추적 도구를 사용하세요." 우리는 픽셀 추적에 대해서도 솔직하게 이야기할 것입니다.
픽셀의 작동 방식
<img> 태그를 통해 이메일 본문에 1×1 크기의 투명한 이미지가 삽입됩니다. 수신자의 이메일 클라이언트가 이메일을 렌더링하고 이미지를 로드하면, 픽셀이 서버에서 가져와지고 IP 주소, 사용자 에이전트, 타임스탬프, 고유 수신자 식별자가 기록됩니다.
메커니즘은 2000년대 초반부터 변하지 않았습니다. 그리고 대응 방법은 그 이후로 계속 발전해왔습니다.
Apple Mail Privacy Protection
위에서 다룬 것처럼, MPP는 모든 이미지를 미리 가져옵니다. 모든 이메일이 "열린" 것처럼 보입니다. Apple Mail이 전체 이메일 열람의 약 47%를 차지하는 상황에서, "열람"의 거의 절반이 유령 읽기일 수 있습니다.
Gmail의 이미지 프록시 및 평판 기반 차단
2013년부터 Gmail은 모든 이미지를 Google의 프록시 서버를 통해 라우팅하여 수신자의 IP 주소와 기기 정보를 숨깁니다. 열람 추적은 기술적으로는 여전히 작동하지만 — 이미지 로드마다 기록됨 — 위치 정보와 기기 데이터는 손실됩니다.
2024년 8월부터 Gmail은 낮은 평판의 발신자에게서 온 이메일의 이미지를 완전히 차단하고 경고 배너를 표시합니다: "이 메시지의 이미지가 숨겨졌습니다. 이 메시지는 의심스럽거나 스팸일 수 있습니다." 이는 전면 차단이 아니라 ML 기반으로, 발신자 평판, SPF/DKIM/DMARC 인증, 스팸 신고율, 참여 지표에 따라 결정됩니다.
좋은 발신자 평판을 가진 정규 마케팅 이메일은 일반적으로 영향을 받지 않습니다. 콜드 아웃리치 이메일 — 정확히 열람 추적이 가장 필요한 경우 — 이 불균형하게 영향을 받습니다. 이미지가 차단되면 추적 픽셀이 로드되지 않아 열람이 전혀 감지되지 않습니다.
기업 보안 스캐너
Barracuda, Mimecast, Proofpoint, Microsoft Defender for Office 365는 모두 인바운드 이메일 스캔 중에 이미지를 미리 가져오고 링크를 미리 클릭하여, 인간이 이메일을 보기 전에 유령 열람과 클릭을 생성합니다.
Microsoft 365의 기업 시장 점유율을 감안하면 Microsoft Defender의 Safe Links 기능이 특히 큰 영향을 미칩니다. 거짓 열람을 생성하는 것으로 확인된 다른 도구로는 Cisco Secure Email, Check Point Avanan, Trend Micro, Sophos, CrowdStrike가 있습니다.
봇 패턴은 예측 가능합니다: 배달 후 60초 이내의 열람 및 클릭, 여러 링크에 대한 1초 미만의 순차 클릭, 알려진 보안 업체 IP 범위에서의 요청. 한 문서화된 사례에서는 캠페인 참여의 80%가 봇 트래픽이었음이 밝혀졌습니다.
덱 뷰 수를 부풀리는 보안 봇에 대해서는 덱 분석이 잘못된 이유에서 다루었습니다 — 이메일 열람을 위조하는 봇과 동일한 봇입니다.
AI 인박스 에이전트 — 2026년의 새로운 변수
Google Gemini 등의 AI 어시스턴트가 이제 수신 이메일을 스캔하여 요약을 생성하고 작업을 제안하며, 추적 픽셀을 포함한 삽입된 이미지를 로드합니다 — 인간의 개입 없이.
이것은 어떤 이메일 추적 도구도 아직 신뢰할 수 있게 필터링하지 못하는 거짓 열람의 새로운 원인입니다. "오전 3시 47분에 열람됨"이라는 정보가 실제로는 사용자가 아닌 Gemini가 이메일을 읽은 것일 수 있습니다.
2026년 기준 이미지 차단 기본값
주요 이메일 클라이언트의 현황:
- 기본적으로 이미지 차단: Outlook 데스크톱(Classic 및 New), Thunderbird, Proton Mail, Tuta(구 Tutanota)
- 기본적으로 이미지 표시(프록시를 통해): Gmail, Apple Mail, Yahoo Mail, Outlook 모바일
근본적인 한계
픽셀 추적이 완벽하게 작동하더라도 — Apple MPP도, 봇도, 이미지 차단도 없다고 해도 — 알 수 있는 것은 이메일이 열렸다는 사실뿐입니다. 첨부 파일이 아닙니다. 첨부 파일 안의 문서도 아닙니다. 첨부 파일을 열어도 픽셀이 발동하지 않습니다. 첨부 파일을 열지 않아도 픽셀 발동을 막을 수 없습니다.
픽셀 추적은 편지가 아닌 봉투에 대한 질문에 답합니다.
봉투를 추적하고 있는 겁니다, 편지가 아니라
실제로 이메일이 열렸는지 신경 쓰는 사람은 없습니다. 궁금한 것은 잠재 고객이 제안서를 읽었는지, 지원자가 오퍼레터를 검토했는지, 고객이 계약서를 살펴봤는지입니다.
이메일 추적 — 읽음 확인이든 픽셀이든 — 은 "봉투를 봤는가?"에 답합니다. 문서 추적은 "편지를 읽었는가, 그리고 어느 페이지에 밑줄을 그었는가?"에 답합니다.
실제로 작동하는 방법: 이메일이 아닌 콘텐츠를 추적하세요
해결책은 점진적 개선이 아닌 구조적 변화입니다. 이메일에 제안서를 첨부하고 읽음 확인을 바라는 대신, 추적 링크로 공유하세요. 수신자가 링크를 클릭하면 문서가 서버에서 로드되어 모든 것을 기록할 수 있습니다: 누가 열었는지, 언제, 각 페이지에 얼마나 시간을 보냈는지, 무엇을 클릭했는지, 다시 돌아왔는지까지.
이것은 임시방편이 아닙니다. 이 글에서 다룬 모든 한계를 우회하는 근본적으로 다른 접근법입니다. Apple Mail은 아직 클릭하지 않은 문서를 미리 가져올 수 없습니다. 보안 봇은 참여 분석을 채우지 않습니다. 그리고 추적이 이메일 레이어가 아닌 콘텐츠 레이어에 있기 때문에, 이미지를 차단해도 소용이 없습니다.
첨부 파일에서 추적 링크로의 전환에 대한 전체 워크플로는 이메일 첨부 파일 열람 추적이 가능할까?에서 다룹니다. 제안서별 추적에 대해서는 영업 제안서 열람 여부 확인하는 방법을 참고하세요. 신뢰할 수 있는 추적을 제공하는 도구를 평가하고 있다면, 제안서 추적 소프트웨어 비교에서 주요 옵션을 나란히 비교합니다. 현재 DocSend를 사용 중이라면 DocSend 대안 비교를 확인하세요.
이메일 추적이 여전히 유효한 경우
이메일 열람 추적이 쓸모없다고 말하는 것이 아닙니다. 개별적인 고위험 결정에서는 쓸모없다는 것입니다.
대규모 아웃리치 및 캠페인
수백 또는 수천 건의 이메일에 걸친 집계 열람률은 노이즈가 있더라도 유용한 방향성 신호를 제공합니다. 화요일 발송이 34%의 열람률을 기록하고 목요일이 22%라면, 절대 수치가 봇과 Apple MPP로 부풀려져 있더라도 화요일 시간대가 더 효과적일 가능성이 높습니다.
Mailchimp, HubSpot 같은 마케팅 자동화 도구는 캠페인 수준의 열람률을 제목 줄 A/B 테스트, 발송 시간 최적화, 목록 상태 모니터링에 활용합니다. 이 규모에서는 노이즈가 평균화되어 충분히 유용합니다.
구분
- 집계 이메일 지표 — 캠페인 최적화에 유효
- 개별 이메일 추적 — 고위험 후속 결정에서는 신뢰 불가
화요일 배치가 목요일보다 나은 성과를 냈는지 알고 싶을 때는 이메일 열람 추적이 충분합니다. 목요일 통화 전에 Acme Corp의 Jane이 당신의 특정 제안서를 읽었는지 알고 싶을 때는 실패합니다.
업계의 방향
답장률, 클릭률, 전환율이 대부분의 이메일 플랫폼에서 열람률을 대체하는 주요 참여 지표로 자리잡고 있습니다. Apple의 MPP가 전환점이 되었습니다 — 전체 열람의 절반이 신뢰할 수 없게 되자 지표로서의 권위를 잃었습니다. 이메일 인프라의 변화에 대해서는 2026년 이메일 전달률을 참고하세요.
이메일 추적 방법 비교
| 기능 | 읽음 확인(MDN) | 픽셀 추적 | 추적 문서 링크 |
|---|---|---|---|
| 이메일 열람 여부 확인 | 불확실 — 수신자가 거부 가능 | 불확실 — Apple MPP, Gmail, 보안 스캐너에 의해 차단 | 해당 없음 — 이메일이 아닌 문서를 추적 |
| 열람자 확인 | 예, 확인이 반환된 경우 | 근사치 — IP/사용자 에이전트, 프록시에 의해 마스킹 | 예 — 이름 및 이메일로 확인 |
| 열람 시각 확인 | 예, 확인서의 타임스탬프 | 예, 픽셀이 로드된 경우 | 예 — 실시간 알림 |
| 열람 시간 확인 | 아니오 | 아니오 | 예 — 페이지별 시간 추적 |
| 읽은 내용 확인 | 아니오 | 아니오 | 예 — 페이지별 참여도 |
| 링크 클릭 확인 | 아니오 | 아니오 | 예 — 클릭 추적 |
| 개인 Gmail에서 작동 | 아니오 | 저하됨 — 프록시, 평판 기반 차단 | 예 |
| Apple Mail에서 작동 | 아니오 | 아니오 — MPP가 모든 것을 미리 가져옴 | 예 |
| 수신자 차단 가능 | 예 — 자동으로 | 예 — 이미지 차단 | 아니오 |
| EU 법적 지위 | 일반적으로 허용 | 점점 논쟁의 여지 있음 — CNIL 초안 지침은 별도 동의 요구 제안 | 표준 데이터 처리 |
FAQ
Gmail에서 상대방이 이메일을 읽었는지 알 수 있나요?
신뢰할 수 있는 방법은 없습니다. 개인 계정은 읽음 확인을 전혀 지원하지 않습니다. Workspace 계정은 관리자 활성화가 필요하고, 데스크톱 웹에서만 작동하며, 수신자가 자동으로 거부할 수 있습니다. 픽셀 추적 확장 프로그램은 작동하지만 Gmail의 이미지 프록시(위치 또는 기기 데이터 없음)와 평판 기반 이미지 차단(콜드 아웃리치 이메일은 신호가 전혀 없을 수 있음)으로 인해 저하됩니다.
Gmail과 Outlook 간에 읽음 확인이 작동하나요?
일관적이지 않습니다. 크로스 플랫폼 읽음 확인 처리는 클라이언트 버전, 관리자 설정, 수신자 구성에 따라 다릅니다. Gmail Workspace 사용자가 읽음 확인을 요청할 수 있지만, Outlook 수신자가 자동 거부하거나 무시할 수 있습니다. 발신자는 아무런 응답도 받지 못하는 경우가 많으며, 이유도 알 수 없습니다.
이메일 추적 픽셀은 합법인가요?
점점 논쟁의 여지가 생기고 있습니다. 프랑스의 CNIL은 2025년 6월 중요한 초안 지침을 발표하여 추적 픽셀을 ePrivacy 지침에 따른 쿠키와 동등하게 취급하고, 개별 수준의 열람 추적에는 이메일 수신 동의 외에 별도의 명시적 동의가 필요하다고 제안했습니다. 영국 ICO는 추적 픽셀이 쿠키와 동일한 규칙을 준수해야 한다고 명시합니다. 일대일 비즈니스 이메일 픽셀을 구체적으로 겨냥한 집행 조치는 아직 없지만, 규제 방향은 명확합니다. 이것은 법률 조언이 아닙니다.
Mailtrack에서 이메일이 10번 열렸다고 표시되는 이유는 무엇인가요?
보안 스캐너와 봇입니다. 기업 이메일 보안 도구 — Microsoft Defender, Proofpoint, Mimecast, Barracuda — 는 인바운드 스캔 중에 이미지를 미리 로드하고 링크를 미리 클릭하여 각각 별도의 "열람" 이벤트를 생성합니다. Google Gemini 같은 AI 인박스 에이전트도 스캔하는 동안 이미지를 로드합니다. "3개 국가에서 15번 열람됨"이 실제로는 보안 스캐너 하나와 AI 에이전트 하나일 수 있습니다.
이메일 첨부 파일 열람을 추적하는 방법이 있나요?
없습니다. 이메일 첨부 파일은 발신자와의 연결이 없는 로컬 복사본입니다. 전체 설명과 대안적 접근법은 이메일 첨부 파일 열람 추적이 가능할까?를 참고하세요.
Superhuman, Hey 등 읽음 추적 기능을 갖춘 이메일 클라이언트는 어떤가요?
Superhuman(2025년 Grammarly에 약 8억 2,500만 달러에 인수됨)은 여전히 "Read Statuses" — 상대방이 이메일을 언제, 몇 번, 어떤 기기에서 열었는지 보여주는 픽셀 기반 추적 — 을 제공합니다. 위치 추적을 둘러싼 2019년 논란 이후 이 기능은 기본적으로 꺼져 있으며, 위치 추적은 영구적으로 제거되었습니다.
Hey.com은 정반대의 접근 방식을 취합니다 — 수신 이메일의 모든 추적 픽셀을 적극적으로 제거하고, 어떤 서비스가 추적을 시도했는지 식별하여 사용자에게 알려줍니다.
두 가지 모두 같은 점을 보여줍니다: 기본 픽셀 메커니즘은 동일하며, 위에서 다룬 Apple MPP, Gmail 프록시, 보안 스캐너의 한계를 그대로 가지고 있습니다. 더 세련된 UI가 신뢰성 문제를 해결하지는 않습니다.