[ DKIM ]

전송 중인 메일에 대한 확인을 잃지 않고 DKIM 키 순환

새 키 게시, 서명 컷오버, 중복 및 폐기를 분리하고 실제 수신된 메시지가 무엇을 사용하는지 확인합니다.

EmailAuth 연구팀 제공 · 5분 읽기

[ 핵심사항 ]

  • 서명자를 전환하기 전에 새로운 확인 자료를 게시하십시오.
  • 정당한 전환 기간 동안 이전 선택기와 새 선택기를 계속 사용할 수 있습니다.
  • 일상적인 순환과 별도로 침해 대응을 처리합니다.
이 페이지에서

계획된 DKIM 순환은 이미 전송 중인 메시지에 필요한 확인 자료를 보존하면서 개인 키가 새 메일에 서명하는 방식을 변경합니다. 새 공개 키 게시, 서명자 전환 및 이전 공개 키 폐기 선택자 별도의 단계입니다.

서명 서비스와 지원되는 교체 절차부터 시작하세요. 공급자 관리 선택기 위임은 조직에서 직접 제어하는 ​​키 쌍과 다른 운영 모델을 갖습니다.

현재 서명 상태 설정

수신된 원본 메시지를 사용하여 실제 d= 서명 도메인과 s= 선택자를 식별합니다. 서명 서비스, 키 관리 모델 및 비즈니스 소유자와 연관시키십시오.

DNS 레코드는 현재 메시지에서 사용되지 않고 존재할 수 있습니다. 반대로, 이전 메시지는 더 이상 새 메일에 대한 활성 선택이 아닌 선택기를 참조할 수 있습니다.

관련 공개 답변 및 구성 상태를 저장합니다. 티켓, 인벤토리 스프레드시트 또는 공개 DNS 레코드가 아닌 승인된 서명 시스템에 개인 서명 키를 보관하세요.

알고리즘 및 공급자 요구 사항 확인

현재 암호화 지침과 지원되는 확인 동작을 검토하세요. RFC 8301 §3 rsa-sha1을 제외하고 RSA 키 크기 요구 사항을 설정합니다. 최소 2048비트의 RSA 키를 권장합니다. RFC 8463 §5 Ed25519-SHA256을 추가 방법으로 정의합니다.

알고리즘의 사양과 관련된 발신자, 제공자, 수신자의 실제 지원은 서로 다른 증거입니다. 지원되는 구성에서 사용할 수 없는 방법으로 프로덕션 서비스를 변경하지 마십시오.

공급자 관리 서명의 경우 생성된 값과 순환 프로세스를 따릅니다. DNS 별칭은 팀에 개인 키를 제공하거나 수동 전환 제어를 제공하지 않고도 키 관리를 위임할 수 있습니다.

컷오버 전 새로운 검증 자료 게시

지원되는 디자인이 새로운 선택기를 사용하는 경우 먼저 올바른 공개 검증 자료를 게시하세요. 최종 소유자 이름, 답변 및 위임 체인을 확인하세요.

지원되는 절차에서 허용하는 경우 새 키에 대해 다른 선택기를 사용하십시오. 하나의 선택기에서 키를 교체하면 교체 키를 확인할 수 없는 이전 키로 서명된 메시지가 남을 수 있습니다.

새 DNS 응답이 정확해 보인다는 이유만으로 이전 키를 제거하지 마십시오. 이 단계에서는 서명자가 전환되었거나 모든 수신자가 의도한 자료를 검색할 수 있는 것이 아니라 출판을 설정했습니다.

서명 전환 및 새 메시지 확인

승인된 서명 절차를 사용하여 새 키로 서명을 시작합니다. 중요한 경로를 통해 대표 메시지를 보내고 원본 수신 서명과 신뢰할 수 있는 결과를 검사합니다.

합성 순환에서 이전 메일은 s=old2026 사용하고 새 메일은 s=new2026. 계획된 중복 기간 동안 두 공개 확인 이름 모두 계속 사용할 수 있으며, 새로 수신된 메시지는 의도한 선택기와 통과 서명을 보여줍니다.

게이트웨이가 서명 후 메시지를 수정하는 경우 해당 게이트웨이 이전의 직접 테스트는 완료되지 않습니다. 전체 사업경로를 확인하고 DMARC 조정 원시 서명 결과도 마찬가지입니다.

배송조건에서 폐기 선택

