제품 팀은 DKIM 설정을 어떻게 안전하게 구현해야 하나요?

키를 생성하기 전에 실제 발신 경로를 모두 파악하기

DNS 레코드가 아니라 인벤토리부터 시작하세요. 조직의 표시 From 도메인으로 메일을 발신할 수 있는 모든 시스템(애플리케이션 워커, 트랜잭션 제공업체, 마케팅 플랫폼, 지원 도구, ID 시스템, 티켓 소프트웨어, 릴레이, 비상 경로)을 나열하세요. 각각의 소유자, 메시지 클래스, 엔벨로프 발신자, 표시 From 도메인, 현재 DKIM d= 도메인, 셀렉터, 서명 구성 요소, 이후 릴레이가 메시지를 수정하는지를 기록하세요. 한 제공업체에 게시된 DKIM 키는 비공개 키를 사용하지 않는 다른 경로에는 작동하지 않습니다. 검증된 도메인 하나를 표시하는 일반 제공업체 대시보드도 모든 테넌트, 리전, 스트림, 템플릿, 대체 경로의 서명을 증명하지 않습니다. 모든 경로에서 제어된 샘플을 수집하고 원본 헤더를 보존하세요. 서명을 활성화하기 전에 승인된 경로를 결정하세요. DKIM은 서명에 대한 도메인의 책임을 인증할 뿐 수신자 동의나 메시지 내용의 진실성을 인증하지 않습니다.

DMARC 정렬을 지원하는 서명 도메인 선택하기

DKIM의 d= 태그는 서명 도메인을 나타냅니다. 조직이 제어할 수 있고 메일 스트림의 수명 동안 관리할 수 있는 도메인을 선택하세요. DMARC가 DKIM에 의존할 때는 d= 도메인이 적용되는 relaxed 또는 strict 정렬 규칙에 따라 보이는 RFC 5322 From 필드의 도메인과 정렬되어야 합니다. 제공업체 소유의 서명 도메인은 유효한 DKIM 결과를 내더라도 조직의 From 도메인과는 정렬되지 않을 수 있습니다. 소유권, 평판 분리, 위임된 DNS, 사고 격리를 고려해 스트림마다 루트 도메인이 서명할지 용도별 서브도메인이 서명할지 결정하세요. 평판이나 정책 문제를 피하려고 도메인을 임의로 늘리지 마세요. 조직 도메인 관계와 의도한 DMARC 모드를 기록하세요. 정렬은 최종적으로 수신된 헤더로 테스트하세요. 메시지가 다른 d= 값을 쓸 수 있으므로 셀렉터 조회만으로 추정해서는 안 됩니다.

셀렉터를 운영상의 ID로 할당하기

셀렉터는 도메인이 여러 키를 게시하고 전역 레코드 하나를 교체하지 않고 키를 변경하게 합니다. 시크릿을 노출하지 않으면서 제공업체 또는 서명자와 교체 세대를 식별하는 결정적 셀렉터 정책을 만드세요. 예를 들어 product-a-2026q3는 default보다 명확할 수 있지만 DNS 규칙과 도구 한도 내에서 이름을 유지하세요. DNS 레코드를 줄이기 위해 관련 없는 제공업체, 환경, 테넌트 간에 비공개 키 하나를 재사용하지 마세요. 셀렉터, d= 도메인, 목적, 서명 서비스, 소유자, 생성 시간, 알고리즘, 공개 키 지문, 배포 상태, 교체 기한, 폐기 증거가 있는 레지스트리를 유지하세요. 게시 전 정확한 이름을 확인하세요. 조회는 `selector._domainkey.signing-domain`입니다. 표시 From 도메인, return-path 도메인, 잘못된 DNS 영역의 레코드는 의도한 서명을 검증하지 않습니다. 이전 셀렉터로 서명된 지연 메일과 재시도가 만료될 때까지 이전 셀렉터를 삭제하지 마세요.

개인 키 생성 및 보호하기

제공업체가 지원한다면 관리형 키 서비스 또는 엄격하게 통제되는 서명 시스템 안에서 키 쌍을 생성하세요. 개인 키는 공개 DNS, 소스 관리, 브라우저 코드, CI 출력, 분석, 일반 로그, 티켓, 문서, 프롬프트, 공유 채팅에 절대 들어가서는 안 됩니다. 서명 권한은 키가 필요한 메일 구성 요소에만 부여하고, 프로덕션과 하위 환경을 분리하고, 관리자 접근을 기록하세요. RFC 8301은 DKIM 암호 요건을 갱신하면서 서명하는 쪽이 최소 1024비트 RSA 키를 사용해야 하고 최소 2048비트를 사용하는 것이 좋다고 명시하며, 더 큰 키에 따르는 운영상의 DNS 제약도 언급합니다. 오래된 예제를 그대로 따라 하지 말고, 선택한 서명자와 수신자 집단의 현재 기능과 권고를 사용하세요. Ed25519를 고려한다면 RFC 8463이 DKIM에서의 사용을 정의하지만, 상호 운용성을 테스트해야 하며 필요한 곳에는 호환 가능한 서명 전략을 유지해야 합니다. 교체는 개인 키를 내보내지 않고도 가능해야 합니다.

