보내는 모든 이메일에는 그 메일이 내 도메인에서 발송되었음을 증명하는 보이지 않는 서명이 붙어 있으며, DKIM 셀렉터는 이 서명을 검증하는 데 쓰이는 키가 어디에 있는지 수신 메일 서버에 알려 주는 짧은 이름입니다. 셀렉터는 모든 메시지와 함께 전달되므로, 내 도메인에서 보내 받은편지함에 도착한 메시지의 헤더, 발송 플랫폼의 설정, DNS 레코드, DMARC 보고서 등 네 곳에서 찾을 수 있습니다.
이 가이드에서는 가장 빠른 확인 방법부터 도메인이 사용하는 모든 셀렉터를 한 번에 보여 주는 방법까지, 네 가지 방법을 모두 설명합니다. 글의 끝에서는 찾은 셀렉터가 제대로 작동하는지 알려 주는 두 가지 확인 방법을 다룹니다.
DKIM(DomainKeys Identified Mail)은 이메일에 보이지 않는 서명을 붙이는 방식을 정의한 표준입니다. 내 도메인 명의로 이메일을 보내는 서비스는 각 메시지에 개인 키로 서명하고, 수신 서버는 DNS에 게시된 공개 키로 그 서명을 확인합니다. 한 도메인이 여러 개의 키를 게시할 수 있기 때문에 어떤 키로 확인할지를 지정하는 이름이 필요하며, 이 이름이 DKIM 셀렉터입니다.
셀렉터는 DKIM-Signature 헤더의 s= 태그에 들어 있습니다. 다음은 이 헤더를 줄여서 나타낸 예시입니다.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2025; ...
이 예시에서 셀렉터는 mail2025입니다. 수신 서버는 이 셀렉터를 도메인과 결합해 mail2025._domainkey.example.com의 DNS 레코드를 조회하고, 그 레코드에서 공개 키를 가져옵니다.
셀렉터 이름은 문자와 숫자로 된 단순한 문자열이며, 서명을 설정한 사람이 정합니다. 실제로 쓰이는 셀렉터는 mail, k1, s1, selector1, google 같은 이름이나 mail2025처럼 날짜를 붙인 이름입니다. 이 이름은 서명의 s= 태그와 DNS 레코드 이름, 두 곳에 들어가며 두 값은 정확히 일치해야 합니다.
셀렉터를 가장 빠르게 찾는 방법은 내 도메인에서 보내 이미 수신자에게 전달된 메시지에서 읽어 내는 것입니다. 보낸편지함에 있는 사본은 보통 발신 메일 서버가 DKIM 서명을 추가하기 전에 저장되어 읽을 수 있는 DKIM-Signature 헤더가 없으므로, 메시지는 보낸편지함이 아니라 메시지를 받은 쪽의 받은편지함에서 열어야 합니다. 받은 사본이 없다면 내 도메인에서 다른 서비스의 메일함(개인 Gmail 계정이면 충분합니다)으로 메시지를 보낸 뒤 그 메일함에서 여세요. 그런 다음 아래 방법으로 원본 메시지를 확인합니다.
DKIM-Signature를 검색하고 s= 뒤의 값을 읽습니다.발송 플랫폼은 내 도메인으로 서명하는 것과 별도로 플랫폼 자체 도메인으로도 서명하기 때문에, 한 메시지에 DKIM-Signature 헤더가 두 개 이상 들어 있는 경우가 많습니다. 이 중 d= 태그에 내 도메인이 적힌 헤더를 읽으세요. 그 헤더의 s= 값이 DMARC 정렬(Alignment) 판정에 쓰이는 서명의 셀렉터입니다.
이메일을 발송하는 플랫폼도 인증 설정에서 셀렉터를 보여 줍니다.
google입니다.selector1과 selector2라는 이름의 CNAME 레코드 두 개를 게시해야 하며, Microsoft 365는 키를 교체할 때 두 셀렉터를 번갈아 사용합니다.._domainkey 앞에 있는 부분입니다.온라인 쇼핑몰은 보통 두세 개의 셀렉터를 동시에 사용합니다. 예를 들어 이커머스 플랫폼은 주문 확인 메일에, 뉴스레터 발송 플랫폼은 캠페인 메일에 각자의 셀렉터로 서명합니다.
DMARCeye의 무료 DKIM 검사 도구가 이 조회를 대신해 줍니다. 도메인을 입력하면 주요 플랫폼에서 흔히 쓰는 셀렉터를 차례로 확인합니다.
위의 세 가지 확인 방법은 모두 메시지 하나나 플랫폼 하나만 보여 준다는 한계가 있습니다. 모든 셀렉터를 한 번에 확인할 수 있는 곳은 DMARC 집계 보고서입니다. 이 보고서는 내 도메인 명의로 발송된 메일에 대해 수신 메일 서버가 매일 보내는 요약본이며, 각 보고서에는 수신 서버가 확인한 발송 서비스와 각 서비스의 인증 검사 결과가 셀렉터와 함께 나열됩니다.
DMARCeye는 이 보고서를 대신 읽고, 어떤 키가 활성 상태인지, 어떤 서비스가 그 키를 사용하는지, 어디에서 정렬 문제가 발생하는지 보여 줍니다. 보고서에 처음 보는 셀렉터가 있다면 확인해 볼 필요가 있습니다. 이런 셀렉터는 누군가 나에게 알리지 않고 연결한 서비스의 것이거나, 내 도메인을 사칭하는 발신자의 것입니다.
DMARCeye의 무료 플랜은 도메인 1개의 DMARC 집계 보고서 모니터링을 지원합니다.
DKIM 실패의 원인은 네 가지입니다.
d= 도메인으로 서명하므로, 서명 자체는 통과하지만 DMARC가 요구하는 내 도메인과의 정렬은 이루어지지 않습니다.이와 같은 설정 문제는 최대 규모의 제공업체를 이용할 때도 흔히 발생합니다. DMARCeye의 2026년 1분기 데이터셋에서 상위 10개 ESP의 DKIM 실패율을 보면 Google LLC는 11.1%, Microsoft Corporation은 19.6%, Mailgun은 22.9%, Proofpoint는 26.3%이며, Proofpoint의 수치는 당사가 측정한 상위 10개 ESP 중 가장 높습니다.
1분기 보고서에서 직접 밝히고 있듯이, 주요 ESP의 낮은 컴플라이언스는 거의 언제나 발신자 측의 설정 문제이지, 제공업체 자체의 결함이 아닙니다. 구체적으로는 고객이 DNS에 올바른 DKIM 키를 추가하지 않았거나, 잊고 있던 도구가 잘못된 셀렉터로 서명하고 있거나, 발송 서비스와 DNS 중 한쪽에서만 키를 교체한 경우입니다.
컴플라이언스 수치는 DMARCeye가 모니터링하는 고객군의 구성도 반영하므로, 각 플랫폼의 전체 고객 기반과는 다를 수 있습니다.
셀렉터를 찾고 DNS 레코드가 정상적으로 응답하는지 확인했다면, 다음 테스트 한 번으로 서명부터 검증까지 전체 과정을 점검하세요.
Authentication-Results 헤더를 찾아 dkim=pass가 있는지 확인합니다. Gmail이 추가하는 이 헤더에는 Gmail이 확인한 셀렉터도 header.s= 값으로 표시됩니다.테스트 한 번을 통과했다는 것은 그날 한 서비스에서 셀렉터가 작동한다는 사실을 증명할 뿐입니다. 모든 서비스가 계속 올바르게 서명하고 있는지는 DMARC 보고서가 매일, 모든 서비스에 대해 한꺼번에 알려 줍니다.
네, 둘 이상의 서비스로 이메일을 보내는 도메인은 대부분 여러 개의 셀렉터를 사용합니다. 각 발송 서비스는 자체 셀렉터에 연결된 자체 키로 서명하므로, 온라인 쇼핑몰이라면 영수증용, 뉴스레터용, 헬프데스크용 셀렉터를 하나씩 둘 수 있습니다. 이 셀렉터들은 DNS에 함께 게시되며 서로 충돌하지 않습니다.
아니요. 셀렉터는 키를 구분하는 이름일 뿐이므로, 문자와 숫자로 된 짧은 이름이면 무엇이든 사용할 수 있습니다. 중요한 것은 서명의 s= 태그에 적힌 이름과 공개 키가 담긴 DNS 레코드의 이름이 일치하는지 여부입니다. 두 이름이 다르면 키 자체가 올바르더라도 검증에 실패합니다.
Microsoft 365가 서명하는 각 도메인에 사용하는 두 개의 셀렉터입니다. DKIM을 설정할 때 두 셀렉터를 모두 CNAME 레코드로 게시하며, Microsoft는 키를 교체할 때 두 셀렉터를 번갈아 사용하므로 교체 중에도 메일이 계속 인증을 통과합니다.
DKIM 셀렉터는 전달된 메시지의 s= 태그를 읽거나, 발송 플랫폼의 인증 설정을 확인하거나, DNS를 직접 조회하는 것만으로 찾을 수 있습니다. 계속 관리해야 하는 부분은 모든 셀렉터가 제대로 작동하도록 유지하는 일인데, 새 서비스가 추가되고, 키가 교체되고, _domainkey가 무엇을 뜻하는지 모르는 누군가가 DNS 레코드를 정리하기 때문입니다. DMARC 보고서는 이 모든 변화를 기록하며, DMARCeye는 이 보고서를 바탕으로 어떤 셀렉터가 내 도메인 명의로 서명하고 있고 어떤 셀렉터가 더 이상 통과하지 못하는지 실시간 목록으로 보여 줍니다.