RFC 6376 §3.1 메일이 아직 전송 중일 수 있는 전환 중 동시 게시에 대해 설명합니다. 모든 조직에 대해 하나의 보편적인 중복 기간을 제공하지는 않습니다.

대기열, 재시도 동작, 예상되는 배달 지연, DNS 캐시 동작, 관련 서명 만료 및 확인 요구 사항을 평가합니다. 선택한 중복 이유와 공급자 제약 조건을 기록합니다.

해당 평가가 정당한 경우에만 지원 프로세스에 따라 기존 검증 자료를 폐기하십시오. 나중에 저장된 메시지를 확인하면 키 폐기 후 원래 배달 시간 결과와 다를 수 있습니다.

의심되는 손상을 다른 결정으로 처리

일상적인 순환은 연속성을 목표로 합니다. 개인 키 손상이 의심되는 경우 오래된 메일에 대한 잠재적 확인 영향에도 불구하고 긴급 제한 또는 폐기가 필요할 수 있습니다.

조직의 사고 프로세스와 서명 제공업체의 지원되는 대응을 따르세요. 증거를 보존하고 절충안을 설명하십시오. 적극적인 타협 중에는 일상적인 유지 관리에 적합한 중복이 적합하다고 약속하지 마십시오.

확인 가능한 서명 기록으로 마감

서비스, ​​소유자, 이전 및 새 선택자, 게시 증거, 컷오버 관찰, 중복 근거, 폐기 결정 및 담당자 수신 결과를 유지합니다.

그만큼 선택 가이드 신원 조회에 대해 설명합니다. Microsoft 365 또는 Workspace의 경우 테넌트별 또는 선택된 도메인 구성 지침. 새 서명 경로가 확인되고 문서화된 이유로 이전 종속성이 폐기되면 순환이 완료됩니다.

세 가지 별도의 승인 확인을 사용하세요.

이 제안된 체크리스트는 기록 회전이 완료된 것입니다. 컷오버 전에 이전 선택기를 계속 사용할 수 있는 동안 새 선택기가 생성된 공개 값으로 확인되는지 확인하세요. 컷오버 후 새로 수신된 애플리케이션 메시지에는 s=new2026 및 신뢰할 수 있는 패스가 포함된 의도된 d 도메인이 표시되어야 합니다. 종료하기 전에 합의된 대기열/재시도 및 확인 조건이 충족되었는지 확인하고 결정을 기록합니다. 관련되지 않은 애플리케이션의 패스는 영향을 받는 경로를 닫지 않습니다. 예시 간격을 범용 대기 시간으로 바꾸지 마세요.

[ 테이크아웃 ]

서명자를 전환하기 전에 새로운 확인 자료를 게시하십시오. 정당한 전환 기간 동안 이전 선택기와 새 선택기를 계속 사용할 수 있습니다. 일상적인 순환과 별도로 침해 대응을 처리합니다.

[ 역할별 ]

이것이 당신에게 의미하는 바

실용적인 다음 단계를 위해 역할을 선택하세요.

IT/메일 관리자

출판, 서명, 폐기를 별도로 추적합니다.

사용 가능한 DNS 레코드가 현재 사용을 나타낸다고 가정하는 대신 실제 서명 ID와 지원되는 키 관리 모델을 사용하십시오.

다음 단계

  1. 컷오버 전에 새 선택기를 확인하세요.
  2. 최종 게이트웨이 이후에 테스트합니다.
  3. 문서 중복 및 폐기 조건.

CISO/SecOps

키 보관 및 균형을 검토합니다.

계획된 연속성과 침해 대응에는 다른 결정이 필요할 수 있습니다. 각 단계의 소유권, 액세스 제어 및 증거가 필요합니다.

다음 단계

  1. 개인 키 관리 책임을 검토합니다.
  2. 검증 증거의 보유를 평가합니다.
  3. 침해 에스컬레이션 경로를 확인하세요.

창립자 / 비기술자

중요한 메일의 연속성이 필요합니다.

순환에는 비즈니스에 필요한 메시지에 대한 소유자와 테스트 계획이 있어야 하며, 손상이 의심되는 경우 뚜렷한 대응이 있어야 합니다.

다음 단계

  1. 중요한 워크플로를 식별합니다.
  2. 변경 및 에스컬레이션 소유권에 동의합니다.
  3. 컷오버 후 메시지 수신 결과를 요청합니다.

[ 자주 묻는 질문 ]

자주 묻는 질문

새 키가 게시되는 즉시 이전 선택기를 삭제해야 합니까?

