DKIM 셀렉터 없음: dkim=none 진단

Problem

수신 서버가 당신 메일을 받아 DKIM-Signature 헤더에서 s= 셀렉터를 읽고, selector._domainkey.yourdomain에서 공개 키를 조회합니다 — 그런데 아무것도 없습니다. 서명을 검증할 키가 없으니 DKIM은 실패한다기보다 아예 돌지 않습니다. Authentication-Results 헤더는 dkim=none으로 돌아오고, DMARC 정렬은 SPF 혼자 감당할 수 있는 수준으로 떨어지며, 메일은 내용과 무관한 이유로 스팸함에 들어가기 시작합니다.

이건 이메일 옷을 입은 DNS 문제입니다. 메시지의 서명은 멀쩡할 가능성이 높습니다. 그걸 증명할 레코드가 수신 서버가 보는 곳에 없을 뿐입니다.

Symptoms

• 발송 플랫폼은 DKIM을 켰다는데 Authentication-Results는 dkim=none으로 나온다.
• DKIM 검사기가 “no DKIM record found”, 또는 더 헷갈리게 “레코드는 등록됨 — 못 찾음”이라고 한다.
• 메인 플랫폼 메일은 인증되는데, 두 번째 발송원(CRM, 티켓 시스템, 뉴스레터 도구)은 DKIM이 전혀 없다.
• DMARC 리포트에서 특정 소스 IP의 dkim이 none/fail이고 SPF는 통과한다.
• DNS 제공업체 대시보드엔 키가 보이는데, 외부 조회는 빈 결과를 돌려준다.

”셀렉터 없음”이 실제로 뜻하는 것

DKIM은 개인 키로 메시지에 서명하고, 짝이 되는 공개 키를 어디서 찾을지를 서명 안의 두 태그로 알려줍니다: d=(도메인)와 s=(셀렉터). 수신 서버는 이 둘로 이름 하나를 만들고 — <셀렉터>._domainkey.<도메인> — 단일 DNS TXT 조회를 합니다. 원하는 답은 v=DKIM1; k=rsa; p=<base64 공개 키> 형태의 레코드입니다.

“셀렉터 없음”은 그 한 번의 조회가 빈 결과로 돌아왔다는 뜻입니다. RFC 6376은 그다음 동작을 명확히 규정합니다: 키가 없으면 검증 가능한 서명이 없으므로 결과는 fail이 아니라 none입니다. 이 구분이 중요한 이유는 둘이 정반대 방향을 가리키기 때문입니다. fail은 “키는 찾았는데 서명이 안 맞았다” — 본문을 망가뜨린 게 뭔지 보라는 뜻이고, none은 “키를 아예 못 찾았다” — DNS를 보라는 뜻입니다. 사람들은 레코드가 엉뚱한 이름에 앉아 있을 뿐인데도 본문 해시 귀신을 몇 시간씩 쫓습니다.

Top 3 Causes

1. 서명의 셀렉터가 등록된 레코드와 불일치. 수신 서버는 서명의 s= 값을 정확히 그대로 조회합니다. 플랫폼이 s=selector1로 서명하는데 당신은 default._domainkey를 등록했다면 조회는 빗나갑니다. 키를 교체하거나 새 발송 서비스를 추가할 때도 물립니다: 새 셀렉터가 레코드 등록 전에 메일에 서명하거나, 옛 셀렉터 레코드를 지웠는데 메일이 여전히 그걸 참조하는 경우죠. 확인법: 실제 DKIM-Signature 헤더의 s= 태그를 읽고, 바로 그 이름을 조회하세요.
2. 도메인 중복 덧붙임(UI 함정). 존 이름을 이미 자동으로 덧붙이는 DNS 패널에 selector._domainkey.example.com을 입력해서, 레코드가 조용히 selector._domainkey.example.com.example.com에 생성됐습니다. 대시보드엔 레코드가 보이고, 올바른 이름을 조회하는 수신 서버는 빈 결과를 받습니다. “등록했는데 못 찾음”의 가장 흔한 원인이며, FQDN을 직접 확인하지 않으면 보이지 않습니다.
3. 깨졌거나 전파 안 된 CNAME 위임. 발송 업체가 키를 자기네가 관리하도록 CNAME을 추가하게 했습니다(SES, SendGrid, M365, Mailchimp 모두). 그 CNAME에 오타가 있거나, 잘못된 타깃을 가리키거나, 아직 전파 안 됐거나, DNS 정리 중에 지워졌다면 리졸버는 막다른 길로 따라 들어갑니다. 빠진 TXT와 달리 이건 설정된 것처럼 보입니다 — CNAME이 버젓이 있으니까요 — 하지만 그게 가리키는 사슬이 아무것도 없는 곳으로 끝납니다.

