이메일 보안해설: 메일 한 건, 6가지 검증 단계

이메일은 수신자가 읽기도 전에 총 6번의 평가를 거친다. 이 가이드에서는 발송 서버에서 수신함에 이르기까지 이메일 한 건의 이동 경로를 추적하며 각 단계에서 어떤 일이 일어나는지 살펴본다.

6가지 검증 단계

원래 이메일은 이런 검증 절차 없이 설계되었다. Microsoft의 공식 문서도 이를 명확히 밝히고 있다.

"인터넷상의 간이 우편 전송 프로토콜(SMTP) 이메일은 설계상 메시지 발신자가 주장하는 본인이 맞는지 검증하려는 시도를 전혀 하지 않는다."

모든 보안 조치는 기존 프로토콜 위에 한 겹씩 덧대어 "임시방편으로 패치"되었고, 그 결과 복잡하게 얽힌 현대 이메일 보안 체계가 만들어졌다.

오늘날 이메일 메시지가 거치는 검증은 최소 6가지다.

1. 연결 (Connection) — 엔드포인트와 프로토콜을 확인한다.
2. 봉투 (Envelope) — SPF가 네트워크 주소를 확인한다.
3. 서명 (Signature) — DKIM이 암호화 서명을 확인한다.
4. 정렬 (Alignment) — DMARC가 이메일 클라이언트에 표시되는 정보와의 정렬 상태를 확인한다.
5. 평판 (Reputation) — 복잡하고 동적인 검증을 수행한다(휴리스틱, 머신러닝).
6. 수신함 (Mailbox) — 메일이 도착했을 때 이메일 클라이언트가 수행하는 동작을 다룬다.

Step 1 — 연결 (Connection)

수신 서버는 접속하는 IP 주소를 알고 있으며 해당 IP의 이력을 조회할 수 있다. 역방향 DNS(reverse DNS) 레코드가 없거나 블록리스트에 포함된 발송 주소는 이 단계에서 거부될 수 있다.

구글은 모든 발신자를 대상으로 이 검증을 의무화했다. 2024년 2월 1일부터 적용된 Google의 발신자 가이드라인에 따르면, 유효한 정방향 및 역방향 DNS 레코드, TLS 연결, 그리고 RFC 5322 규격을 준수하는 메시지 형식을 요구한다.

TLS와 관련하여 RFC 8461은 MTA-STS를 정의한다. 도메인 소유자는 유효한 TLS 연결을 제공하지 않는 한 해당 메일 서버로의 전달을 거부하도록 발신자에게 요구하는 정책을 게시할 수 있다. RFC 8460은 도메인 소유자에게 TLS 실패 보고서를 제공하는 표준이다.

Step 2 — SPF

SMTP 메시지에는 MAIL FROM과 From이라는 두 가지 발신자 주소가 존재한다. MAIL FROM은 서버 간 메시지를 전송할 때 사용되며 Return-Path 헤더에 들어간다. 반면 From 주소는 메일 클라이언트에 실제 표시되는 주소다.

RFC 7208에 정의된 SPF는 MAIL FROM을 기준으로 작동한다.

도메인 소유자는 해당 도메인을 대신해 메일을 보낼 수 있도록 허용된 서버 목록을 TXT 레코드로 게시하고, 수신자는 접속한 IP가 이 목록에 있는지 확인한다.

v=spf1 include:_spf.google.com -all

SPF가 자사 브랜드를 보호해 줄 것이라 생각하는 사람들이 자주 오해하는 두 가지 사실이 있다.

1. SPF는 From 주소에 관심이 없다. 메시지가 SPF 검증을 통과하더라도 From에는 전혀 다른 도메인이 표시될 수 있다.
2. 조회 횟수(Lookup limit)에 제한이 있다. include, a, mx, ptr, exists, redirect 구문은 각각 DNS 조회를 발생시키며, 표준에 따라 엄격히 제한된다.

RFC 7208 §4.6.4: "SPF 구현체는 DNS 과부하를 막기 위해 SPF 평가 중 해당 구문의 총 개수를 10개로 제한해야 한다(MUST). 이 제한을 초과하면 'permerror'를 반환해야 한다(MUST)."