아직 전송 중인 메일과 기타 확인 종속성을 평가하지 않고 정기적인 순환을 수행하는 것은 아닙니다. 출판, 서명 중단 및 폐기는 별도의 단계입니다.

RFC 6376 §3.1

새 키에 새 선택기를 사용하는 이유는 무엇입니까?

전환 중에 이전 검증 자료와 새 검증 자료를 구별할 수 있도록 유지합니다. 동일한 선택기 아래의 키를 바꾸면 나중에 이전 메시지를 해석하기가 복잡해질 수 있습니다.

RFC 6376 §3.1

보편적인 DKIM 중복 기간이 있나요?

여기에는 보편적인 지속 기간이 규정되어 있지 않습니다. 배달 대기열, 재시도, DNS 캐싱, 서명 조건, 공급자 제어 및 조직의 확인 요구 사항을 고려하세요.

새 DNS 키는 서명이 전환되었음을 증명합니까?

아니요. 실제 서비스에서 새로 수신된 메시지를 검사하고 선택자, 서명 도메인 및 신뢰할 수 있는 확인 결과를 확인하세요.

공급자 관리 순환은 무엇을 따라야 합니까?

공급자가 현재 생성한 값과 지원되는 프로세스를 사용합니다. 위임된 키 관리에는 직접 운영되는 서명과 다른 제어 및 제한이 있을 수 있습니다.

폐기된 키가 저장된 메시지 확인에 영향을 미칠 수 있나요?

예. 이후 확인 시도는 배송 시 사용 가능했지만 이후 변경되거나 제거된 DNS 자료에 따라 달라질 수 있습니다. 배송 시간 증거를 보존합니다.

RFC 6376 §3.1 RFC 6376 §6.1.2

의심되는 손상은 일반 유지 관리 중복을 사용해야 합니까?

그렇게 가정하지 마십시오. 사고 대응에는 다른 연속성 균형을 고려한 긴급 조치가 필요할 수 있습니다. 승인된 절차를 따르고 증거를 보존하십시오.

계획된 순환이 완료되었음을 증명하는 것은 무엇입니까?

게시 및 컷오버 증거, 실제 경로 전달 서명 및 조정, 중복 근거, 폐기 결정 및 책임 있는 서비스 소유권을 유지합니다.

[ 출처 ]

출처

  1. RFC 6376

    섹션 §1 · §2.1 · §3.1 · §3.5 · §6.1.2 · §8.3

  2. RFC 8301

    섹션 §3

  3. RFC 8463

    섹션 §5 · §6

  4. RFC 9989

    섹션 §4.1 · §4.4

  5. RFC 1034

    섹션 §3.6 · §4.2

[ 어휘 ]

어휘

DMARC
인증된 이메일 ID를 작성자 도메인 및 해당 정책과 연결하는 메커니즘입니다.

RFC 9989 §4.1

조정
인증된 식별자와 DMARC 에 따른 작성자 도메인 간의 필수 관계입니다.

RFC 9989 §4.4

신뢰할 수 있는 DNS
캐시된 확인자 응답과 구별되는 영역의 데이터 제공을 담당하는 DNS 서버입니다.

RFC 1034 §4.2

DKIM
수신자가 공개 키 데이터로 확인하는 선택된 메시지 헤더 및 본문 콘텐츠에 대한 도메인 관련 서명입니다.

RFC 6376 §1

선택자
DKIM 공개 확인 데이터를 찾기 위해 서명 도메인과 함께 사용되는 s 값입니다.

RFC 6376 §3.1

기업 출처

최고의 금융 기관과 정부가 필요한 이유 이메일 보안 대시보드를 폐기했습니다.

기존 이메일 인증 플랫폼은 대시보드를 판매하고 엔지니어에게 작업을 요청합니다. 위험이 높은 환경에서 수동 감독은 시행 지연, 구성 드리프트 및 모니터링되지 않는 섀도우 도메인을 의미합니다.

EmailAuth 는 에이전트 이메일 출처 플랫폼입니다. 우리 대리인은 집행합니다 p=reject, 제3자 발신자를 정렬하고 도메인을 전체로 이동하세요. RFC 9989 인간 참여형 감사 기능을 갖춘 새로운 DMARC 표준을 준수합니다.

정부 대기업 1등급 금융기관

SaaS · 전용 테넌시 · Air-Gapped 온프레미스 · BYOK 암호화

기술 자료