Defaults.Exposed › 수정 › Guides
이메일 도구 변경 후 DKIM 실패: CNAME 및 셀렉터 마이그레이션 가이드 (2026)
게시일 2026-07-08
2026-06-29 기준 수치 · 방법론 v7. 261백만 개의 평가된 도메인에 대한 집계 데이터. 평가 방식 보기.
도구 전환 후 DKIM이 두 가지 기계적인 이유로 깨집니다: DNS 패널이 새 도구의 CNAME 대상을 손상시킨 경우 — 보통 자체 영역을 추가하여 — 또는 이전 도구의 셀렉터가 메일이 소진되기 전에 제거된 경우. Defaults.Exposed의 261,086,232개 평가 도메인 센서스에 따르면 3.87% — 10,092,481개 도메인 — 만이 SPF+DKIM+DMARC 트리아드를 완성합니다.
수정 순서: 도메인을 스캔하고, dig으로 각 새 CNAME의 저장된 대상을 확인하세요 — 자체 도메인 이름으로 끝나는 대상이 결정적인 증거입니다. 권한 있는 네임서버에서 레코드를 수정하고, 실제 메일을 라우팅하기 전에 새 도구가 서명하고 통과하는지 확인하고, 이전 도구의 트래픽이 소진될 때까지 셀렉터를 게시 상태로 유지하세요.
도구를 전환했는데 DKIM이 왜 깨졌나요?
DKIM 자체에 대한 것은 아무것도 변경되지 않았습니다 — 셀렉터가 변경되었습니다. 이전 도구는 자체 셀렉터로 서명했습니다; 새 도구는 다른 셀렉터로 서명합니다. 보통 온보딩 중에 추가된 두세 개의 CNAME 레코드를 통해 위임됩니다. 네 가지 함정이 거의 모든 마이그레이션 후 DKIM 실패를 설명합니다:
- DNS 패널이 CNAME 대상에 영역을 추가했습니다. 많은 패널이 붙여넣은 호스트명을 상대적으로 처리하여
target.provider.com대신target.provider.com.yourdomain.com을 조용히 저장합니다. 레코드는 존재하고, 패널은 녹색 체크를 보여주며, 아무것도 해석되지 않습니다. - 후행 점 혼란. 일부 패널은 “절대적 — 영역 추가 중단”을 의미하는 후행 점(
target.provider.com.)이 필요합니다; 다른 것들은 점을 유효하지 않다고 거부하고 절대성을 자체적으로 처리합니다. 같은 붙여넣기 값이 한 패널에서는 올바르고 다음 패널에서는 손상됩니다. - 이전 도구의 셀렉터가 전환 당일 삭제되었습니다. 이전 도구가 이미 서명한 메일이 재시도 큐와 전달 경로에 며칠 동안 있습니다; 셀렉터를 제거하거나 이전 계정을 닫으면 — 위임된 CNAME이 죽음 — 그 메일을 소급하여 깨뜨립니다.
- 잘못된 네임서버에서 확인했습니다. 마이그레이션에 네임서버 변경이 포함된 경우, 수정된 레코드가 하나의 NS 세트에는 존재하지만 수신자가 여전히 다른 것을 쿼리합니다.
센서스의 261백만 개 도메인 중 51.84%만이 스캔 시점에 검색 가능한 DKIM 키를 제시합니다(2026-06-29 기준 데이터).
같은 마이그레이션은 보통 SPF 잔재도 남깁니다 — 1,013,416개 도메인, SPF를 시도하는 도메인의 약 138개 중 1개로, 두 개의 v=spf1 레코드를 실행합니다. 공급자 전환이 하나를 병합하는 대신 레코드를 추가한 전형적인 징후입니다. 이동의 그 부분에는 자체 가이드가 있습니다: 이메일 공급자 전환 후 SPF 작동 중단.
손상된 CNAME 레코드를 어떻게 발견하나요?
패널을 믿지 마세요 — DNS에 실제로 저장된 것을 물어보세요. 새 도구가 제공한 각 셀렉터의 CNAME 대상을 쿼리하세요. SendGrid 스타일 위임 셀렉터를 흉내낸 예시(공급자의 대상 모양은 다를 수 있습니다):
$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.
공급자는 s1.domainkey.u1234567.wl123.sendgrid.net을 요청했는데 — 저장된 대상이 **.yourdomain.com**으로 끝납니다. 패널이 영역을 추가했습니다; 그 이름은 아무것도 해석되지 않으므로 수신자가 키를 찾지 못합니다. 정상 버전:
$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.
(dig 출력의 단일 후행 점은 정상입니다 — 완전한 이름을 표시합니다.) 대상이 올바르면 한 홉 따라가세요: dig TXT s1._domainkey.yourdomain.com +short가 공급자의 키를 반환해야 합니다. 올바른 CNAME이 있는데 빈 응답이면 문제가 위임의 공급자 쪽에 있습니다 — 검증 단계를 완료하거나 셀렉터 수준 진단은 DKIM “no key for signature”를 참조하세요.
마이그레이션 절차: 전, 중, 후
실패는 보통 레코드가 아닌 순서에 있습니다. DKIM 마이그레이션은 실제 메일이 이미 실패하고 있을 때 확인이 전환 후에 이루어지기 때문에 전환 시점에 잘못됩니다.
| 단계 | 할 일 | 다음으로 넘어가기 전 조건 |
|---|---|---|
| 전환 전 | 새 도구의 DKIM CNAME(및 반송 도메인 레코드)을 추가하고, 증명하세요: 네트워크 외부에서 dig으로 각 CNAME의 저장된 대상을 확인하고, 도구 자체 확인 단계를 완료하고, 새 도구를 통해 제어하는 사서함으로 테스트를 보내세요 | 테스트 메시지에 d= = 도메인인 dkim=pass 표시 — 검증되지 않은 도구로 절대 실제 메일을 라우팅하지 마세요 |
| 전환 당일 | 실제 트래픽을 새 도구로 이동. 이전 도구에 속한 것은 아무것도 건드리지 마세요: 셀렉터, CNAME, 계정을 살아있게 두세요 | 새 도구의 메일이 실제 수신자에서 통과; 이전 도구는 여전히 흐르는 것에 대해 계속 통과 |
| 소진 후 | 이전 도구의 셀렉터가 나타나지 않을 때까지 DMARC 집계 보고서를 감시하고(재시도 큐와 전달은 며칠 동안 실행 — 일주일 이상 허용), 레코드와 계정을 의도적으로 폐기하세요 | 제거 전 ≥ 7일 동안 보고서에서 이전 셀렉터 없음 |
굵은 행이 마이그레이션이 살거나 죽는 곳입니다: 그 안의 모든 확인은 전환 며칠 전에 할 수 있으며 실제 메일에 위험이 없습니다. 셀렉터 폐기 방법 — 빈 p=로 재게시가 삭제보다 나은 이유 포함 — 은 교체 절차에서 다루고 있습니다; 이 표는 도구 전환 자체의 순서 지정에 관한 것입니다.
전환 후 DKIM을 어떻게 수정하나요?
- DNS를 건드리기 전에 defaults.exposed에서 무료 스캔을 실행하세요. 실제 레코드를 읽고 수신자가 실제로 보는 것을 보여줍니다 — 영역 추가된 CNAME 대상과 해석되지 않는 셀렉터 포함.
- 새 도구가 예상하는 DKIM 레코드를 나열하세요. 관리 콘솔에서 — 사서함 공급자의 경우 Google Workspace와 Microsoft 365 설정 가이드에서 어디를 확인할지 보여줍니다; 뉴스레터와 CRM 도구는 도메인 인증 아래에 CNAME을 나열합니다(Mailchimp/Brevo/Klaviyo 이메일 DMARC 실패 참조).
dig CNAME <name> +short로 각 레코드의 저장된 값을 확인하고 도구가 요청한 것과 문자 하나하나 비교하세요. 자체 도메인으로 끝나는 대상 = 영역 추가됨; 다시 입력하고, 패널이 계속 추가하면 후행 점을 추가하세요(또는 패널이 점을 거부하면 제거하세요).- 권한 있는 네임서버에서 확인하세요.
dig +short NS yourdomain.com, 그런 다음@<해당 네임서버>에서 CNAME 확인을 반복하세요. 마이그레이션에서 네임서버가 변경되었다면 두 세트 모두 확인하세요 — 수신자가 위임이 전파될 때까지 이전 것을 쿼리할 수 있습니다. - 도구 확인을 다시 실행하고 테스트 메시지를 보내세요.
Authentication-Results헤더에 도메인과 같은d=와 함께dkim=pass가 표시되어야 합니다 — 도구의 기본 도메인에서의 통과는 DMARC를 정렬하지 않습니다. - 메일이 소진될 때까지 이전 도구의 셀렉터를 게시 상태로 유지하고, 의도적으로 폐기하세요. 그런 다음 재스캔하고 DKIM 수정 페이지에서 표시된 다른 항목을 처리하세요.
자주 묻는 질문
DKIM CNAME에 후행 점이 필요한가요, 아닌가요?
전적으로 패널에 달려 있습니다. 점은 “절대 이름 — 영역 추가 안 함”을 의미합니다; 일부 패널은 필요하고, 일부는 추가하고, 일부는 거부합니다. 중요한 유일한 테스트는 저장 후 dig CNAME <selector>._domainkey.yourdomain.com +short의 출력입니다: 대상이 자체 도메인으로 끝나면 패널이 영역을 추가한 것이며 점이 필요합니다(또는 다른 입력 형식).
전환 당일 이전 도구의 DKIM 레코드를 삭제해도 되나요? 아닙니다. 이전 도구가 서명한 메일이 재시도 큐와 전달 경로에 여전히 있으며, 가리키는 키를 삭제하면 그 메시지를 소급하여 깨뜨립니다. DMARC 집계 보고서에서 나타나지 않을 때까지 이전 셀렉터를 활성화 상태로 유지하세요 — 일주일 이상 — 그 전에 이전 계정도 닫지 마세요.
DNS 패널과 새 도구 모두 “검증됨”이라고 하는데 수신자는 여전히 DKIM에 실패합니다. 왜 그런가요? 두 가지 일반적인 경우: 도구가 권한 있는 네임서버가 다른 것을 서비스하는 동안 캐시된 확인에 대해 검증했거나, DKIM이 통과하지만 도메인이 아닌 도구의 기본 서명 도메인에서 통과하여 DMARC가 여전히 정렬에 실패합니다. 스캔이 두 가지를 구분합니다.
겹치는 동안 두 도구의 DKIM 레코드가 공존할 수 있나요?
예 — 그리고 그래야 합니다. DKIM에는 단일 레코드 규칙이 없습니다: 각 셀렉터는 자체 DNS 이름이므로 두 도구의 레코드가 충돌 없이 나란히 있을 수 있으며, 이전 셀렉터를 소진될 때까지 유지하는 규칙을 따르기가 자유롭습니다. (SPF는 정반대입니다 — 두 개의 v=spf1 레코드는 무효화합니다. 따라서 SPF 마이그레이션 가이드는 병합에 관한 것입니다.)
소유자에게 보고서 전달
클라이언트나 고용주를 위해 이 마이그레이션을 실행하는 경우 증거로 마무리하세요. 새 도구가 서명하고 정렬되면 무료 스캔을 다시 실행하고 등급 보고서를 비즈니스 소유자에게 전달하세요: 날짜 기록, 알기 쉬운 언어로 전환이 도메인을 완전히 인증 상태로 남겼다는 증거. 사이버 보험 갱신과 다음 공급업체 보안 설문지를 위한 증거물입니다 — “마이그레이션이 완료되었습니다”를 주장이 아닌 문서로 전환합니다.
DKIM 무료 확인
새 도구의 셀렉터가 해석되는지 — 그리고 정확히 무엇을 수정해야 하는지 — 비공개로, 소유자만 확인하세요.
도메인 확인하기 → · 공급자 전환 후 SPF 깨짐 → · DKIM 수정 → · Google Workspace에서 DKIM 설정 → · 집계 데이터만 사용합니다. 데이터는 EU에서 저장 및 처리됩니다.