DMARCbis가 하위 도메인 스푸핑을 막는 새로운 방어 수단을 추가하다

2015년 이후 DMARC 표준이 처음으로 전면 개정되는 DMARCbis가 정식 표준이 되었습니다. 2026년 5월 19일 세 건의 새 RFC(9989, 9990, 9991)로 공개되어 RFC 7489를 대체하고, DMARC를 IETF 표준 트랙으로 올렸습니다. 대부분의 변경은 당장 조치가 필요하지 않지만, 지금 적용할 가치가 있는 추가 사항이 하나 있습니다. 기존 표준이 열어 둔 하위 도메인 스푸핑의 빈틈을 막아 주는 np=라는 새 태그입니다.

DMARC는 인증 검사를 통과하지 못한 메일을 어떻게 처리할지 수신 서버에 알려 주는 표준입니다. 이미 p=quarantine이나 p=reject로 운영하고 있다면, DMARCbis가 비준되었다고 해서 이미 게시해 둔 레코드가 깨지는 일은 없습니다. pct 태그의 제거, Public Suffix List에서 벗어난 변경처럼 비교적 조용한 변경 사항은 DMARCbis가 당신에게 어떤 의미인지 평이한 언어로 정리한 가이드에서 다룹니다. 이 글은 오늘 적용할 가치가 있는 그 한 가지 추가 사항에 관한 것입니다.

특정 섹션으로 바로 이동하려면 아래 링크를 클릭하세요.

• DMARCbis가 정식화한 것
• sp= 태그가 미치지 못하는 지점
• np= 태그는 어떤 일을 하는가?
• DMARCbis 비준으로 그 밖에 무엇이 바뀌었나?
• 지금 무엇을 해야 하는가?
• 정리

DMARCbis가 정식화한 것

DMARCbis는 단일 문서가 아닙니다. 표준의 각 부분을 하나씩 담당하는 세 건의 별도 RFC로 공개되었습니다.

• RFC 9989는 핵심 프로토콜을 정의합니다. 정책이 어떻게 게시되는지, 정렬(alignment)이 어떻게 평가되는지, 수신 측이 DMARC 레코드를 어떻게 처리하는지를 규정합니다.
• RFC 9990은 집계 보고서 형식, 즉 도메인이 매일 수신하는 XML 요약 보고서의 형식을 정의합니다.
• RFC 9991은 실패 보고(메시지 단위 포렌식 보고서)를 정의합니다.

이 세 RFC를 합쳐 지금까지 DMARC를 정의해 온 2015년 규격인 RFC 7489를 대체합니다. 동시에 표준의 지위도 한 단계 올렸는데, 이 부분은 정확히 짚어 둘 가치가 있습니다. RFC 7489는 Informational로 분류되어 있었고, 이는 DMARC를 문서로 정리하기는 했으나 IETF 표준 트랙의 인증을 받지는 못했다는 뜻입니다. DMARCbis는 Proposed Standard로 공개되었으며, 이는 비준된 표준 트랙 문서에 IETF가 부여하는 성숙도 등급의 명칭입니다. "Proposed"라는 단어가 붙어 있지만 이는 초안이나 진행 중인 작업이 아니라 완성된 정식 표준이며, 널리 쓰이는 여러 인터넷 프로토콜이 그 이상으로는 끝내 올라가지 못하는 표준 트랙의 첫 단계입니다. 실무적으로 이는 새로운 의무가 아니라 성숙도를 나타내는 신호입니다. Informational 문서로는 의문이 제기되던 조달과 컴플라이언스 상황에서 표준에 더 단단한 근거를 부여하지만, 이미 잘 동작하는 레코드를 손볼 것을 요구하지는 않습니다.

sp= 태그가 미치지 못하는 지점

DMARC에서는 메인 도메인에 적용할 정책(p= 태그)과 하위 도메인에 적용할 별도의 정책(sp= 태그)을 각각 설정할 수 있습니다. 문제는 sp=가 DNS에 실제로 존재하는 하위 도메인만 규율한다는 점입니다. 한 번도 생성된 적 없는 하위 도메인에 대해서는 아무 말도 하지 않습니다.

