Defaults.Exposed › 수정 › Guides
DKIM "서명에 키 없음": 셀렉터 및 키 교체 수정 방법 (2026)
게시일 2026-07-08
2026-06-29 기준 수치 · 방법론 v7. 261백만 개의 평가된 도메인에 대한 집계 데이터. 평가 방식 보기.
“No key for signature”는 수신자가 DKIM 서명이 가리키는 DNS 레코드 — selector._domainkey.yourdomain — 를 조회했는데 키가 없었다는 의미입니다: 게시된 적이 없거나 교체 중에 삭제되었습니다. 서명자가 실제로 사용하는 셀렉터를 게시하세요. Defaults.Exposed의 261,086,232개 평가 도메인 센서스에 따르면 10,092,481개 도메인 — 3.87% — 만이 SPF+DKIM+DMARC 트리아드를 완성합니다.
수정은 DNS 레코드 하나로, 헤더 하나에서 찾을 수 있습니다. 실제 DKIM-Signature 헤더에서 s= 및 d= 태그를 읽어 메일이 어떤 셀렉터로 서명되었는지 파악하고, 정확히 그 레코드를 게시(또는 수정)하고, 공급자가 키를 교체해주도록 CNAME 위임을 선호하세요. 그런 다음 아래 절차에 따라 교체하세요 — 이 오류는 보통 누군가가 이전 셀렉터를 너무 일찍 삭제했다는 의미입니다.
”dkim no key for signature”는 무슨 의미인가요?
모든 DKIM 서명에는 수신자에게 공개 키를 어디서 가져올지 알려주는 두 태그가 있습니다: d=(서명 도메인)와 s=(셀렉터). 수신자는 이 두 값으로 구성된 하나의 DNS 이름 — s._domainkey.d — 을 키 조회에 사용합니다. “No key for signature”는 그 조회가 빈 결과를 반환했다는 의미입니다: 서명은 있지만 서명이 가리키는 키가 없습니다.
이 문구는 Authentication-Results 헤더와 DMARC 집계 보고서에 나타납니다 — 정확한 표현은 수신자마다 다르지만 두 가지 유형이 중요합니다:
| 결과 문자열 (조각, 널리 관찰됨) | 실제로 일어난 일 | 일시적? |
|---|---|---|
dkim=temperror (no key for signature) | DNS 쿼리가 실패하거나 시간 초과 — 수신자가 응답을 전혀 받지 못함 | 예 — 재시도하면 통과하는 경우 많음; 지속될 경우만 조사 |
dkim=permerror (no key for signature) | DNS 쿼리 성공 후 “해당 레코드 없음” 응답 — 셀렉터가 진짜로 없음 | 아니오 — 게시할 때까지 레코드 없음 |
일회성 temperror는 DNS 날씨와 같습니다. permerror — 또는 여러 날과 여러 수신자에 걸쳐 반복되는 temperror — 는 서명이 가리키는 레코드가 영역에 없다는 의미입니다. 이 가이드가 다루는 내용입니다.
결과: 검증할 수 없는 서명은 DKIM이 없는 것과 같으므로, DMARC는 SPF에만 의존하게 됩니다 — 그리고 SPF는 전달(forwarding) 시 깨집니다. 서명이 없는 것이 아니라 유효하지 않은 경우(본문 해시, 훼손된 키)는 다른 오류입니다 — “DKIM 서명이 유효하지 않음”을 참조하세요.
내 메일이 어떤 셀렉터로 서명되었는지 어떻게 찾나요?
공급자 문서에서 추측하지 말고 — 실제 메시지에서 읽으세요:
- 영향받는 시스템에서 제어하는 사서함으로 메시지를 보냅니다(Gmail 주소가 잘 작동합니다).
- 원시 소스를 엽니다(Gmail의 “원본 보기”, Outlook의 “메시지 소스 보기”).
DKIM-Signature:헤더를 찾아 두 태그를 읽으세요:s=는 셀렉터,d=는 서명 도메인입니다. 예시:DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...- 수신자가 조회하는 레코드는
s._domainkey.d— 여기서는mail2026._domainkey.yourdomain.com입니다. 직접 확인하세요:dig TXT mail2026._domainkey.yourdomain.com +short. 빈 응답 = 모든 수신자에게 오류가 실제로 존재합니다. - 발송 시스템마다 반복하세요. 메시지에는 여러 DKIM 서명이 있을 수 있습니다 — 사서함 공급자, 뉴스레터 도구, 헬프데스크 — 각각 자체
s=/d=쌍과 레코드가 있습니다. 실패하는 것을 수정하고,d=를 확인하세요: From 도메인과d=가 일치하는 서명만 DMARC에 도움이 됩니다.
셀렉터 레코드가 없는 이유는 무엇인가요?
네 가지 원인이 거의 모든 오류를 차지합니다 — 이 순서로 확인하세요:
- 게시된 적이 없음. 아무도 DNS에 추가하지 않은 셀렉터로 서명자가 켜졌습니다(또는 기본값으로 켜졌습니다). 예상치 못하게 서명하는 새 도구 및 게이트웨이에서 흔합니다.
- 교체 중 삭제됨. 누군가 이전 셀렉터로 서명된 메시지가 아직 전송 중이거나 재시도 대기 중이거나 전달 대기 중인 동안 이전 셀렉터를 “정리”했습니다. 그 메일은 이미
s=old로 서명되어 있습니다;old._domainkey를 삭제하면 그 메시지 모두가 소급하여 깨집니다. - DNS UI가 CNAME 대상을 훼손함. 많은 공급자가 CNAME으로 위임합니다(
s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), 많은 DNS 패널이 대상에 영역을 자동 추가합니다 —s1.domainkey.u123.esp.com.yourdomain.com을 저장하는데, 이는 아무것도 해석되지 않습니다. 대상을 확인하세요:dig CNAME s1._domainkey.yourdomain.com +short. 같은 문제가 도구 마이그레이션 중에도 발생합니다 — 이메일 도구 변경 후 DKIM 실패 참조. - 공급자가 교체했는데 영역이 업데이트 안 됨. 정적 TXT 레코드로 붙여넣은 공급자 키(CNAME 대신)는 공급자의 예정된 교체로 고아가 됩니다 — 서명자가 게시하지 않은 셀렉터로 이동합니다. 센서스의 261백만 개 도메인 중 51.84%만이 스캔 시점에 검색 가능한 DKIM 키를 제시합니다(2026-06-29 기준 데이터).
“no key for signature”는 어떻게 수정하나요?
- DNS를 건드리기 전에 defaults.exposed에서 무료 스캔을 실행하세요. 실제 DKIM, SPF, DMARC 레코드를 읽고 수신자가 실제로 보는 것을 보여줍니다 — 셀렉터가 해석되는지, CNAME 대상이 훼손되었는지 포함.
- 서명자가 실제로 사용하는 셀렉터를 게시하세요 — 이전 가이드에 있는 것이 아니라 헤더의
s=값으로. 공급자 관리 콘솔에서 레코드를 가져와(Google Workspace DKIM 설정 · Microsoft 365 DKIM 설정) 정확히s._domainkey.yourdomain.com에 추가하세요. - TXT 키를 붙여넣기보다 CNAME 위임을 선호하세요. 공급자가 DKIM CNAME을 제공하면 사용하세요: 키가 공급자 영역에 있으므로 다시 DNS를 건드리지 않아도 교체합니다 — 원인 4가 불가능해집니다. 뉴스레터 플랫폼은 거의 모두 이 방식으로 작동합니다; Mailchimp/Brevo/Klaviyo 이메일 DMARC 실패 참조.
- 패널 외부에서 확인하세요. 네트워크 외부의 기기에서
dig TXT s._domainkey.yourdomain.com +short(또는 위임된 셀렉터의 경우dig CNAME …). 패널에서 레코드가 표시된다고 해서 영역이 다른 내용을 서빙하는 것이 아니라는 의미가 아닙니다. - 재스캔 및 테스트 메시지 재발송.
Authentication-Results에 이제dkim=pass가 표시되어야 합니다. 그런 다음 DKIM 수정 페이지에서 스캔이 표시한 다른 항목을 처리하세요 — From 도메인과 정렬되지 않는 통과 서명은 여전히 DMARC에 실패합니다.
DKIM 키를 이 오류 없이 교체하려면 어떻게 해야 하나요?
교체는 작동 중인 설정이 깨지는 곳입니다. 이를 방지하는 규칙: 셀렉터는 그것으로 서명된 마지막 메시지가 소진된 후에만 삭제합니다 — 절대 전환 시점에 삭제하지 마세요. 서명된 메일은 생각보다 오래 살아있습니다: 재시도 큐는 며칠 동안 실행되고, 전달된 메시지는 이동할 때마다 재검증됩니다.
| 단계 | 조치 | 다음 단계 전 조건 |
|---|---|---|
| 1. 추가 | 이전 셀렉터 옆에 새 셀렉터(s2._domainkey…) 게시 | 외부에서 dig으로 해석됨을 확인 |
| 2. 전환 | 서명자를 새 셀렉터로 변경 | 테스트 메시지에서 s=s2 및 dkim=pass 표시 |
| 3. 대기 | 전송 중, 대기 중, 전달 중인 트래픽이 소진될 동안 이전 셀렉터를 게시 상태로 유지 | ≥ 7일; DMARC 집계 보고서에서 이전 셀렉터 표시가 멈출 때까지 감시 |
| 4. 폐기 | 이전 키 제거 — 또는 더 좋게는 빈 p= 태그로 재게시: “존재한 적 없음”이 아닌 “폐기됨” | 절대 전환 시점에 시작하지 마세요 — 조기 삭제는 “no key for signature”의 #1 원인 |
CNAME 위임에서는 공급자가 자체 영역 내에서 이 절차를 정확히 실행하므로 여러분은 보이지 않습니다 — 위임하는 가장 강력한 이유입니다.
자주 묻는 질문
“no key for signature”는 temperror인가요, permerror인가요?
두 문자열 모두 존재합니다: temperror는 실패하거나 시간 초과된 DNS 조회 — 일시적, 재시도 시 사라지는 경우 많음 — 이고 permerror는 DNS가 “해당 레코드 없음”을 응답했다는 의미입니다. 여러 수신자에 걸쳐 반복되는 temperror는 대개 진짜 누락된 레코드이기도 합니다. dig로 확인하고 레이블이 아닌 응답을 신뢰하세요.
이 오류는 누군가 내 도메인을 사칭하고 있다는 의미인가요? 아닙니다 — 사칭자는 내 셀렉터로 서명하지 않을 것입니다. 내 메일이 수신자가 검증할 수 없는 서명을 가지고 있어 서명이 없는 것과 같으며 DMARC가 SPF에만 의존하게 된다는 의미입니다. 완전한 정렬 인증은 드뭅니다: Defaults.Exposed 센서스에서 261,086,232개 도메인 중 10,092,481개(3.87%)만이 SPF+DKIM+DMARC 트리아드를 완성했습니다(2026-06-29 기준 데이터).
새 셀렉터가 작동하면 이전 셀렉터를 바로 삭제해도 되나요?
즉시는 안 됩니다. 그것으로 서명된 메시지가 재시도 큐와 전달 경로에 여전히 있습니다; 키를 삭제하면 소급하여 깨집니다. 이전 레코드를 최소 일주일 유지하고, 이전 셀렉터 표시가 멈출 때까지 DMARC 보고서를 감시한 후 폐기하세요 — 삭제보다 빈 p=가 이상적입니다.
공급자 검사기에서 DKIM이 설정되어 있다고 하는데 수신자는 여전히 키 없음을 보고합니다. 왜 그런가요?
거의 항상 CNAME 대상 함정입니다: DNS 패널이 대상에 영역을 추가했습니다(…esp.com.yourdomain.com), 레코드는 존재하지만 아무것도 가리키지 않습니다. dig CNAME selector._domainkey.yourdomain.com +short가 저장된 대상을 그대로 보여줍니다 — 공급자가 요청한 것과 문자 하나하나 비교하세요.
소유자에게 보고서 전달
클라이언트나 고용주를 위해 수정하는 경우 증거로 마무리하세요. 셀렉터가 해석되면 무료 스캔을 다시 실행하고 등급 보고서를 비즈니스 소유자에게 전달하세요: 날짜 기록, 알기 쉬운 언어, DKIM 이제 검증됨. 사이버 보험 갱신과 다음 공급업체 보안 설문지에 필요한 증거물입니다 — 닫힌 티켓이 아닌 작동하는 통제의 증거.
DKIM 무료 확인
셀렉터가 해석되는지 — 그리고 정확히 무엇을 수정해야 하는지 — 비공개로, 소유자만 확인하세요.
도메인 확인하기 → · “DKIM 서명이 유효하지 않음” → · DKIM 수정 → · Google Workspace에서 DKIM 설정 → · 집계 데이터만 사용합니다. 데이터는 EU에서 저장 및 처리됩니다.