공개 키를 정확하게 게시하기

정확한 `selector._domainkey.signing-domain` 소유자 이름에 TXT 레코드를 게시하세요. DKIM 키 레코드에는 v=DKIM1, 필요한 경우 키 유형, 비공개 키 래퍼 없는 공개 키 자료를 포함하는 p= 등의 태그가 있습니다. 서명자의 정확한 레코드 형식과 DNS 제공업체의 따옴표 동작을 따르세요. 저장 전 DNS 인터페이스가 영역을 자동 추가하거나 긴 문자열을 분할 또는 이스케이프하는지 확인하세요. 게시 후 권한 있는 네임 서버에 직접 조회한 뒤 독립 재귀 리졸버에도 조회해 전체 TXT 값을 재구성하세요. 한 TXT 레코드의 여러 문자열은 DNS 클라이언트가 연결하지만 경쟁하는 여러 리소스 레코드는 모호성을 만들 수 있습니다. 롤백을 위해 이전 응답과 TTL을 보존하세요. 검사기를 조용하게 하려고 더 광범위한 키를 게시하거나 프로덕션에 테스트 플래그를 남겨 보안을 낮추지 마세요. 표시되는 레코드는 DNS 게시만 증명하며 발신자가 일치하는 비공개 키를 쓴다는 뜻은 아닙니다.

최종 서명자와 서명 필드 구성하기

최종 메시지를 발신 전송 계층에 넘기는 구성 요소에서 서명을 설정하거나, 이후 어떤 구성 요소도 서명된 내용을 바꾸지 않도록 하세요. DKIM 서명은 본문 해시와 h=에 명시된 헤더 필드를 다룹니다. RFC 6376은 유효한 서명을 위해 From 헤더 필드가 서명되도록 요구합니다. 제품에 적합한 ID 핵심 헤더를 포함하고, 반복되는 헤더가 어떻게 선택되는지 이해하고, 필요한 다운스트림 시스템이 다시 써야 하는 필드는 그 변환을 통제할 수 없는 한 서명 대상에서 제외하세요. 정규화 방식은 의도를 갖고 선택하세요. relaxed 정규화는 정해진 공백과 헤더 서식 변경을 허용하지만 임의의 본문 수정은 허용하지 않습니다. simple 정규화는 더 깨지기 쉽습니다. 서명 이후의 푸터 삽입, 링크 재작성, MIME 경계 변경, 전송 인코딩 변환, 제목 태그, 줄 끝 정규화는 검증을 깨뜨릴 수 있습니다. 승인된 변환을 마친 뒤 완전히 렌더링된 메시지에 서명하고, 신뢰할 수 없는 사용자가 d=, s=, 헤더 목록, 키를 선택하지 못하게 하세요.

수신된 원본 메시지를 처음부터 끝까지 검증하기

팀이 운영하는 외부 테스트 메일함으로 실제 프로덕션과 같은 모든 경로에서 통제된 메시지를 발송하세요. 본문을 복사하거나 티켓 첨부 파일로 다시 직렬화한 것이 아니라 원본 메시지를 그대로 보존하세요. DKIM-Signature의 d=와 s= 값, 서명된 헤더 목록, 본문 해시, 알고리즘, 정규화 방식, 타임스탬프, 만료 시각을 확인하세요. 독립적인 네트워크에서 공개 키를 조회하고 표준을 준수하는 검증기로 원본 바이트를 검증하세요. RFC 8601의 신뢰 경계를 지키면서, 신뢰할 수 있는 수신자의 Authentication-Results 헤더를 자체 검증기의 결과와 비교하세요. 일반 텍스트, multipart alternative, 예상되는 첨부 파일, 유니코드 제목, 긴 헤더, 템플릿, 추적 변환, 재시도, 릴레이 경로를 테스트하세요. 부정 테스트에는 픽스처에서 서명된 헤더를 의도적으로 바꾸는 경우, 없는 셀렉터, 만료되었거나 폐기된 셀렉터, 서명을 건너뛰는 경로가 포함되어야 합니다. 테스트를 위해 실제 고객 메일을 조작하지 마세요.

DKIM, DMARC, 전달을 별개의 결과로 평가하기