바로 이 빈틈을 공격자가 이용합니다. 사기범은 당신이 설정한 적도 없고 DNS 레코드도 전혀 없는 주소, 예컨대 accounting.yourbrand.com이나 payroll.yourbrand.com에서 메일을 보낼 수 있습니다. 그런 하위 도메인은 DNS 용어로 NXDOMAIN 응답(그런 이름 없음)을 반환하는데, 일부 수신 서버는 과거에 레코드가 없는 것을 정책이 없는 것으로 간주해 메시지를 그대로 통과시켰습니다.

대부분의 도메인이 이 부분을 노출된 채로 둡니다. DMARCeye의 2026년 1분기 산업 보고서에서, 완전 강제(p=reject) 상태인 도메인 가운데서도 65.15%가 어떤 종류의 하위 도메인 정책도 선언하지 않았습니다. p=none에서는 그 수치가 86.67%입니다. 최상위 수준에서는 단단히 잠겨 있는 도메인이라도, 한 레이블 왼쪽에서는 공격자에게 열린 문을 그대로 내줄 수 있습니다.

하위 도메인 정책 전체 분석은 2026년 1분기 데이터셋의 나머지 내용과 함께 보고서에 담겨 있습니다.

np= 태그는 어떤 일을 하는가?

np= 태그는 존재하지 않는 하위 도메인, 즉 DNS 레코드를 전혀 반환하지 않는 하위 도메인에 대해서만 DMARC 정책을 설정합니다. sp=에 빠져 있던 나머지 절반입니다.

np=가 게시되어 있으면, 지어낸 하위 도메인에서 온 메일을 평가하는 수신 서버는 명확한 순서를 따릅니다. 먼저 np= 정책이 있는지 확인합니다. 설정되어 있지 않으면 sp=로 넘어갑니다. 그것마저 없으면 메인 p= 정책으로 넘어갑니다. 이 새 태그는 과거에 위조된 하위 도메인 메일이 빠져나가게 했던 모호함을 없앱니다.

대부분의 도메인에서 올바른 값은 np=reject입니다. 존재하지 않는 하위 도메인은 정당한 메일을 전혀 보내지 않으므로, 그곳에서 왔다고 주장하는 모든 메일을 거부해도 잃을 것이 없으며 한 부류의 사칭 전체를 차단할 수 있습니다. 이미 v=DMARC1; p=reject;로 되어 있는 레코드는 한 항목만 추가하면 v=DMARC1; p=reject; np=reject;가 됩니다. 같은 논리가 sp=를 통해 기존 하위 도메인에도 적용되며, sp= 하위 도메인 정책 태그 가이드에서 각각을 언제 설정해야 하는지 짚어 줍니다.

다만 np=는 수신 서버가 그것을 존중할 때 비로소 도움이 됩니다. 갓 도입된 태그인 만큼 메일박스 제공자 전반에서 지원이 아직 확산되는 중이므로, 지금 게시해 두는 것은 즉각적인 해결책이라기보다 향후 호환성을 위한 보험에 가깝습니다.

지금 게시하고 있는 DMARC 레코드를 도메인을 입력해 확인해 보세요. 이미 적용된 sp=나 np= 태그가 있다면 함께 보여 줍니다.

DMARCbis 비준으로 그 밖에 무엇이 바뀌었나?

두 가지 변경이 이번 개정을 마무리하지만, 둘 다 오늘 당장 큰 조치를 요구하지는 않습니다.

pct 태그가 사라졌습니다. 한 번에 일정 비율의 메일에만 정책을 적용할 수 있게 하려던 태그였지만, 수신 서버마다 구현이 제각각이었습니다. DMARCeye의 2026년 1분기 데이터셋에서, p=quarantine 도메인의 94.11%, p=reject 도메인의 93.51%가 이미 이 태그를 무시하고 첫날부터 완전 강도로 강제하고 있었습니다. DMARCbis는 이를 더 단순한 t=(테스팅) 플래그로 대체합니다. 단계적 롤아웃이라는 발상이 끝내 작동하지 못한 이유에 대한 자세한 설명은 DMARCbis가 당신에게 어떤 의미인지 정리한 가이드에 담겨 있습니다.

