요약

  • RFC 9990은 구조화된 DMARC 집계 보고서를 정의합니다. 메일 수신자는 명시된 기간에 대해 인증 결과, 평가된 정책, 메시지 수, 식별자 및 로컬 재정의 사유를 보고합니다.
  • 이 보고서는 메시지별 이벤트 이력이 아닙니다. 정책 변경은 기록된 정책 구성이 하나뿐인 혼합 기간 집계를 만들 수 있고, 부분적 겹침은 항상 분리될 수 없으며, RFC는 보고서 데이터가 위조될 수 있음을 명시적으로 경고합니다.
  • Daniel Kade는 메시지 본문이나 개별 주소를 보존하지 않으면서 생성자 신원, 정책 시대, 커버리지 기간, 파일 다이제스트, 겹침 처리 및 소비자의 결정을 기록하는 프라이버시 최소화된 집계 의존 영수증을 제안합니다.

유용한 수치에도 관찰되지 않은 분모가 있을 수 있다

도메인 소유자가 아침 DMARC 대시보드를 검토한다고 생각해 봅시다. 한 수신자는 120,000개의 메시지를 보고했고, 다른 수신자는 80,000개를 보고했으며, 세 번째는 파일을 전달하지 않았습니다. 일부 행은 정렬된 통과를 보여줍니다. 다른 행은 격리, 거부 또는 로컬 정책 재정의를 보여줍니다. 소유자는 무단 발신자를 찾아내고, DKIM 배포를 복구하고, 더 엄격한 정책이 실행 가능한지 판단할 수 있습니다.

이는 가치 있는 운영 증거입니다. 그러나 메일 스트림의 완전한 센서스와 같은 것은 아닙니다. 대시보드 자체는 어떤 수신자가 보고서를 생성했는지, 어떤 수신자가 그러지 않기로 했는지, 어떤 파일이 유실되거나 캐시되거나 폐기되었는지, 두 파일이 겹치는지, 또는 수치 옆에 표시된 정책이 그 수치의 모든 메시지에 적용된 정책이었는지 증명하지 않습니다.

이 구분은 집계에 대한 반대 논거가 아닙니다. 집계야말로 메시지 콘텐츠를 배포하지 않으면서 인터넷 규모의 보고를 가능하게 하는 것입니다. 실수는 제도적입니다. 소비자가 표준화된 XML 문서를 받으면 표준화를 내면 관찰의 인증처럼 다루기 시작한다는 점입니다.

RFC 9990은 그런 대시보드보다 솔직합니다. 이 규격의 규칙은 해석이 생성자와 소비자에게 남아 있음을 드러냅니다. 그 열린 결정들은 숨겨야 할 결함이 아니라 거버넌스 표면입니다.

표준이 실제로 결합하는 것

2026년 5월에 IETF 표준 트랙으로 발행된 RFC 9990은 DMARC 집계 보고를 정의하고, 더 최신의 DMARC 문서들과 함께 RFC 7489의 보고 부분을 대체합니다. 도메인 소유자는 DMARC 정책 레코드에 보고 목적지를 광고합니다. 메일 수신자는 메시지를 평가하고 XML 보고서를 준비하며, 자격이 있는 목적지로 전달을 시도합니다.

보고서는 보고 조직, Report-ID 및 UTC 날짜 범위를 식별합니다. 정책 도메인에 대해 관찰된 정책 구성을 기록합니다. 행은 발신 IP, 메시지 수, 평가된 처분, 정렬 결과, RFC5322.From 도메인 같은 식별자를 결합합니다. 인증 결과 요소는 DKIM과 SPF 결과를 기술합니다. 수신자가 요청된 처분을 적용하지 않는 경우, 사유는 로컬 정책, 메일링 리스트, 테스트 모드, 신뢰된 포워더 또는 기타 예외를 식별할 수 있습니다.

각 필드는 경계가 있는 질문에 답합니다. 정책 도메인은 어떤 관리 이름이 보고서를 조직했는지 소비자에게 알려줍니다. 날짜 범위는 정확한 첫 메시지와 마지막 메시지가 아니라 집계 기간을 정의합니다. 행 수는 수신자가 하나의 튜플로 묶은 메시지가 몇 개인지 말해줍니다. 정책 재정의 사유는 수신자가 요청된 정책에서 벗어난 것을 어떻게 분류했는지 말해줍니다. 어느 것도 개별 메시지의 전체 경로나 최종 배치에 대한 암호학적 진술이 아닙니다.

또한 표준은 수치가 다른 필터링 에이전트가 최종적으로 전달을 차단하더라도 수신된 메시지를 기준으로 한다고 말합니다. 따라서 집계의 처분은 보편적인 전달 결과로 읽어서는 안 됩니다. DMARC 평가와 수신자의 더 큰 필터링 시스템은 여전히 별개의 제어 평면입니다.

