DMARCbis에서 바뀌는 것과 바뀌지 않는 것

DMARC 사양의 차기 버전인 DMARCbis(사실상 DMARC 2.0)가 IETF Last Call을 통과하고 RFC Editor 큐에 올라갔습니다. Proposed Standard로 공식 발행되는 시점은 2026년으로 예상되며, 현행 RFC 7489 사양은 이와 함께 폐기됩니다. DMARC 레코드를 운영 중인 조직이라면, 바뀌는 내용 대부분은 조용히 지나갑니다. 그러나 단 한 가지는 그렇지 않습니다.

DMARCbis는 pct 태그를 제거합니다. pct는 DMARC 프로토콜 내에서 단계적 적용(staged rollout)을 위한 유일한 수단이었습니다. DMARCeye 자체 데이터에 따르면, 이 태그는 올바르게 쓰인 사례가 드물었고 아예 사용되지 않은 경우가 대부분이었습니다. 이번 제거는 프로토콜이 이미 안고 있던 공백을 공식화하는 동시에, DMARC가 여전히 답하지 못하는 질문을 선명하게 드러냅니다. 즉 '정상 메일을 깨뜨리지 않으면서 모니터링에서 차단(enforcement)으로 어떻게 넘어갈 것인가' 하는 문제입니다.

DMARCbis의 현재 진행 상황

현재 초안은 draft-ietf-dmarc-dmarcbis-41이며, 최종 갱신일은 2026년 1월 13일입니다. IETF Last Call 검토는 2024년 말 버전 36에서 완료되었습니다. 문서는 현재 RFC Editor 큐에 있으며, 이는 Proposed Standard가 RFC 번호를 부여받아 공식 발행되기 직전의 마지막 행정 단계입니다.

먼저 실무 관점에서 세 가지를 짚어두겠습니다.

1. 기존 DMARC 레코드는 그대로 작동합니다. 버전 태그는 여전히 v=DMARC1입니다. DMARCbis를 구현한 수신자도 RFC 7489 형식의 레코드를 수용합니다.
2. 대부분의 변경은 조용합니다. 태그 명칭 변경과 Public Suffix List를 DNS 기반 메커니즘으로 대체하는 작업은 수신자 구현 내부에서 이뤄집니다. 도메인 소유자는 자신의 레코드를 계속 유효하게 유지하기 위해 아무것도 손댈 필요가 없습니다.
3. 모니터링에서 차단으로 넘어가는 지점에 영향을 주는 변경은 하나입니다. 바로 pct의 제거입니다. 새로 설계된 테스트 모드와 맞물려, 단계적 적용이 '작동해야 하는 방식' 자체가 달라집니다. 나머지 사양을 다 읽지 않더라도 이 변경만큼은 이해해둘 가치가 있습니다.

한눈에 보는 변경점

RFC 7489(현행 DMARC)와 DMARCbis의 핵심 차이는 다음과 같습니다.

• 제거되는 태그: pct(비율 기반 정책 적용), rf(포렌식 리포트 형식), ri(리포트 주기).
• 추가되는 태그: psd(public suffix 도메인 플래그, DMARC에 참여하는 PSO용), np(존재하지 않는 서브도메인 정책), t(이진 테스트 모드).
• 조직 도메인(Organizational Domain): Public Suffix List(PSL)는 더 이상 쓰이지 않습니다. 대신 DNS Tree Walk가 그 자리를 대신하며, 상위 도메인들에 차례로 존재하는 DMARC 레코드를 조회해 경계를 판단합니다.
• 메일링 리스트 가이드: 활성 메일링 리스트 트래픽이 있는 도메인에 대해 p=reject를 적용하지 말 것을 사양이 명시적으로 권고합니다. 구독자에게 미치는 부수 피해를 줄이기 위한 조치입니다.
• 폐기되는 문서: RFC 7489(DMARC), RFC 9091(PSD DMARC).

이 글의 나머지 부분은 실제 운영에 영향을 주는 변경에 집중합니다.

pct 태그의 제거

pct 태그는 운영자가 차단 정책을 점진적으로 확대할 수 있도록 DMARC가 마련한 장치였습니다. p=quarantine 레코드에 pct=10을 설정하면, 수신자가 실패 메시지 중 10%에만 격리(quarantine) 정책을 적용하고 나머지 90%는 통과시키는 방식이었습니다. 전면 차단 시 어떤 메일이 깨질지를 실제로 깨뜨리지 않으면서 확인하려는 의도였습니다.

실제로는 그렇게 작동하지 않았습니다. IETF가 이 태그를 제거하면서 밝힌 이유를 보면, 수신자마다 pct 값을 일관되지 않게 해석했고 0이나 100이 아닌 값에서는 수신자 생태계 전반에 걸쳐 동작이 신뢰할 수 없었습니다. pct를 통한 단계적 적용은 일종의 복권이었습니다. 레코드에 기재한 비율과 실제로 메일에 적용된 비율이 일치하는 경우가 드물었습니다.