관리자는 이 제한을 초과하지 않도록 주의해야 한다. CRM, 세금계산서 발송 도구, 고객지원 헬프데스크 등을 하나씩 추가하다 보면 구문이 10개를 넘어 모든 메일 수신이 마비되는 상황이 쉽게 발생한다.

SPF 정책의 마지막에 위치하는 -all은 목록에 없는 서버의 권한을 인정하지 않음을 의미하며, ~all은 다소 완화된 처리를 요청한다.

RFC 7208 §8.5: "수신 소프트웨어는 이 결과만을 이유로 메시지를 거부해서는 안 되며(SHOULD NOT), 평소보다 더 정밀한 검사를 적용할 수 있다(MAY)."

~all은 SPF를 처음 설정할 때 적용하기 좋은 시작점이다. 문제는 대부분 이 단계에서 설정을 더 이상 변경하지 않고 방치한다는 점이다.

5,798개 .co.kr 도메인의 SPF 레코드를 분석한 결과, 85.6%가 ~all로 끝났다. 이는 전 세계 평균인 53.6%를 크게 웃도는 수치다.

SPF는 일반적인 상황 중 하나인 '메일 전달(Forwarding)' 시 실패한다. 메시지가 다른 서버로 전달되면 발송 서버가 변경되는데, 이 전달 서버는 원본 도메인의 SPF 레코드에 포함되어 있지 않기 때문이다. 이 문제를 극복하고 수신함까지 안전하게 전달되도록 돕는 검증 단계가 바로 DKIM이다.

Step 3 — DKIM

RFC 6376에 명시된 DKIM은 SPF와는 다른 방식으로 접근한다. 발송 서버가 개인키를 사용해 메시지 본문과 주요 헤더에 서명하고, 이 서명을 DKIM-Signature 헤더에 첨부한다. 이에 대응하는 공개키는 DNS의 <selector>._domainkey.<domain> 위치에 게시되며, 수신자는 이를 가져와 서명을 검증할 수 있다.

SPF와 달리 서명이 메시지 내부 자체에 포함되어 전송되므로, DKIM은 메일이 전달(Forwarding)되어도 서명이 유지된다.

다만 DKIM은 SPF의 허점과 대칭되는 한계를 가진다. 서명의 d= 태그에 지정된 도메인이 From 헤더의 도메인과 반드시 일치할 필요는 없다.

또한 DKIM에는 키 만료 개념이 없다. 게시된 키 레코드에는 만료 필드가 없으며, 표준 규격 어디에서도 키 교체(Rotation)를 강제하지 않는다. 예를 들어 2015년에 게시된 키가 오늘날에도 문제없이 작동할 수 있다. 이는 관리하기 편하지만 보안상 위험 요소가 될 수 있다.

Step 4 — DMARC

두 가지 검증을 통과했음에도, 수신자가 실제로 눈으로 확인하는 From 필드는 아직 검증되지 않았다. DMARC는 바로 이 허점을 메우는 보안 레이어다.

DMARC는 From에 표시된 도메인과 앞서 SPF 및 DKIM 검증을 통과한 도메인을 비교하여, 둘 중 최소 하나가 정렬(Align)되는지 확인한다. DMARC 자체가 SPF와 DKIM 둘 다 통과하도록 강제하는 기능은 없다는 점에 유의해야 한다. 그 정도 수준의 보안이 필요하다면 별도의 내부 기업 정책을 적용해야 한다.

DMARC 정책은 SPF와 DKIM이 모두 실패했을 때 수신자가 어떻게 처리해야 하는지 지정한다. 정책 값은 p=none, p=quarantine, p=reject 중 하나이며, _dmarc.<domain>의 TXT 레코드 형태로 게시된다.

현재 최신 규격은 2026년 5월에 발표된 RFC 9989로, IETF 표준 트랙에 오른 첫 DMARC 버전이다.

참고하는 문서가 어떤 버전인지 확인하는 것이 중요하다. 대부분의 설정 가이드는 여전히 이전 규격인 RFC 7489를 기준으로 설명하고 있다. Microsoft의 DMARC 설정 페이지조차 RFC 9989에서 폐지된 pct 태그를 여전히 안내하고 있다.

표준은 DMARC 정책을 게시하지 않은 도메인에 대해 명확한 지침을 내린다.

