A DKIM 선택기 범위는 서명 도메인으로 지정됩니다. 두 서비스는 서로 다른 d= 도메인에서 "default"라는 단어를 안전하게 사용할 수 있지만 default._domainkey.example.com 은 하나의 DNS 소유자 이름입니다. 두 개의 독립 서비스에 동일한 이름의 서로 다른 키가 필요한 경우 두 번째 서비스를 추가하면 첫 번째 서비스에 대한 확인이 중단될 수 있습니다. DNS 변경하기 전에 소유권 충돌을 해결하세요.
전체 이름을 비교해보세요
각 활성 서비스에서 최근 수신된 서명된 메시지를 수집하고 d= 및 s=. 해당 값을 보류 중인 공급자 설정 지침과 비교하세요. DNS 기반 키 검색의 경우 선택기와 서명 도메인에 따라 조회 이름이 결정됩니다. 설정 화면의 "선택기 1"과 같은 공급자 레이블은 실제 DNS 소유자를 식별하는 데 충분하지 않습니다. RFC 6376 §3.5 그리고 RFC 6376 §3.6.2.1.
예시: 급여 및 마케팅 모두 d=example.com, 사용하여 s=default 요청하지만 각각 다른 개인 키를 보유합니다. 두 서명 모두 검증자를 default._domainkey.example.com 으로 안내합니다. 급여의 공개 키를 마케팅 키로 바꾸면 이미 전송 중인 메시지를 포함하여 급여 메시지를 확인할 수 없게 될 수 있습니다. 반대로 d=payroll.example.com 의 기본값과 d=marketing.example.com 의 기본값은 서로 다른 조회 이름입니다. 조정 의미는 여전히 별도의 확인이 필요합니다.
지원되는 분리 디자인 선택
공급자가 지원하는 경우 독립적인 서명 서비스에 대해 고유한 선택기를 선호합니다. 새 서비스에서 생성된 공개 키 레코드를 자체 소유자 이름으로 게시하고 유효성을 확인한 다음 해당 서명자를 활성화하고 수신된 메일을 테스트합니다. 서비스가 선택기 이름을 수정하는 경우 별도의 서명 하위 도메인이나 문서화된 다른 구성을 지원하는지 물어보세요. 발명하지 마세요 CNAME DNS 에서만 선택기의 대상을 지정하거나 이름을 바꾸십시오. 서명자는 일치하는 s= 값을 내보내야 합니다.
d=를 하위 도메인으로 변경하면 영향을 받을 수 있습니다. DMARC. 하위 도메인은 상위 작성자 도메인과의 엄격한 정렬에 실패하면서 완화된 규칙에 따라 정렬될 수 있습니다. 명명 해결 방법을 선택하기 전에 의도한 관계를 확인하십시오. RFC 9989 §4.4.1 그리고 RFC 9989 §4.10.2.
모호한 핵심 답변에 의존하지 마세요
아래에 RFC 6376 §3.6.2.2, TXT 키 레코드는 선택기 이름에 대해 고유해야 합니다. 다중 레코드 결과는 정의되지 않습니다. 한 소유자가 여러 개의 서로 다른 키를 게시하는 것은 해당 게시 규칙을 위반하는 것이며 서비스 분리 설계가 아닙니다. RFC 6376 에서는 검증자가 반환된 키 하나를 선택하거나 재량에 따라 지정되지 않은 순서로 여러 키를 시도할 수 있습니다. 따라서 하나의 수신기에서 작동하는 구성은 다른 곳에서는 신뢰할 수 없을 수 있습니다. 별도의 선택기는 키 선택 동작에 의존하는 대신 명시적인 매핑을 제공합니다. RFC 6376 §6.1.2.
하나의 TXT 리소스 레코드 내에서 여러 개의 따옴표로 묶인 문자열은 다른 문제입니다. 이는 단일 레코드의 일부일 수 있습니다. 여러 개의 개별 키로 공급자 디스플레이 래핑을 착각하지 마십시오. 적절한 DNS 도구를 사용하여 실제 DNS 응답과 공급자가 생성한 값을 비교합니다.
기존 충돌을 안전하게 처리
충돌이 이미 발생한 경우 현재 DNS , 구성 기록, 영향을 받은 d/s 쌍 및 수신기 오류를 캡처합니다. 안전하고 여전히 필요한 경우에만 이전 매핑을 복원한 다음 지원되는 고유 선택기에서 새 서비스를 온라인으로 가져옵니다. 단지 하나의 공개 기록에 맞추기 위해 관련 없는 서비스 간에 개인 키를 공유하지 마세요. 이는 양육권과 사고 영향을 확대합니다.
보안 고려 사항 및 공급자의 순환 프로세스에 따라 적법한 지연 메일 경로 요구 사항과 중복되는 이전 확인 기록을 유지하십시오. 손상된 키는 다른 경우이며 배달에 미치는 영향에도 불구하고 즉시 취소해야 할 수 있습니다. 변경 후 두 서비스를 독립적으로 테스트하고, 소유자를 기록하고, 선택기 이름을 인벤토리에 예약하세요. 승인 테스트는 단순히 두 개의 녹색 공급자 설정 화면이 아닌 두 개의 검증 가능하고 의도된 ID입니다.
합성 2개 서비스 요청 해결
급여가 현재 s=default 및 d=example.com, 으로 서명하고 마케팅 요청이 다른 키와 동일한 쌍이라고 가정합니다. 조회 소유자는 동일하므로 덮어쓰거나 옆에 두 번째 독립 키를 게시하지 마세요. 마케팅에서 s=marketing2026, 지원하는 경우 생성된 키를 marketing2026._domainkey.example.com 에 게시하고 서명자에서 동일한 선택기를 구성합니다. 그런 다음 급여/기본 및 마케팅/마케팅2026을 독립적으로 테스트합니다. 서명 하위 도메인 옵션만 지원되는 경우 변경하기 전에 정렬을 검토하세요. d. 이는 계획 단계이지 테스트된 공급자 절차가 아닙니다.