DMARCbis는 이 메커니즘을 t 태그로 대체합니다. t=y는 레코드를 테스트 모드로 두며, 유효 정책을 한 단계 낮춥니다. 예를 들어 t=y가 붙은 p=reject 레코드는 p=quarantine으로 취급됩니다. 기본값인 t=n은 전면 적용입니다. 여기에는 비율이 없습니다. 연속적인 조절도 없습니다.

그대로 읽어두실 필요가 있습니다. 새 사양은 단계적 적용이 실제로 가능한 다른 수단으로 pct를 대체하지 않습니다. 실패한 메커니즘을 제거하되, 단계적 적용이라는 과제는 운영자의 몫으로 남겨둡니다.

Public Suffix List에서 DNS Tree Walk로

RFC 7489에서는 수신자가 invoices.example.com처럼 서브도메인에서 온 메일을 처리할 때, 외부에서 관리되는 등록부인 Public Suffix List를 참고해 조직 도메인 경계가 어디인지 판단합니다. 이 경계가 어떤 DMARC 정책을 적용할지, 정합성(alignment)을 어떻게 평가할지를 결정합니다.

DMARCbis는 PSL 대신 DNS Tree Walk를 사용합니다. 외부 목록을 참조하는 대신 수신자가 DNS를 직접 조회합니다. From 도메인에서 DMARC 레코드를 찾고, 상위 도메인으로 라벨을 하나씩 올라가며(invoices.example.com → example.com → com) 처음 발견한 유효한 DMARC 레코드에서 멈춥니다. 그 레코드에 붙은 새로운 psd 태그가, 해당 레코드가 조직 소유인지 public suffix 운영자 소유인지를 수신자에게 알려주고, 이에 따라 이후 처리 방식이 달라집니다.

조직 레코드를 하나만 가진 일반적인 도메인이라면 Tree Walk와 PSL이 같은 결과에 도달합니다. 달라지는 것은 예외적인 상황들입니다. 자신의 환경에서 다음 세 가지는 한 번 점검해볼 만합니다.

• 서브도메인에 DMARC 레코드를 별도로 운영하는 경우(거래성 메일과 마케팅 메일을 분리하거나 외부 발송자를 격리할 때 흔합니다). Tree Walk에서는 해당 서브도메인에서 발송된 메일에 대해 서브도메인의 DMARC 레코드가 조직 정책보다 항상 우선합니다. 오래전에 설정하고 손대지 않은 서브도메인 레코드가 있다면, 현재 조직 정책을 알게 모르게 덮고 있을 수 있습니다. 한 번 감사해 보시기 바랍니다.
• public suffix를 운영하는 경우(자사 존 아래에 고객 브랜드 도메인을 발급하는 호스팅 플랫폼, ccTLD/gTLD 레지스트리, 테넌트에게 서브도메인을 할당하는 BaaS나 CMS 등). 새로 추가된 psd=y 태그는 바로 이 경우를 위해 DMARCbis에 기본 탑재됐습니다. RFC 7489 체계에서는 별도 문서인 RFC 9091로 덧붙여져 있었는데, DMARCbis가 이를 본 사양에 통합합니다. 자신의 존에서 psd=y 레코드를 발행해야 하는지 검토하시기 바랍니다.
• 특이한 TLD, ccTLD 또는 여러 라벨로 이뤄진 public suffix 아래에서 메일을 보내는 경우(예: co.uk, github.io, s3.amazonaws.com 하위). 해당 suffix에 대한 PSL 항목과 Tree Walk 동작이 정확히 일치하지 않을 수 있습니다. 본인의 도메인부터 public suffix까지 각 상위 라벨에서 DMARC 레코드를 직접 조회해, 예상대로 해석되는지 확인하시기 바랍니다.

그 밖의 경우에는 별도로 할 일이 없습니다. 기존 DMARC 레코드는 PSL 시절과 동일하게 Tree Walk 아래에서도 그대로 동작합니다.

메일링 리스트에 관한 새로운 가이드

개정 사양은 활성 메일링 리스트 트래픽이 있는 도메인에서 p=reject를 발행하지 말라는 권고를 명시적으로 추가했습니다. 근거는 DMARC 운영자라면 오랫동안 겪어온 동일한 운영 문제입니다. 메일링 리스트는 헤더를 재작성하면서 DMARC 정합성을 깨뜨리고, 이때 reject 정책은 아무 잘못도 없는 구독자들을 처벌하게 됩니다.

자신의 도메인이 오픈소스 프로젝트 리스트, 업계 포럼, 협회 뉴스레터 등 메일링 리스트에 상당량 참여하고 있다면, 이 가이드는 진지하게 받아들일 가치가 있습니다. DMARC 전체 구현 가이드에서 대부분의 팀이 사용하는 서브도메인 분리와 ARC 패턴을 다루고 있으며, 이를 통해 강한 조직 정책과 리스트 참여를 양립시킬 수 있습니다.