DMARC는 또한 조직 도메인의 경계가 어디인지 판단하기 위해 Public Suffix List에 의존하던 방식에서도 벗어났습니다. 이제 DNS를 직접 따라 내려가며 판단합니다. 단일 도메인 소유자는 차이를 느끼지 못할 것입니다. 다만 대규모 하위 도메인 체계를 운영하는 담당자라면 레코드가 여전히 기대한 대로 해석되는지 확인해 두는 것이 좋습니다.

지금 무엇을 해야 하는가?

np=가 얼마나 중요한지는 무엇을 운영하느냐에 따라 달라집니다.

단일 도메인이나 소규모 사업을 운영하는 경우: np=reject를 추가하는 것은 단점이 없는 한 줄짜리 변경이며, 생성해 둔 모든 하위 도메인을 일일이 기억할 필요 없이 사칭 경로 하나를 막아 줍니다. 직접 DNS를 관리하지 않는다면 이는 관리하는 쪽이 할 일입니다. 보통 도메인을 구입한 등록 대행사(GoDaddy나 Namecheap 같은 회사), 웹 호스팅 업체, 또는 이메일을 설정해 준 IT 담당자나 에이전시입니다. 게시하려는 레코드 v=DMARC1; p=reject; np=reject;를 전달하고 도메인에 추가하거나 업데이트해 달라고 요청하세요.

이커머스 스토어나 마케팅 도메인을 운영하는 경우: 위조된 하위 도메인은 보안 문제인 동시에 브랜드 신뢰 문제입니다. 그럴듯하게 만든 billing.yourbrand.com이 당신과 똑같은 모습으로 고객의 받은편지함에 도착하기 때문입니다. np=reject를 능동적인 모니터링과 함께 적용해, 무언가를 조이기 전에 어떤 출처가 당신의 도메인 이름으로 메일을 보내는지부터 파악하세요. DMARCeye의 무료 플랜은 도메인 하나에 대해 보고서 전체 파싱을 제공하므로 시작하기에 충분합니다.

에이전시나 MSP라면: np=reject는 관리하는 모든 고객 도메인에 빠르게 적용할 수 있고 근거가 분명한 성과입니다. DMARCeye는 각 고객 계정을 독립적으로 분리하므로, 팀은 단일 콘솔에서 포트폴리오 전반의 하위 도메인 상태를 추적하면서도 각 고객은 자신의 데이터만 보게 됩니다.

기업 메일 인프라를 운영한다면: np=를 하위 도메인 거버넌스의 일부로 다루세요. 어떤 사업부가 어떤 하위 도메인을 소유하는지 목록을 정리하고, 정당하게 발송하는 하위 도메인에는 sp=를 설정하며, 그 밖의 모든 것에는 np=reject를 설정해 이 변경을 다음 DMARC 점검에 함께 반영하세요.

정리

DMARCbis가 정식 표준이 되었다고 해서 이미 잘 동작하는 DMARC 레코드에 어떤 변경을 강제하지는 않습니다. 다만 대부분의 도메인이 여전히 열어 두고 있는 빈틈, 즉 위조된 적 없는 하위 도메인 문제에 대한 해결책을 정식화했습니다. np= 태그가 그 새로운 레버이며, 대부분의 도메인에서는 np=reject가 안전한 기본값입니다. 이것이 필요한지 알 수 있는 유일한 방법은 오늘 자신의 도메인이 무엇을 게시하고 있는지 들여다보는 것입니다.

그 가시성이 바로 DMARCeye가 만들어진 이유입니다. 도메인이 수신하는 DMARC 보고서를 읽어, 어떤 출처가 당신의 이름으로 메일을 보내고 있는지, 그리고 정책이 어디에서 당신을 노출된 채로 두고 있는지를 평이한 언어로 보여 줍니다.