DKIM 통과는 검증자가 서명된 필드와 본문에서 식별된 서명 도메인의 유효한 서명을 찾았다는 뜻입니다. 서명되지 않은 모든 헤더, 사람 작성자, 수신자 동의, 법적 준수, 수락이나 받은편지함 도달을 인증하지 않습니다. DMARC는 통과한 DKIM 또는 SPF 도메인이 표시 From 도메인에 정렬되는지 별도로 평가하고 도메인 소유자의 정책을 적용합니다. 제어된 테스트에 DKIM 결과와 사유, d= 도메인, 셀렉터, 표시 From 도메인, 정렬 결과, SPF 결과, DMARC 결과, 수신자, 타임스탬프를 기록하세요. 일상 지표에는 전체 수신자 주소와 콘텐츠를 포함하지 마세요. SMTP 제공업체 접수, 수신 서버 접수, 이후 반송, 메일함 폴더 배치, 참여는 이후 상태입니다. DKIM이 통과해도 메일이 거부되거나 필터링되면 키를 반복 교체하지 말고 DMARC 정렬, SPF, IP 및 도메인 평판, 스팸 신고율, 메시지 정책, 속도, 수신자 지침을 조사하세요.

검증 공백 없이 키 교체하기

셀렉터를 겹쳐서 사용하세요. 먼저 보호된 새 키를 생성하고 새 셀렉터 아래에 공개 레코드를 게시합니다. 신뢰할 수 있는 DNS와 재귀 DNS를 검증하고, 서명자가 새 셀렉터를 사용하도록 구성한 다음, 모든 경로에서 통제된 테스트를 발송하세요. 이전 셀렉터와 새 셀렉터를 사용하는 서명의 비율과 검증 결과를 모니터링하세요. 큐에 남은 메시지의 최대 보관 기간, 재시도 기간, DNS 캐시 기간에 명시적인 안전 여유를 더한 시간 동안 이전 공개 키를 유지하세요. 그런 다음 이전 셀렉터로의 모든 서명을 중단하고, 어떤 활성 구성도 이를 참조하지 않는지 확인하고, 정책에 따라 해당 레코드를 폐기하세요. 개인 키 노출 후의 긴급 폐기에는 더 빠른 제거, 트래픽 일시 중지, 제공업체 자격 증명 교체, 사고 커뮤니케이션이 필요할 수 있으므로 이러한 상충 관계를 미리 문서화하세요. 정기 교체 중에는 하나의 셀렉터를 제자리에서 덮어쓰지 마세요. 캐시된 이전 공개 키로는 새 개인 키로 서명한 메시지의 검증이 실패할 수 있습니다.

서명에서 바깥쪽으로 실패 원인 진단하기

서명이 없다면 메시지가 서명되지 않는 스트림, 승인되지 않은 From 도메인, 대체 릴레이, 템플릿 경로 중 어느 것을 사용했는지 확인하세요. 키를 찾을 수 없다면 정확한 s=와 d= 조회, 영역 위임, 신뢰할 수 있는 응답, DNSSEC 또는 리졸버 오류, 전파를 확인하세요. 본문 해시가 불일치하면 서명 전과 수신된 원본 MIME을 비교해 서명 이후의 변환을 찾으세요. 서명이 불일치하면 게시된 공개 키가 활성 개인 키와 일치하는지 확인하고 정규화 방식과 서명된 헤더를 살펴보세요. DKIM은 통과하는데 DMARC가 실패하면 보이는 From 도메인과의 정렬을 평가하세요. 일시적인 DNS 조회 오류는 지속적인 구성 오류와 구분해 분류하고, SMTP 응답이 일시적일 때만 상한이 있는 전송 재시도를 사용하세요. 다른 도메인으로의 서명, 알 수 없는 키, 광범위한 검증 실패, 키 노출 의심이 있다면 영향받는 스트림을 일시 중지하세요. 개인정보를 최소화한 증거를 보존하고, 통제된 재테스트에서는 한 번에 하나의 변수만 바꾸세요.

발송 시스템의 DKIM 문서 사용

실제 발송 시스템과 DNS 권한에서 DKIM을 설정하고 원본 수신 메시지를 검증하며 최신 IETF 표준과 제공업체별 문서를 따르세요.

자주 묻는 질문

출처

• RFC 6376: DKIM(DomainKeys Identified Mail) 서명 — RFC Editor
• RFC 8301: DKIM 암호 알고리즘 및 키 사용 갱신 — RFC Editor
• RFC 8463: DKIM을 위한 새로운 암호 서명 방식 — RFC Editor
• RFC 7489: 도메인 기반 메시지 인증, 보고 및 준수(DMARC) — RFC Editor
• RFC 8601: 메시지 인증 상태를 나타내는 메시지 헤더 필드 — RFC Editor
• RFC 5321: 단순 메일 전송 프로토콜(SMTP) — RFC Editor