행은 재생 로그가 아니라 압축이다

행은 관련 속성을 공유하는 많은 메시지를 축약하기 때문에 강력합니다. 그 압축 덕분에 도메인 소유자는 패턴을 볼 수 있습니다. 예기치 않은 발신지, 로테이션 이후 실패하는 셀렉터, 정렬 실패를 일으키는 포워딩 경로, 또는 재정의되는 요청 정책.

그러나 압축은 조인을 버립니다. 5,000개의 메시지가 하나의 발신 IP와 인증 튜플을 공유한다면, 집계는 5,000개의 안정적인 이벤트 식별자를 드러내지 않습니다. 그 자체로 어떤 메시지가 첫 번째였는지, 어떤 수신자 등급이 영향을 받았는지, 어떤 별개 필터가 한 메시지를 차단했는지, 어떤 이후 조치가 다른 메시지를 바꿨는지 대답할 수 없습니다. 메시지 본문, 개별 수신자 주소 또는 수신함 배치 증거를 담도록 설계된 것도 아닙니다.

집계가 자동화의 입력이 될 때 이것이 중요해집니다. 시스템이 갑작스러운 수치 증가를 무단 캠페인의 증거로 해석해 발신자를 정지시키거나 정책 변경을 강제할 수 있습니다. 수치는 조사를 정당화할 수 있습니다. 그러나 그것만으로는 인과관계나 완전성을 확립하지 못합니다. 수신자 누락, 변경된 그룹핑 규칙, 지연된 보고서 또는 중복 기간은 발신자의 행동 변화 없이도 그래프를 바꿀 수 있습니다.

증거 대상은 수신자의 평가에 대한 요약된 서술입니다. 관찰된 메일 스트림은 더 큰 대상입니다. 첫째를 둘째라고 부르는 것은 보고서 생성자에게 표준이 부여하는 것보다 더 많은 권위를 조용히 줍니다.

하나의 정책 필드가 혼합 정책 기간을 기술할 수 있다

가장 명확한 경고는 도메인이 보고 기간 중에 DMARC 정책 레코드를 변경할 때 나타납니다. 조회 타이밍, 구현 선택, DNS 전파 때문에 수신자들이 변경을 서로 다른 시점에 관찰할 수 있습니다. RFC 9990은 수신자가 관찰된 구성당 하나씩 여러 보고서를 생성하는 것을 허용합니다. 또한 하나의policy_published요소만 담은 채 이전 정책 하에서 이루어진 처분이나 이전·신규 정책의 혼합을 포함하는 단일 보고서를 생성할 수도 있습니다.

명세는 그 상황에 대한 인식을 Report Consumer와 도메인 소유자에게 맡깁니다. 모든 수신자가 인터넷 규모에서 모든 정책 전환을 지속적으로 추적하도록 요구하는 것은 과중한 부담을 만들 것입니다. 이 절충은 합리적이지만 하나의 결과를 낳습니다. 정책 필드가 그 아래 모든 수치에 대한 시대(epoch) 레이블일 필요는 없다는 것입니다.

도메인이 정오에 모니터링에서 거부로 전환했다고 가정해 봅시다. 보고서는 자정부터 자정까지를 커버하며 최종 구성을 표시합니다. 그 행들 속 일부 실패는 변경 이전에 평가되었을 수 있고, 일부는 이후에 평가되었을 수 있습니다. 별도의 시대 표시나 개별 보고서가 없다면 소비자는 "이 메시지들은 모두 신규 정책 하에서 거부되었을 것"이라는 반사실을 안전하게 계산할 수 없습니다.

거버넌스 대응은 수신자를 비일관성으로 고발하는 것이 아니라, 집계를 혼합 또는 시대 모호로 표시하고 그에 의존하는 결정을 제한하는 것입니다.

인증된 보고서는 인증된 관찰 집합이 아니다

RFC 9990은 DMARC 피드백을 운반하는 메일 스트림이 정렬된 DMARC 통과를 얻도록 요구합니다. 이는 무관한 도메인에서 전송된 위조 보고서를 소비자가 처리할 위험을 줄입니다. 보안 전송도 권장됩니다. 외부 목적지에는 DNS 승인 관계가 필요해, 도메인이 원치 않는 제3자에게 보고서 홍수를 퍼부을 수 없습니다.

이들은 의미 있는 통제이며, 그 적용 범위는 계속 보여야 합니다. 정렬된 통과는 DMARC 하에서 보고 메시지에 대한 도메인 정렬 관계를 인증합니다. 외부 목적지 검증은 Report Consumer가 다른 도메인에 대한 보고서 수신 의사를 표시했다는 것을 증명합니다. TLS는 그 인증 모델에 따라 전송 채널을 보호합니다.