Diagnose with DechoNet

• 이메일 점검은 수신 서버처럼 DKIM을 조회해, 당신 도메인의 흔한 셀렉터에 대해 실제로 키가 풀리는지 알려줍니다 — “레코드 없음”인지 “레코드는 있는데 서명이 깨짐”인지 한눈에 구분할 수 있습니다.
• DNS 점검으로 정확한 <셀렉터>._domainkey.<도메인> 이름을 TXT로 조회하고(제공업체가 위임을 쓰면 CNAME도 따라갈 수 있습니다), 수신 서버가 쓰는 바로 그 이름에서 빈 응답이 나오면 그게 결정적 단서입니다 — 대시보드가 숨기는 도메인 중복 덧붙임 케이스도 잡아냅니다.
• 이메일 헤더 분석기는 수신된 메시지의 실제 Authentication-Results를 읽어, 당신 메일이 실제로 어떤 s= 셀렉터로 서명됐는지 보여줍니다 — 추측이 아니라 그 이름을 조회해야 합니다.

Resolution Checklist

• 수신된 메시지를 열어 DKIM-Signature 헤더를 읽는다. 정확한 s=(셀렉터)와 d=(도메인) 값을 확인 — 당신 생각이 아니라 메일이 실제로 주장하는 것을 조회한다.
• <셀렉터>._domainkey.<도메인>을 TXT로 직접 조회한다. 비어 있으면 레코드가 수신 서버가 보는 곳에 없는 것 — 그게 문제다, 여기서 끝.
• 도메인 중복 함정 확인: FQDN에 존 이름이 두 번이 아니라 정확히 한 번 들어갔는지 본다. 제공업체가 도메인을 덧붙인다면 selector._domainkey만 입력한다.
• 발송 업체가 CNAME 위임을 쓰면, CNAME이 존재하고 오타 없이 상대편 TXT까지 풀리는지 확인한다. 있지만 잘못 가리키는 CNAME은 레코드가 없는 것과 똑같이 실패한다.
• 키 교체 후엔, 메일이 새 셀렉터로 서명을 시작하기 전에 그 레코드가 살아 풀리는지 확인하고, 트래픽이 옮겨가기 전엔 옛 셀렉터를 지우지 않는다.
• 발송원이 여러 개라면 각각 자기 셀렉터 레코드를 갖췄는지 확인한다. 셀렉터 하나가 동작한다고 다른 서비스가 서명한 메일까지 커버되진 않는다.

When to Escalate

• 셀렉터 레코드가 올바르고 풀리는데도 dkim=none이 계속된다면, 문제는 서명 쪽으로 올라간 것입니다: 발송 플랫폼이 DKIM-Signature를 애초에 안 붙이고 있는 거죠. 그건 DNS가 아니라 이메일 서비스의 설정이니, 그 발송원을 관리하는 쪽에 넘기세요.
• DNS 존을 직접 통제하지 못하고(관리형 호스트, 레지스트라 기본 존, 당신에게 위임하는 상위 도메인) 요구되는 정확한 이름에 레코드나 CNAME을 만들 수 없다면, DNS 운영자가 변경해야 합니다 — 당신이 관리하지 않는 권한 레코드는 덮어쓸 수 없습니다.