RFC 9989 §4.10.1: "DNS 트리 탐색 결과 DMARC 정책 레코드가 존재하지 않는 것으로 확인되면(일시적인 DNS 오류가 아니라 레코드 자체가 없음이 명확한 경우), 메일 수신자는 해당 메시지에 DMARC 메커니즘을 적용해서는 안 된다(MUST NOT)."

수신 서버는 DMARC 레코드가 없으면 해당 검증 단계를 완전히 건너뛴다.

국내 10,135개 도메인을 대상으로 조사한 결과, 응답한 9,934개 도메인 중 8,484개가 유효한 DMARC 정책을 게시하지 않았으며, 검증 실패 시 수신 서버에 조치를 요청한 도메인은 319개에 불과했다. 정책을 게시한 1,450개 도메인 중에서도 rua 주소를 설정한 곳은 666개에 그쳤다.

rua는 도메인 소유자가 리포트 데이터를 전달받을 수 있도록 권리를 부여하는 피드백 메커니즘이다. rua에 이메일 주소를 지정하지 않으면 DMARC가 잘 준수되고 있는지, 얼마나 많은 메일이 검증에 실패하고 있는지 파악할 수 없다.

Step 5 — 평판 (Reputation)

인증 단계는 메시지가 진짜인지 여부를 판단할 뿐, 수신자가 그 메일을 받고 싶어 하는지까지 확인해주지는 않는다. 수신 서버는 이 요소를 별도로 평가한다.

평판 관리의 대표적인 사례로, Microsoft는 표준 인증 검증과 함께 발신자 평판, 발신자 이력, 수신자 이력, 행위 분석 등 고유한 신호들을 조합하여 '복합 인증(Composite Authentication)'이라는 단일 값을 산출한다. 이 값은 Authentication-Results 헤더에 compauth 항목으로 기록된다. Microsoft 공식 문서는 이 값의 역할을 다음과 같이 설명한다.

"복합 인증 실패가 메시지 차단으로 직결되는 것은 아니라는 점을 이해하는 것이 중요하다. 시스템은 복합 인증 결과와 함께 메시지의 전반적인 의심스러운 정황을 종합적으로 고려하는 전체론적(holistic) 평가 전략을 사용한다."

최근에는 Abnormal Security와 같은 솔루션들이 머신러닝을 활용해 이메일의 위험성이나 스팸 여부를 분류한다. 일부 기업은 여러 겹의 보호 레이어를 구성하기도 한다. 일반적인 보안 체계는 다음과 같다.

1. Mimecast 프록시: 실시간 위협, 스팸 캠페인, 패턴을 기반으로 룰을 실행한다. 악성 이메일과 링크가 실제 수신 서버에 도달하기 전에 차단하는 것이 목적이다.
2. Microsoft Exchange 메일 서버: 표준 평판 검사와 사용자 정의 룰을 통해 이메일을 검증한다.
3. Abnormal Security 머신러닝: 이메일이 수신함에 전달된 후에 해당 메일을 격리하거나 삭제할 수 있다.

Step 6 — 수신함 (Mailbox)

메시지가 수신함에 도달한 이후의 동작은 사용자가 사용하는 메일 클라이언트 소프트웨어에 따라 달라진다.

클라이언트에 따라 원격 이미지 자동 로드 여부, 스캐닝 서비스를 통한 링크 재작성 여부, 외부 발신자 배너 표시 여부 등이 다르게 적용된다.

Panke 팀에서 6개의 메일함으로 추적용 메시지를 발송하고 이를 열어보는 실험을 직접 진행했다. Gmail과 Apple Mail은 사용자를 대신해 추적 이미지를 서버에서 미리 불러왔기 때문에 발신자는 사용자의 위치 정보를 알 수 없었다. 반면 네이버, 카카오, 다음, Outlook은 사용자 기기에서 직접 이미지를 불러와 접속 위치, 네트워크 정보, 브라우저 정보를 발신자에게 그대로 노출했다.

모든 검증을 통과하는 공격 유형

가장 정교한 유형의 이메일 공격은 위에서 언급한 모든 검증을 통과하여 비즈니스 이메일 침해(BEC) 피해를 일으킨다. 대표적인 3가지 수법은 다음과 같다.