어느 것도 모든 XML 행이 실제 수신된 메시지 집합에 대응한다는 것, 모든 수치가 완전하다는 것, 또는 생성자가 기술된 대로 정확히 정책을 적용했다는 것을 증명하지 못합니다. RFC 9990은 집계 보고서 내부 데이터가 위조될 수 있으며 정책이나 플랫폼 아키텍처 결정에 영향을 주기 위해 대량으로 제출될 수 있다고 명확히 말합니다.

올바른 결론은 모든 집계 보고서가 의심스럽다는 것이 아닙니다. 전송 진위성, 생성자 권위, 콘텐츠 무결성, 관찰적 진실은 서로 다른 주장이라는 것입니다. 소비자는 알려진 수신자의 데이터를 사용할 만큼 충분히 신뢰하면서도 이상 징후 점검을 기록하고 단일 보고서에서 되돌릴 수 없는 조치를 피할 수 있습니다.

Report-ID는 하나의 식별 문제를 해결한다

Report-ID는 같은 도메인에 대한 보고서들 사이에서 고유해야 하므로 소비자가 중복을 인식할 수 있습니다. 이 식별자는 보고서와 전달 맥락에서 일관되게 나타나며, 파일명은 수신자, 정책 도메인, 시간 경계, 그리고 선택적 고유 구성요소를 담습니다. 재전송은 원래 파일명을 재사용해야 합니다.

이 설계는 소비자에게 멱등성의 손잡이를 줍니다. 그러나 부분적 겹침을 수학적으로 제거 가능하게 만들지는 않습니다. RFC 9990은 완전 중복과 보고서에 걸쳐 흩어진 중복 정보를 기술한 뒤, 처리를 수신 소비자에게 맡깁니다. 거부, 폐기, 검사, 수용 또는 기타 로컬로 적절한 조치를 취할 수 있습니다. 부분적으로 겹치는 기간에 대해서는 영향을 구분할 명확한 방법이 없으며, 소비자는 데이터를 전체로 수용하거나 거부해야 할 수 있다고 말합니다.

고유 레이블은 두 파일이 서로 다른 보고서 신원을 주장한다는 것을 증명합니다. 재사용은 재전송을 신호할 수 있습니다. 어느 것도 서로소인 관찰 집합을 보장하지 않습니다. 분석 시스템이 모든 고유 Report-ID를 자동으로 합산한다면, 모호성으로부터 확신과 물량을 만들어낼 수 있습니다.

책임 있는 소비자는 보고서 신원과 겹침 결정을 모두 보존합니다. 결과 수치가 중대한 변경을 정당화할 것이라면 중복 제거는 숨겨진 전처리 세부사항이 아니어야 합니다.

목적지 승인은 분석을 보증하지 않는다

DMARC는 보고서가 도메인 소유자의 조직 도메인 외부의 서비스로 갈 수 있도록 허용합니다. 전문 프로세서를 사용하는 조직에게 이는 필수적입니다. RFC 9990은 외부 목적지가 승인 레코드를 공개하도록 요구합니다. 관계가 확인될 수 없으면 메일 수신자는 그 목적지를 무시해야 합니다.

이는 원치 않는 수신자를 보고서 홍수로부터 보호하고, 철회 가능한 동의 표면을 만듭니다. 그러나 승인은 "이 서비스가 이 도메인에 대한 보고서를 받는다"고 말할 뿐입니다. 그 서비스의 정규화, 귀속, 대시보드, 보존 또는 권고가 올바르다는 말은 아닙니다. 프로세서와의 계약이 도메인 소유자가 증거가 정책 결정이 되는 과정을 이해할 책임을 대신하지도 않습니다.

프로세서는 훌륭한 통제를 갖고 있을 수 있습니다. 요점은 그것들을 별도로 기록하는 것입니다. 어떤 원본 파일이 수용되었는지, 어떤 변환이 적용되었는지, 중복 기간이 어떻게 처리되었는지, 어떤 행이 제외되었는지, 어떤 사람이나 규칙이 최종 결론을 승인했는지.

프라이버시는 메일을 재구성하려는 유혹을 거부함으로써 보존된다

집계 보고는 의도적으로 메시지 콘텐츠와 개별 사용자 특성을 생략합니다. 이는 노출을 제한하면서 도메인 소유자에게 도메인 수준의 인증 증거를 줍니다. 그럼에도 수신자 트래픽 패턴은 민감할 수 있고, 중개자는 다른 정책의 지배를 받을 수 있으며, Public Suffix 보고는 피드백 누출을 만들 수 있습니다.

더 나은 감사 기록은 이 최소화를 무너뜨려서는 안 됩니다. 이벤트 수준 증명이 없다는 문제의 답은 모든 메시지 본문을 수집하는 것이 아닙니다. 대부분의 거버넌스 결정에서 소비자에게 필요한 것은 서신이 아니라 출처와 결정 메타데이터입니다.

