이메일은 원래 신원 확인이 없었다 - SPF, DKIM, DMARC 정리

서비스에서 메일 발송을 붙일 때 한 번쯤 마주치는 세 글자 약어가 있습니다. SPF, DKIM, DMARC. DNS에 레코드 추가하라는 문서를 보고 시키는 대로 복사해 붙인 적은 있는데, 정작 각각이 뭘 하는지는 모르고 지나가기 쉽습니다.

이걸 제대로 이해하려면 이메일 프로토콜의 설계부터 봐야 합니다.

애초에 발신자를 검증하지 않는다

SMTP는 1980년대에 만들어졌습니다. 서로 신뢰하는 소수의 연구 기관끼리 쓰던 시절이라, 발신자가 자기를 누구라고 밝히든 그걸 검증할 장치가 없었습니다. 봉투에 보내는 사람 이름을 마음대로 적을 수 있는 것과 같습니다.

그래서 이메일 스푸핑은 해킹이 아니라 프로토콜의 정상 동작에 가깝습니다. From 헤더에 아무 주소나 적으면 그대로 표시됩니다. 피싱이 지금도 잘 통하는 근본 원인이 여기 있습니다.

이 구멍을 사후에 막으려고 덧붙인 게 세 가지 인증 방식입니다.

각각의 역할

SPF(Sender Policy Framework). 도메인 소유자가 "내 도메인 이름으로 메일을 보낼 수 있는 서버는 이것들이다"라고 DNS에 명시합니다. 수신 서버는 메일이 온 IP가 그 목록에 있는지 확인합니다. 발신 주체를 검증하는 거죠.

DKIM(DomainKeys Identified Mail). 발신 서버가 개인키로 메일 헤더에 전자서명을 하고, 수신 서버는 DNS에 공개된 공개키로 검증합니다. 전송 중에 내용이 변조되지 않았는지, 그리고 정말 그 도메인이 서명했는지를 확인합니다.

DMARC. 앞의 두 검사 결과를 어떻게 처리할지 지시하는 정책입니다. 여기가 핵심인데, SPF와 DKIM만 설정해두면 검사는 되지만 실패했을 때 뭘 할지가 정해져 있지 않습니다. DMARC가 없으면 그 결과가 사실상 버려집니다.

DMARC 정책은 세 단계입니다. p=none(아무것도 안 함, 보고서만 수집), p=quarantine(스팸함으로), p=reject(거부). 구글 문서도 none으로 1주일 이상 보고서를 모니터링한 뒤 단계적으로 올리는 방식을 권합니다. 바로 reject로 걸면 정상 메일까지 튕겨나갈 수 있으니까요.

가장 흔한 실수

업계에서 반복적으로 지적되는 게 하나 있습니다. DMARC를 모니터링 모드로 켜두고 그대로 방치하는 것입니다.

레코드를 추가했으니 설정은 끝났다고 생각하지만, p=none은 말 그대로 아무것도 차단하지 않습니다. 보고서만 쌓이고 스푸핑은 그대로 통과합니다. 설정은 했는데 보호는 안 되는 상태인 거죠.

보고서를 읽는 것도 일입니다. 큰 조직은 하루에 수백에서 수천 건의 리포트를 받게 되므로, 전용 메일함이나 그룹을 따로 만들어 두라는 게 일반적인 권고입니다.

이제는 선택이 아니다

2024년부터 Gmail과 야후가 대량 발신자(하루 5,000통 이상)에게 요구 사항을 걸었습니다. SPF와 DKIM 인증, 최소 p=none 이상의 DMARC 설정, 프로모션 메일의 원클릭 수신거부 제공.

이걸 갖추지 않으면 메일이 스팸으로 가는 정도가 아니라 받은편지함에 도달하기 전에 거부될 수 있습니다. 마케팅 메일이든 서비스 알림이든 도달률이 곧 사업 문제가 되니, 인증 설정이 보안 이슈이자 운영 이슈가 된 셈입니다.

참고로 도달률에는 인증 외에도 발신자 평판, 반송률, 스팸 신고율, 수신자 참여도가 함께 작용합니다. 인증만 맞춰두고 오래된 주소 목록에 계속 발송하면 평판이 깎여서 결국 같은 문제를 겪습니다.

한계도 알아둘 필요가 있다

DMARC를 제대로 걸어도 뚫리는 경우가 있습니다.

공격자가 정상 계정을 탈취해서 보내면 모든 인증을 통과합니다. 진짜 그 도메인에서 보낸 메일이 맞으니까요. 표시 이름(display name)만 유명 기업으로 바꾸고 발신 도메인은 자기 것을 쓰는 수법도 흔합니다. 인증은 통과하지만 사람 눈에는 그 기업 메일로 보입니다.

그래서 인증은 필요조건이지 충분조건이 아닙니다. 다계층 방어가 필요하다는 얘기가 나오는 이유입니다.

결국 마지막 방어선은 수신자 쪽에 남습니다. 서버 단에서 걸러지지 않고 들어온 메일을 사람이 판별해야 하는데, 기준을 정리하면 이 정도입니다.

표시 이름이 아니라 발신 도메인 전체를 볼 것, 링크는 클릭 전에 실제 URL을 확인할 것, 시간을 압박하는 문구를 의심할 것, 그리고 돈이나 인증이 걸린 요청이라면 메일 속 링크가 아니라 공식 앱이나 사이트로 직접 접속해 확인할 것. 사내 보안 교육에서 늘 나오는 얘기지만, DMARC를 아무리 잘 걸어도 이 마지막 단계는 대체되지 않습니다.

정리

이메일 인증은 프로토콜의 설계 결함을 DNS 레코드로 메꾼 구조입니다. 우아하진 않지만 지금 우리가 가진 최선이고, 이제는 설정하지 않으면 메일이 아예 안 가는 환경이 됐습니다.

서비스 메일을 운영 중이라면 DMARC 정책이 p=none에 멈춰 있지는 않은지 한 번 확인해보시길 권합니다. 의외로 그 상태로 몇 년 방치된 도메인이 많습니다.