교체 기록이 아닌 행동부터 시작하세요
각 구현 결정에 명명된 사양과 책임 있는 소유자가 있으면 표준 마이그레이션을 관리하기 쉬워집니다. DNS 편집기, 조정 엔진과 집계 보고서 파서는 동일한 작업을 수행하지 않습니다. 셋 다 불러"DMARC "지원"은 한 구성 요소가 변경되고 다른 구성 요소가 이전 구현에 남아 있을 때 문제가 되는 종속성을 숨깁니다. 실제 결과물은 전체 자산이 업그레이드되었다는 선언이 아니라 버전, 인터페이스 및 보유된 승인 증거가 포함된 구성 요소-요구 사항 맵입니다.
현재 문서 세트는 2026년 5월에 게시되었습니다. RFC 9989 핵심 메커니즘을 정의하고 더 이상 사용되지 않음 RFC 7489 및 RFC 9091 . RFC 9990 집계 보고를 다룹니다. RFC 9991 오류 보고를 다루고 RFC 6591 도 업데이트합니다. 새로운 RFC 편집자 레코드는 다음을 식별합니다. RFC 9989 그리고 RFC 9990 제안된 표준으로. 게시된 RFC 9991 텍스트는 표준 트랙 범주를 식별합니다. 이는 미완성 초안이 아닌 공개된 사양이지만 공개로 인해 특정 수신자의 구현이 설정되지는 않습니다.
핵심 엔진에 정확한 계약을 제공하세요.
레코드 구문 분석, 정책 검색, 조직 도메인 검색 및 식별자 정렬을 할당합니다. RFC 9989 섹션 4.7–4.10. 작성자 도메인은 메시지의 도메인에서 나옵니다. RFC5322 필드. 검색된 정책 도메인은 해당 작성자 도메인과 다를 수 있으며 조직 도메인 완화된 정렬에 사용되는 또 다른 명시적 출력입니다. 인터페이스에서 이러한 구별을 잃으면 올바른 파서가 잘못된 의사결정 엔진에 피드를 제공할 수 있습니다.
DNS 레코드는 여전히 v=DMARC1. “DMARCbis"는 DMARC2를 개발하기 위한 권한이 아니라 표준 작업에 대한 이름입니다. 현재 검색에서는 과거 공개 접미사 목록 체크리스트를 전체 알고리즘으로 처리하는 대신 제한된 DNS 트리 탐색을 사용합니다. psd, np 및 t 태그에는 별도의 결정 적용 범위가 필요합니다. IANA 레지스트리 pct, rf 및 ri 역사적 표시; 배포된 제품이 이를 무시, 해석 또는 노출하는지 여부는 인증하지 않습니다.
정상적인 DMARC 오류, 사용할 수 없는 DNS 정보, 유효하지 않은 정책 및 수신자의 최종 메시지 처리 간의 차이점을 유지하세요. RFC 9989 섹션 4.10.1에는 구문적으로 유효한 집계 보고서 URI가 남아 있는 경우 잘못된 정책 태그에 대한 특수 처리가 포함되어 있습니다. 단순한 "모든 잘못된 정책은 없음이 됩니다" 규칙은 해당 조건을 지울 것입니다. 그것을 실행하는 파서 케이스 옆에 정확한 섹션을 기록하십시오.
집계 피드백을 자체 구현으로 처리
집계 생성자, XML 유효성 검사기, 보고서 소비자, 중복 처리 및 전달 통합을 매핑합니다. RFC 9990 섹션 3-4 및 부록 A. 보고 인터페이스에는 실제로 평가된 정책, 인증 결과, 메시지 수 및 보고 기간 컨텍스트가 필요합니다. XML을 표시하는 대시보드는 업스트림 수신자가 올바른 정책을 선택했거나 모든 관련 발신자가 데이터에 나타났다는 증거가 아닙니다.
외부 보고서 대상에는 자체 구성 요소 행이 필요합니다. 도착지 인증은 기술적인 남용 방지 점검이지 임의의 조직 데이터 전송에 대한 동의가 아닙니다. 보고서 생성, 대상 확인 및 액세스/보존 결정을 별도의 승인 기준에 따라 설정합니다. RFC 9990 섹션 7에서는 개인 정보 보호를 다루고, 섹션 8에서는 악의적이거나 잘못된 보고 내용에 대해 경고합니다. 따라서 파서 강화 및 소스 신뢰는 스키마 유효성과 함께 맵에 속합니다.
실패 보고서에 집계 파서를 재사용하지 마십시오.
실패 피드백은 공개 위험이 다른 다른 채널입니다. RFC 9991 참조된 인증 실패 보고 사양을 사용하여 생성 및 형식을 관리합니다. ruf 요청 및 fo 조건은 rua 집계와 동일하지 않습니다. 수신자는 실패 보고를 거부할 수 있으며, 실패 보고서 모든 메시지가 통과되었다는 증거는 아닙니다.
실패-보고 통합 시 발생할 수 있는 문제 메시지 헤더 또는 집계 파이프라인이 전달하지 않도록 설계된 콘텐츠. 누가 요청할 수 있는지, 어디로 보낼 수 있는지, 들어오는 자료가 어떻게 보관되는지, 어떤 개인 정보 보호 검토가 적용되는지 확인하세요. 단순히 기능 매트릭스를 완벽하게 보이도록 하기 위해 활성화하지 마십시오. 핵심 참여 요구 사항, 선택적 오류 보고 및 상용 제품의 광고 기능은 서로 다른 증거가 필요한 서로 다른 주장입니다.
가상의 구성 요소 인벤토리를 통해 작업
정책 디코더, 검색 확인자, 정렬 평가자, 집계 작성기, XML 소비자 및 오류 수집기 등 6개 모듈이 있는 가상 서비스를 생각해 보세요. 처음 세 개는 RFC 9989 에 매핑됩니다. 다음 두 개는 주로 RFC 9990 에 매핑됩니다. 수집기는 주로 RFC 9991 에 매핑됩니다. 공유 스토리지 및 보안 제어는 처리하는 모든 보고 경로의 요구 사항을 상속합니다. 이 인벤토리는 EmailAuth 의 아키텍처에 대한 주장이 아닌 원본 문서의 예입니다.
각 모듈에 대해 실제 빌드 식별자, 관련 섹션, 입력/출력 계약, 소유자 및 승인 장치를 유지합니다. 가상의 검색 장치는 선택된 정책과 해당 소스 도메인을 가상의 집계 장치에 전달할 수 있습니다. 보고 행은 표시되는 보낸 사람 도메인을 자동으로 대체하는 대신 해당 구별을 유지해야 합니다. 그런 다음 실패 보고 요청을 도입하고 설계에서 이를 별도로 승인된 처리 경로로 라우팅하는지 확인합니다. 이는 완료된 실행이 아닌 제안된 점검입니다.
상태, 정오표, 배포를 별도로 유지
정확한 커미션은 다음과 같습니다. 모든 구현 구성 요소를 RFC 9989 , 9990 또는 9991에 매핑하고 정오표를 확인합니다. 실제 구현 범위는 제공되지 않았습니다. 현재 정오표 검색이 실패하여 중지되었으므로 이 초안에서는 문서에 정오표가 없다고 주장할 수 없습니다. 해결된 RFC 7489 정오표에 대한 RFC 9989 의 논의는 세 가지 새로운 문서에 대한 새로운 정오표 검사가 아니라 역사적 맥락입니다.
릴리스 전에 구현 소유자는 실제 인벤토리를 조정해야 하고, 표준 소유자는 현재 정오표를 해결해야 하며, 수신기 테스트 소유자는 버전 범위 상호 운용성 증거를 보존해야 합니다. 전문가 검토, 생산 경로 확인, 시각적 승인 및 출판 승인도 계속 열려 있습니다. 오늘날 유용한 결과는 업데이트된 표준을 지원되지 않는 보편적 배포 주장으로 바꾸지 않고 누락된 증거를 노출하는 검토 가능한 지도입니다.