DMARCbis가 해결하지 않는 것

이번 사양 개정은 단계적 적용이 한 번도 제대로 동작한 적이 없음을 인정합니다. 그러나 단계적 적용을 고치지는 않습니다. 그냥 제거합니다.

모니터링에서 차단으로 이동해야 하는 조직 입장에서는, 이번 개정이 지난 몇 달간 DMARCeye 자체 데이터가 보여주고 있던 구조적 공백을 공식화하는 셈입니다. DMARCeye 플랫폼에서 활발히 모니터링되고 있는 도메인을 2026년 1분기 스냅샷으로 살펴본 결과는 다음과 같습니다.

• 유효한 DMARC 정책을 가진 도메인 중 39.9%가 영구적으로 p=none에 머물러 있습니다. 모니터링 도구를 돌릴 정도로 관심이 있음에도, 스푸핑에 대한 보호는 0입니다.
• 실제로 차단을 적용하는 도메인 중 93.8%는 단계적 적용 없이 전체 트래픽(100%)에 정책을 걸고 있습니다. pct<100을 사용하는 비율은 6.2%뿐입니다.

서로 다른 두 결과, 같은 원인입니다. DMARC는 모니터링과 차단 사이에서 실제로 작동하는 중간 지대를 제공하지 않습니다. 그 간극을 메우기로 했던 메커니즘(pct 태그)은 복권이었고, DMARCbis 이후에는 아예 사라집니다. 새로 도입된 이진 테스트 플래그는 단계적 적용이 해줬어야 할 역할을 대신하지 못합니다.

당황하지 않고 준비하는 법

대부분의 도메인 소유자에게 DMARCbis는 긴급 대응 사안이 아닙니다. 기존 레코드는 그대로 동작하고, 수신자들이 정합성 처리 방식을 하루아침에 바꾸지도 않습니다. 다만 보급이 진행되는 과정에서 기억해둘 만한 실무 포인트 몇 가지를 정리합니다.

• 현재 단계적 적용 목적으로 pct를 쓰고 있다면: 레코드는 문법적으로는 여전히 유효하지만, DMARCbis를 준수하는 수신자는 pct<100을 사실상 pct=100처럼 다룹니다. 비율에 의존하고 있었다면 지금부터 전환 계획을 세우시기 바랍니다. 사양 내에서 가장 가까운 대체 수단은 테스트 모드용 t=y이지만, 이는 확률적으로 정책을 적용하는 것이 아니라 정책 수준을 한 단계 낮추는 방식입니다.
• 서브도메인 구조가 복잡한 경우: Tree Walk 모델을 기준으로 DMARC 레코드를 점검하시기 바랍니다. 실제 결과는 대개 PSL 기반과 동일하지만, 예외적 상황은 존재합니다.
• 활성 메일링 리스트 트래픽이 있는 경우: 해당 도메인에 p=reject를 피하라는 새 가이드는 진지하게 받아들일 필요가 있습니다. 보통은 서브도메인 분리 패턴으로 해결합니다.
• 오랜 기간 p=none에 머물러 있는 경우: DMARCbis는 이 상태를 바꿔주지 않습니다. 구조적 문제는 사양 자체에 있지 않고, 안전하게 넘어갈 수 있는 통로가 없다는 데 있습니다. DMARCbis는 이 공백을 공식화할 뿐, 해결하지는 않습니다.

DMARC 집계 리포트 읽는 법 가이드와 DMARC 전체 구현 가이드는 DMARCbis에서도 그대로 적용됩니다. 새 사양이 공식 발행된 뒤에 달라지는 것은 레코드에 무엇을 '설정할 수 있는지'이며, 돌아오는 리포트를 '어떻게 읽는지'가 아닙니다.

전환이 실제로 요구하는 것

당장 급한 일은 없습니다. DMARCbis 이후에도 DMARC는 여전히 DMARC이며, 오늘 발행한 레코드는 새 사양이 RFC 번호를 받는 그 날에도 그대로 수용됩니다. 이번 전환이 요구하는 것은 관점의 전환입니다. 모니터링에서 차단으로 넘어가는 일은 프로토콜이 도와주지 않는 문제라고 받아들이고, 그에 맞게 계획을 세워야 합니다.

집계 리포트를 대신 지켜보고, 차단 정책 적용 전에 정체불명의 발송자를 걸러주며, 더 강한 정책을 적용했을 때 어떤 메일이 깨질지 평이한 언어로 알려주는 도구는 프로토콜이 엄격해질수록 가치가 커집니다. DMARCeye는 바로 그 역할을 중심에 두고 만들어진 플랫폼이며, 무료 온라인 도구(DMARC 구성기, SPF, DKIM, BIMI 검사기)는 설정 측면을 10분 안에 정리할 수 있게 해줍니다.

지금 DMARCeye를 무료로 시작해 보세요. 사양이 바뀌기 전에, 내 도메인의 DMARC 리포트가 실제로 무엇을 말하고 있는지 확인하시기 바랍니다.