영수증은 파일 다이제스트, 생성자 도메인, 정책 도메인, 보고 기간, 정책 시대 상태, 수용된 행 집합 다이제스트, 수치 총계, 이상 결과 및 결정을 담을 수 있습니다. 로컬 파트, 수신자 주소, 메시지 콘텐츠, 수신함 배치는 생략할 수 있습니다. DMARC 운영을 위해 발신 IP가 필요한 곳에서는 접근과 보존을 제한하고, 모든 하류 대시보드에 복제하지 않을 수 있습니다.

프로세서 자체도 보고서를 적대적 입력으로 다루어야 합니다. GZIP과 XML 파서는 자원 고갈 위험에 직면합니다. 구문적 수용과 증거적 수용은 분리되어야 합니다. 파일이 파싱 가능하더라도 신원, 겹침 또는 정책 맥락이 해결되지 않으면 격리될 수 있습니다.

집계 의존 영수증을 유지하라

Daniel Kade의 제안은 집계가 결정의 증거가 될 때 생성되는 작은 기록입니다. RFC 9990의 요구사항이 아니며 보고서 형식을 바꾸지도 않습니다.

첫째, 수신된 산출물을 묶습니다. 정확한 Report-ID, 원래 파일명, 파일 다이제스트, 크기, 미디어 처리, 수신 시각, 인증된 전송 결과를 담습니다. 보고 조직과 그것을 수용할 때 사용한 신원 근거를 기록합니다.

둘째, 주장된 범위를 보존합니다. 정책 도메인, UTC 시작과 끝, 생성자, 보고서 스키마 버전, 기간이 완전한지, 지연되었는지, 부분적이라는 것이 알려져 있는지 여부를 담습니다. 보고서의 날짜 범위를 수집 시각으로 조용히 대체하지 마십시오.

셋째, 정책 맥락을 서술합니다.policy_published값, 소비자가 이용할 수 있는 조회 또는 구성 증거, 기간이 이전과 신규 정책 시대를 모두 포함할 수 있는지를 기록합니다. 상태가 혼합이거나 알려지지 않았다면, 모든 행을 최종 정책에 배정하는 대신 레이블을 붙입니다.

넷째, 중복 처리를 기록합니다. 식별자, 파일명, 생성자, 정책 도메인 또는 겹치는 기간을 공유하는 보고서들을 연결합니다. 거부, 교체, 병합, 수용 또는 격리의 결정과 그 책임 있는 규칙이나 검토자를 보존합니다.

다섯째, 변환을 묶습니다. 수용된 행 집합 또는 정규화된 데이터셋을 해시하고, 파서와 정규화 버전을 식별하고, 거부된 행 수를 보존하고, 무시된 확장을 기록합니다. 대시보드는 전체 메시지 스트림을 보존하지 않고도 안정적인 변환으로 역추적 가능해야 합니다.

여섯째, 점검과 불확실성을 보존합니다. 형식이 잘못된 입력, 생성자 평판, 수치 불연속, 예기치 않은 발신지, 상충하는 보고서, 누락된 예상 보고자, 의심스러운 물량. 이들은 지표이며 자동적인 사기 판정이 아닙니다.

마지막으로, 의존 결정을 기록합니다. 조사, 발신자 연락, 키 로테이션, 정책 변경, 보류, 거부, 롤백 또는 대체. 책임 있는 역할, 임계값, 증거 번들, 정정 경로를 명명합니다. 이후의 보고서가 그 이전 결정이 당시에 합리적이었던 이유를 지워서는 안 됩니다.

영수증은 집계에 정확히 그것이 획득한 권위만을 부여합니다. 덜지도, 더도 않습니다.

증거의 한계

확인된 출처는 표준화된 필드, 보고 의미론, 혼합 정책 허용, 중복 모호성, 외부 목적지 검증, 프라이버시 경계, 위조 데이터 경고를 확립합니다. 이들은 몇 개의 수신자가 RFC 9990을 구현하는지, 특정 조직이 부정확한 보고서를 보내는지, 부분적 겹침이 얼마나 자주 발생하는지, 또는 어느 상업 분석 시스템이 가장 신뢰할 만한지를 확립하지 않습니다.

이 글은 집계 보고서가 단순한 의견이라고 주장하지 않습니다. 그것은 운영 관찰자의 구조화된 증거입니다. 이 글은 DMARC 통과가 약하다거나, 외부 프로세서가 신뢰할 수 없다거나, 메시지별 보존이 바람직하다고 주장하지도 않습니다. 더 좁은 주장은, 수신자의 표준화된 집계는 여전히 수신자의 서술이라는 것입니다. 중대한 의존에는 그 서술에서 정책 시대, 겹침 처리, 변환, 결정까지의 보이는 조인이 필요합니다.

출처