표시 이름 위조 (Display-name spoofing): 수신자가 알 만한 사람의 이름으로 표시 이름을 설정하는 방식이다.

유사 도메인 (Lookalike domains): 원래 도메인과 매우 유사하게 등록한 도메인을 사용하는 방식이다.

탈취된 메일함 (A compromised mailbox): 공격자가 계정 정보를 탈취하여 실제 계정에서 메일을 발송하는 방식이다. 이 경우 메일이 회사 내부에서 정식으로 발송되므로 이메일 보안 소프트웨어로 탐지하기가 매우 어렵다.

FBI의 2025년 인터넷 범죄 보고서에 따르면 비즈니스 이메일 침해(BEC) 신고 건수는 24,768건, 피해 보고액은 약 30억 달러에 달했다. 이는 사이버 범죄 유형 중 투자 사기에 이어 두 번째로 큰 규모이며, 역대 최고치인 총 200억 달러의 전체 피해액 중 상당 부분을 차지한다.

이처럼 6가지 검증 단계는 필수적인 요소이지만 완전히 완벽한 방어를 보장하지는 않는다. 다음 글에서는 이메일 기반 사이버 공격으로부터 조직을 보호하기 위해 취할 수 있는 추가적인 보안 조치를 다룰 예정이다.

내 도메인 상태 확인하는 방법

현재 도메인의 이메일 인증 설정 상태를 확인할 수 있는 3가지 DNS 조회 명령어가 있다. 각 항목별 자세한 내용은 전용 포스트에서 확인할 수 있으므로, 여기서는 기본 확인 법만 다룬다.

DMARC

dig +short TXT _dmarc.yourcompany.com

주의가 필요한 상태:

• 응답 값이 없음 (수신 서버가 DMARC 검증을 건너뜀)
• p=none 설정
• rua 주소가 없음

DMARC에 대한 자세한 내용은 국내 10,135개 도메인 조사 결과 글에서 확인할 수 있다.

SPF

dig +short TXT yourcompany.com

v=spf1로 시작하는 줄을 찾아서 확인한다. 주의가 필요한 상태:

• include: 항목에 모르는 도메인이나 주소가 포함되어 있음
• +all 설정 (인증 제한이 전혀 작동하지 않음)
• ~all 설정 (개선 여지가 있음. -all로의 전환 검토 필요)
• DNS 조회가 필요한 구문이 10개를 초과함 (메일 수신 전체가 실패할 수 있음)

~all과 -all의 차이에 대한 자세한 내용은 한국의 SPF 설정 현황 포스트를 참고할 수 있다.

DKIM

dig +short TXT google._domainkey.yourcompany.com

위 예시의 google은 셀렉터(selector) 명칭이다. DNS만 조회해서는 어떤 셀렉터가 사용 중인지 직접 알아내기 어렵다. DNS 설정이나 수신된 메일의 DKIM-Signature 헤더를 확인해야 하며, 일반적인 셀렉터명인 google, default, selector1 등을 테스트해 볼 수 있다.

키 크기 및 교체 주기에 관한 내용은 DKIM 키 교체가 강제되지 않은 이유 포스트에서 다루고 있다.

참고 자료

1. IETF — RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (2026년 5월; RFC 7489 및 RFC 9091 대체)
2. IETF — RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (2014년 4월)
3. IETF — RFC 6376: DomainKeys Identified Mail (DKIM) Signatures (2011년 9월)
4. IETF — RFC 8461: SMTP MTA Strict Transport Security (MTA-STS) (2018년 9월)
5. IETF — RFC 8460: SMTP TLS Reporting (2018년 9월)
6. Microsoft Learn — How email authentication works in Microsoft 365 (2026년 7월 17일 업데이트)
7. Google Workspace Admin Help — Email sender guidelines (2024년 2월 1일 적용 발신자 지침)
8. FBI Internet Crime Complaint Center — 2025 Internet Crime Report (신고 1,008,597건, 피해액 208억 7,700만 달러)
9. Panke — 이메일 스푸핑: 한국 도메인 10,000개 이상 조사 결과 (2026년 9월 1일)
10. Panke — 한국의 SPF 현황 (2026년 9월 3일)
11. Panke — 이메일 열면 위험하다고? (2026년 8월 31일)