2026년 5월 1일 IETF가 표준화 트랙 문서(Proposed Standard) 세 건을 발행했습니다. 두 건은 전자우편 도메인 인증 정책인 DMARC 관련 문서로, 기존 RFC 7489(와 RFC 9091)를 대체하는 본 규격과 집계 보고(Aggregate Reporting) 규격입니다. 나머지 한 건은 자식 영역이 부모 쪽 위임 정보(DS, NS)를 자동으로 갱신하도록 요청할 때 쓰는 CDS/CDNSKEY·CSYNC 레코드가 '일관된' 상태인지 판단하는 조건을 정한 문서이며, RFC 7344와 RFC 7477을 갱신합니다.
한눈에 보기
| RFC 번호 | 제목 | 종류 | 대체·갱신하는 RFC | 적용 대상 |
|---|---|---|---|---|
| RFC 9989 | 도메인 기반 메시지 인증·보고·준수(DMARC) 본 규격 | 표준 제안 (Proposed Standard) | RFC 7489, RFC 9091 대체 | 메일 도메인 운영자, 메일 수신 서버 |
| RFC 9990 | DMARC 집계 보고(Aggregate Reporting) 규격 | 표준 제안 (Proposed Standard) | RFC 7489 대체 | DMARC 보고서를 받아 분석하는 운영자 |
| RFC 9975 | CDS/CDNSKEY·CSYNC 일관성 조건 명확화 | 표준 제안 (Proposed Standard) | RFC 7344, RFC 7477 갱신 | 하위 영역 권한 서버 운영자, 레지스트리·레지스트라 |
건별 내용
RFC 9989: 도메인 기반 메시지 인증·보고·준수(DMARC)
DMARC(Domain-based Message Authentication, Reporting, and Conformance)는 메일의 From 헤더 도메인, 곧 작성자 도메인(Author Domain) 소유자가 DNS TXT 레코드로 인증 정책을 게시하고, 검증에 실패한 메일의 처리 방식과 보고서 수신을 요청할 수 있게 하는 프로토콜입니다. 이 TXT 레코드를 DMARC 정책 레코드(DMARC Policy Record)라고 합니다. DMARC 검증을 통과하려면 발신자 정책 프레임워크(SPF)나 도메인키 식별 메일(DKIM) 검증을 통과해야 하고, 그 도메인이 작성자 도메인과 '정렬(aligned)'되어야 합니다. 정렬 방식은 조직 도메인(Organizational Domain)만 같으면 되는 relaxed와 도메인이 완전히 같아야 하는 strict 가운데 도메인 소유자가 고릅니다. 원문은 DMARC를 통과했다고 해서 그 메일이 안전하다는 뜻은 아니며, 수신 측이 도메인 소유자가 요청한 처리 방식이나 보고서 발송을 반드시 따라야 하는 것은 아니라고 설명합니다. 이 문서로 RFC 7489와 RFC 9091은 폐기(obsolete)됩니다.
RFC 9990: DMARC 집계 보고(Aggregate Reporting)
도메인 소유자는 DNS 레코드에 지정한 수신처로 수신 측의 집계 보고서를 받아 볼 수 있으며, 보고서는 나중에 다른 종류의 데이터를 덧붙일 수 있는 확장형 XML 문서입니다. 보고서에는 발견해 적용한 DMARC 정책, 선택된 메일 처리 결과, SPF·DKIM이 평가한 식별자와 그 결과, 정렬 여부, 메시지 수 등이 담길 수 있습니다. 보고는 하루 단위나 그보다 더 자주 이루어지며, 보고 기간에 만난 DMARC 정책 도메인마다 보고서를 따로 만들어야 하고(MUST) 보고서 하나에는 정책 도메인 하나의 데이터만 담아야 합니다(MUST). 이 문서도 RFC 7489를 대체합니다.
RFC 9975: CDS/CDNSKEY와 CSYNC 일관성에 대한 명확화
자식 영역은 CDS/CDNSKEY 레코드(RFC 7344)로 바라는 DS 값을, CSYNC 레코드(RFC 7477)로 바라는 NS·글루 갱신을 게시하고, 레지스트리·레지스트라 같은 부모 측 주체는 이를 조회해 위임 정보를 갱신합니다. 권한 서버 한 곳에서만 이 레코드를 가져오면 키 서명 키(KSK) 롤오버 중이거나 다중 서명자(multi-signer) 구성처럼 권한 서버 사이에 레코드가 다를 때, 서버 하나가 혼자서 위임의 DS나 NS를 바꿀 수 있습니다. 원문은 다중 서명자 구성에서 사업자 한 곳이 실수로든 고의로든 다른 사업자의 신뢰 앵커나 네임서버를 위임에서 빼 버릴 수 있다는 예를 듭니다. 그래서 이 문서는 부모 측 주체가 이 레코드를 근거로 조치하기 전에, 자식 영역의 여러 권한 서버에서 가져온 갱신 요청이 일관된지 확인하도록 정합니다.
운영자가 할 일
- 메일 도메인을 운영하는 경우: 게시 중인 DMARC 정책 레코드(TXT)와 SPF·DKIM 설정을 RFC 9989 기준으로 다시 검토하세요. 기존 문서로 인용하던 RFC 7489·9091은 이제 폐기된 문서입니다.
- DMARC 집계 보고서를 받아 분석하는 경우: 보고서 처리 도구가 RFC 9990의 보고서 형식을 지원하는지 확인하세요. 원문은 집계 보고서를 자기 도메인을 도용하는 발신원을 찾는 데뿐 아니라 자기 쪽 인증 설정의 빈틈을 찾아 고치는 데 쓰라고 권합니다.
- CDS/CDNSKEY·CSYNC를 게시하는 경우: 모든 권한 서버가 같은 CDS/CDNSKEY·CSYNC 레코드를 응답하는지 확인하세요. 특히 KSK 롤오버 중이거나 여러 DNS 사업자를 함께 쓰는 다중 서명자 구성이라면, 서버 사이에 레코드가 다를 때 부모 측이 갱신을 진행하지 않을 수 있습니다.
- 위임 정보를 갱신하는 부모 측(레지스트리·레지스트라)인 경우: 자식 영역의 권한 서버 한 곳만 조회해 DS·NS를 갱신하고 있지 않은지 점검하고, RFC 9975의 일관성 요건에 맞춰 처리 절차를 고치세요.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.