AI 요약
서버웍스(ServerWorks)의 엔지니어 우치무라(内村)는 고객사로부터 자사 도메인 관련 SPF/DKIM 인증 실패 보고를 받고 조사한 과정을 공유했습니다. 당시 고객사는 DMARC 정책을 'none'에서 'quarantine' 또는 'reject'로 강화하기 위해 사전 조사를 진행 중이었으며, 분석 결과 인증 실패가 발생한 IP는 모두 구글의 메일 서버(ASN 15169)로 확인되었습니다. 서버웍스 측은 내부 개발 자산의 Git 리포지토리 검색 및 Gmail 에일리어스 설정 등을 전수 조사했으나 특이점이 없었습니다. 최종적으로 사내 보안 전문가와의 협업을 통해, 구글 워크스페이스(Google Workspace) 그룹 메일링 리스트를 통한 메일 전달 과정에서 헤더 From과 인증 도메인이 일치하지 않는 'DMARC 얼라이먼트' 오류가 원인임을 특정했습니다. 이는 시스템의 결함이 아니라 메일 전달 메커니즘의 특성에 기인한 것으로, 향후 ARC(Authenticated Received Chain) 기술의 중요성을 시사합니다.
핵심 인사이트
- 인증 실패의 실체: 고객사가 제공한 데이터 분석 결과, 실패한 IP 주소는 모두 'ASN 15169(Google)'에 속하며 역방향 호스트명이 '*.google.com'인 구글 전용 메일 서버였습니다.
- DMARC 얼라이먼트 중요성: SPF/DKIM 기술 인증 자체는 통과(Pass)하더라도, 헤더 From 도메인과 SPF의 Return-Path 또는 DKIM의 d= 태그 도메인이 일치하지 않으면 DMARC는 최종 실패(Fail) 처리됩니다.
- 조사 시점 및 배경: 본 조사는 2026년 3월 기준으로 작성되었으며, 특히 보안 기준이 엄격한 금융 업계의 DMARC 강화 추세가 이번 조사의 주요 배경이 되었습니다.
- 핵심 원인 도구: 사내 시스템의 직접 발송이 아닌, Google Workspace 그룹(메일링 리스트)의 전달 기능을 통한 메일 발송이 얼라이먼트 불일치를 유발한 결정적 원인이었습니다.
주요 디테일
- 시스템 전수 조사: 개발 리포지토리 내에서 고객사 도메인(
example.jp) 및 메일 관련 키워드(sendmail,smtp,ses)를 검색(grep)하여 내부 시스템 발송 여부를 1차 검증했습니다. - DMARC 정책 3단계: 인증 실패 시 아무 조치도 하지 않는 'none', 스팸함으로 보내는 'quarantine', 수신을 거부하는 'reject' 단계 중 고객사는 상위 단계로의 전환을 추진 중이었습니다.
- SPF/DKIM/DMARC의 관계: SPF는 엔벨로프 From, DKIM은 전자서명을 검증하며, DMARC는 이들이 실제 사용자에게 보이는 '헤더 From'과 일치하는지를 최종적으로 확인합니다.
- ARC(Authenticated Received Chain) 언급: 메일 전달 과정에서 발생하는 인증 정보 훼손을 방지하기 위한 기술적 대안으로 ARC의 역할이 강조되었습니다.
- 추적 기법: DMARC 리포트(XML 형식)와 메일 헤더 정보를 대조하여 특정 메일링 리스트를 통해 전달된 경로를 역추적하는 방식을 사용했습니다.
향후 전망
- DMARC2 도입 가속화: 메일 전달 시의 한계를 극복하기 위해 논의 중인 DMARC2 표준화 및 관련 기술 동향에 대한 업계의 관심이 높아질 것으로 보입니다.
- 엔터프라이즈 보안 강화: 금융권뿐만 아니라 일반 기업에서도 DMARC 정책을 'reject'로 설정하는 사례가 늘어남에 따라, 정당한 메일이 차단되지 않도록 하는 정밀한 사전 화이트리스트 관리가 필수화될 전망입니다.