이 조언은 늘 ‘추가’라는 동사로 나온다. 그냥 DMARC 추가하세요. meta 태그 하나 넣듯, config에 한 줄 붙이듯 추가하라고. 보안 체크리스트에, “도메인 하드닝 10가지” 글에, 감사관이 템플릿에서 복붙하는 조치 노트에 등장한다. 그리고 이건, 저 문장 그대로는, 최악의 조언이다 — DMARC가 나빠서가 아니라 ‘추가’라는 단어가 실제 작업의 5%쯤만 묘사하고 정작 중요한 95%를 가리기 때문이다.
“그냥 DMARC 추가하세요”가 현실에서 실제로 뭘 만들어내는지 보자. 누군가 조언을 읽고, v=DMARC1; p=none이라고 적힌 TXT 레코드를 올리고, 체크리스트 항목이 초록색으로 바뀌는 걸 보고, 넘어간다. 이제 그들은 “DMARC가 있다.” 그리고 어제와 정확히 똑같이 스푸핑당할 수 있다. p=none은 수신 서버에게 아무것도 하지 말라고 하니까. “관찰만 하고 조치는 취하지 말 것”이라는 정책이다. 위조된 청구서는 여전히 도착한다. 가짜 대표이사 송금 요청도 여전히 도착한다. 방어된 건 없다. 상자에 체크만 됐다.
p=none이 DMARC 배포가 가서 죽는 곳이라는 건 전에도 썼다. 근데 리포트 함정은 “그냥 추가하세요”가 실패하는 이유의 절반일 뿐이다. 나머지 절반은 더 기술적이고, 덜 논의되고, p=reject까지 제대로 가는 사람조차 자기 메일을 조용히 깨먹었다는 걸 뒤늦게 발견하게 만드는 원인이다. 이름은 alignment. “그냥 DMARC 추가하세요”라고 말하는 사람 중에 이걸 설명한 사람은 거의 없다.
SPF도 DKIM도 통과하는데 DMARC는 실패한다
처음 보면 뇌가 멈추는 부분이니 구체적으로 가자.
DMARC는 SPF가 통과하는지 신경 안 쓴다. DKIM이 통과하는지도 신경 안 쓴다. SPF나 DKIM이 수신자가 실제로 보는 From 헤더의 도메인과 일치하는 도메인에 대해 통과하는지를 신경 쓴다. 그 일치 요구가 alignment고, 그게 메커니즘 전부다(RFC 7489가 정의한다). SPF와 DKIM은 옛 자물쇠들이다. Alignment는 둘 다 남긴 구멍을 메우려고 DMARC가 그 위에 볼트로 조인 것이다: 어느 쪽도 혼자서는 눈에 보이는 From 주소에 대해 할 말이 없다.
둘이 어떻게 어긋나는지 보자. SPF는 envelope 발신자 — 서버끼리 주고받는 MAIL FROM return-path 주소, 수신자는 절대 못 보는 것 — 를 인증한다. DKIM은 서명의 d= 태그에 든 도메인을 인증한다. 그동안 수신자는 From: 헤더를 보고 있고, 그건 둘 중 어느 것과도 완전히 다른 도메인일 수 있다. 공격자는 not-your-bank.example을 등록하고, 거기에 완벽히 유효한 SPF와 DKIM을 세팅하고, 표시 이름에 “Your Bank”를, From에 security@yourbank.com을 넣어서, SPF도 통과하고 DKIM도 통과하고 모든 레거시 검사가 초록불인 메시지를 만들어낼 수 있다 — 정작 From 도메인은 그들이 소유하지도 않은 것인데. 그게 SPF와 DKIM이 끝내 못 막은 스푸핑이다. Alignment는 인증된 도메인과 From 도메인이 같은 조직이어야 한다고 요구해서 그걸 막는다.
여기까진 훌륭하다. 그 alignment가 돌아서서 정당한 발신자를 물기 전까지는.
ESP 함정
마케팅 메일을 큰 이메일 플랫폼으로 보낸다고 하자. 착실하게 “DMARC를 추가했다.” 심지어 누가 집행이 목표라고 해서 p=reject까지 갔다. 그런데 캠페인 오픈율이 곤두박질치고 당신 뉴스레터가 Gmail에서 반송되기 시작한다.
이유는 이렇다. 그 플랫폼은 자기 return-path 도메인으로 메일을 보내서, SPF는 당신 도메인이 아니라 플랫폼 도메인에 대해 인증되고 align된다 — 당신 입장에선 SPF alignment 실패. 그리고 따로 설정하지 않는 한 플랫폼은 d=를 자기 도메인으로 놓고 DKIM 서명한다 — 그래서 DKIM은 인증되지만 당신 From이 아니라 플랫폼에 align된다. 두 기반 검사 다 통과. 어느 것도 구독자가 보는 주소에 align 안 됨. DMARC 실패. 그리고 당신이 p=reject로 점프했으니, 방금 전 세계 인터넷에 당신 뉴스레터를 쓰레기통에 버리라고 말한 셈이다.
해결이 어렵진 않지만 그건 작업이고, 정확히 “그냥 DMARC 추가하세요”가 없는 척하는 그 작업이다: custom return-path(보통 플랫폼이 주는 CNAME)를 세팅해 SPF가 당신 도메인에 align되게 하고, 플랫폼이 당신 도메인에 게시된 키로 DKIM 서명하게 설정해 DKIM이 align되게 한다. 이걸 마케팅 플랫폼에 대해 한다. 그리고 청구 시스템. 그리고 헬프데스크. 그리고 HR 툴. 그리고 프랑크푸르트 사무실의 그 이상한 relay 하나까지. 당신인 척 메일 보내는 모든 서비스를 하나하나 alignment 안으로 데려와야 한다. 안 그러면 집행이 그 메일을 먹어버린다.
그건 추가하는 레코드가 아니다. 재고 조사 프로젝트다.
조언은 이렇게 말했어야 한다
제대로 된 DMARC는 하나의 순서고, 매 단계가 ‘추가’가 아니라 하기의 동사다:
p=none을 리포트 주소와 함께 게시하고 — 다들 건너뛰는 게 이 단계다 — 실제로 그 리포트를 삼켜라. aggregate 리포트는 못생긴 XML이고, 무더기로 오고, 당신 도메인으로 메일 보내는 게 누구인지 알려줄 유일한 지도다. 안 읽으면 눈뜬장님이다. 2023년에 만든 SaaS 체험판이 아직도 당신인 척 메일 보낸다는 걸, 급여팀 외부 벤더가 한 번도 align 안 됐다는 걸, 리포트를 읽거나 집행에서 그들 메일을 깨먹기 전까진 모른다. 리포트 읽기가 그 일이다.
그다음 리포트가 드러낸 모든 정당한 발신자에 대해 alignment를 고친다. 그다음, 오직 그다음에, p=quarantine로 옮겨 지켜보고, 마침내 p=reject. 레코드 변경은 사소하다. 그 사이의 발견과 조치가 진짜 보안 작업이고, 실제 조직에선 몇 주에서 몇 달이 걸린다. 진짜 조직은 아무도 다 기억 못 할 만큼 많은 곳에서 메일을 보내니까.
그중 무엇도 ‘추가’라는 단어에 안 들어간다.
나쁜 버전이 퍼진 이유
나쁜 조언은 compliance 모양이 돼서 이겼다. 2024년 초 Google과 Yahoo가 대량 발신자 — 대략 자기 사용자에게 하루 5,000통 넘게 보내는 누구든 — 에게 DMARC 레코드 게시를 요구하기 시작했다. 결정적으로 그 요구는 어떤 레코드든 있으라는 거였다. p=none 레코드면 충족된다. 그래서 엄청난 도메인 물결이 메일을 계속 흘려보내려고 “DMARC를 추가했고”, 업계는 집행 관점에선 거의 전부 겉치레인 채택률 급등을 발표할 수 있었다. 조언과 강제가 서로를 강화했다: 둘 다 레코드를 결과물로 취급한다.
DMARC가 문제라고 생각하진 않는다. 이 프로토콜은 진짜 영리한 일을 한다 — 인증을 사람이 실제로 읽는 신원에 묶는데, SPF와 DKIM은 그걸 한 적이 없다. 문제는 우리가 몇 주짜리 alignment·모니터링 프로젝트를 두 단어 명령형으로 압축해 놓고, DMARC가 있는 도메인이 여전히 스푸핑당하고 정당한 발신자가 여전히 메일을 거부당하는 걸 놀란 척하는 것이다.
누가 “그냥 DMARC 추가하세요”라고 하면 한 가지만 물어라: 뭐에 align해서요? 무슨 말인지 모른다면, 그들은 그걸 실제로 해본 적이 없는 거다. 그냥 레코드를 추가했을 뿐이다.