DKIM 선택자: 설정, 조회와 문제 해결

DKIM 선택자는 메일 인증이 실패하거나 Gmail이 메시지를 스팸으로 분류하거나 업체가 tm1._domainkey.example.com 같은 TXT 레코드를 요구할 때 비로소 눈에 들어오곤 합니다. 사소해 보여도 잘못 설정하면 DKIM이 실패할 수 있습니다. 유효하고 정렬된 SPF 경로도 없다면 DMARC까지 실패할 수 있으며, 이는 전달 가능성에 불리하게 작용할 수 있습니다.

한 도메인에서 여러 발신자를 쓰면 더 복잡해집니다. 사서함 호스팅은 자체 키로, 마케팅 도구는 다른 키로, CRM은 또 다른 키로 서명합니다. 선택자를 이해하지 못하면 어느 시스템이 어떤 서명을 관리하는지, 어떤 DNS 레코드를 교체해야 하는지, 왜 특정 메일 흐름만 실패하는지 구분하기 어렵습니다. 전체 설정 배경은 업무 이메일 글을 참고하세요.

해결의 출발점은 선택자를 DKIM 키의 조회 이름으로 이해하는 것입니다. DNS와 연결되는 방식을 알면 설정과 진단을 반복 가능한 절차로 다룰 수 있습니다.

DKIM 선택자란 무엇인가요?

DKIM 선택자는 수신 서버가 DNS에서 어떤 공개키를 가져올지 지정하는 서명 안의 이름입니다. 한 도메인이 여러 시스템, 메일 흐름, 키 교체를 위해 여러 DKIM 키를 동시에 게시할 수 있게 합니다.

선택자는 키 자체가 아니라 조회에 필요한 정보입니다. DKIM-Signature 헤더의 s= 태그에 있으며, 서명 도메인은 d=에 있습니다. 수신 서버는 둘을 합쳐 selector._domainkey.example.com 같은 DNS 이름을 만들고 TXT 레코드에서 공개키를 가져옵니다.

RFC 6376은 검증자가 d=의 도메인과 s=의 선택자로 공개키 레코드를 찾는다고 규정합니다. 선택자가 없으면 조회 이름을 만들 수 없고, 잘못된 선택자는 없는 키나 다른 키로 이어질 수 있습니다. 그러면 해당 서명을 유효하게 검증할 수 없습니다.

메시지에 d=example.com과 s=tm1이 있으면 수신 서버는 tm1._domainkey.example.com을 조회합니다.

DKIM 선택자가 실제로 하는 일

특정 메시지를 검증할 공개키를 알려 줍니다. 같은 도메인에서 이름 충돌 없이 여러 키를 운영하기 위한 장치입니다.

운영상 세 가지 의미가 있습니다.

1. 발신자를 구분합니다. 헬프데스크와 트랜잭션 앱이 서로 다른 선택자를 사용할 수 있습니다.
2. 키 교체를 가능하게 합니다. 새 선택자를 게시하고 서명을 전환한 뒤 이동 중인 기존 메일이 처리되면 이전 키를 폐기합니다.
3. 영향 범위를 줄입니다. 특정 업체 키가 유출되거나 폐기되어도 다른 모든 발신자를 바꿀 필요는 없습니다.

그래서 체계적인 메일 운영에서는 같은 키를 무기한 쓰기보다 선택자가 다른 여러 DKIM 레코드를 사용하고 다른 인증 정보처럼 관리합니다.

DKIM 선택자는 어디서 찾나요?

메시지 헤더 또는 발신 업체의 DNS 안내에서 찾습니다. 실제 메일의 DKIM-Signature 헤더에서는 s= 값입니다.

수신한 메시지의 원본 헤더를 열고 DKIM-Signature:를 검색하세요. 다음 두 태그를 확인합니다.

• d=는 서명 도메인입니다.
• s=는 DKIM 선택자입니다.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=tm1;
 c=relaxed/relaxed; h=from:to:subject:date:message-id;
 bh=...; b=...

이 예시의 선택자는 tm1입니다. 확인할 DNS 레코드는 다음과 같습니다.

tm1._domainkey.example.com TXT

새 발신자를 설정할 때 업체는 보통 선택자 이름과 TXT 값 또는 CNAME 대상을 제공합니다. TrekMail은 도메인 설정 과정에서 DNS 안내와 대시보드 상태 검사를 제공합니다. 정확한 입력 위치는 필수 DNS 레코드와 DNS 상태 확인 문서를 참고하세요.

DNS에 DKIM 선택자를 게시하는 방법

selector._domainkey.yourdomain.com에 DNS 레코드를 만듭니다. 보통 DKIM 공개키를 담은 TXT이며, 일부 업체는 관리형 키를 가리키는 CNAME을 사용합니다.

대표적인 두 형태는 다음과 같습니다.

TXT 기반 DKIM:

Host: tm1._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

CNAME 기반 DKIM:

Host: tm1._domainkey
Type: CNAME
Value: tm1.example-com.dkim.vendor.net.

업체가 선택자를 정해 주었다면 임의로 바꾸지 마세요. s1을 안내했다면 s1._domainkey에 게시합니다. TrekMail 관리형 발신 설정에 dkim._domainkey가 표시된다면 해당 호스트와 값을 정확히 사용합니다. Nano에서 외부 발신 업체를 쓴다면 실제 업체의 선택자를 따라야 하며 사용자 지정 SMTP(BYO) 안내를 참고할 수 있습니다.

선택자가 작동하는지 어떻게 테스트하나요?

DNS 레코드가 조회되고 실제 메시지가 같은 선택자로 서명되며 DKIM 검증을 통과하는지 확인합니다.

먼저 DNS 레코드를 직접 조회합니다.

dig +short TXT tm1._domainkey.example.com
nslookup -type=TXT tm1._domainkey.example.com

빈 응답은 레코드 누락, 캐시, 잘못된 호스트 또는 다른 DNS 문제 때문일 수 있습니다. 무조건 기다리기보다 원인을 확인하세요.

그다음 실제 메일을 보내 헤더를 확인합니다.

Authentication-Results: mx.google.com;
 dkim=pass header.i=@example.com header.s=tm1 header.b=...
 spf=pass smtp.mailfrom=example.com;
 dmarc=pass header.from=example.com

확인할 항목:

• dkim=pass
• header.s=tm1이 게시한 선택자와 일치함
• header.i는 서명 ID이며 DMARC 정렬 기준은 아닙니다. DKIM의 DMARC 정렬은 d=의 도메인이 From 도메인과 정렬되는지로 판단합니다

전달을 자주 사용한다면 이메일 전달도 읽어 보세요. SPF는 전달 시 실패할 수 있습니다. DKIM은 서명된 내용이 바뀌지 않고 서명이 유효하게 유지될 때 인증을 보완할 수 있습니다.

DKIM 선택자가 실패하는 이유

흔한 원인은 잘못된 DNS 호스트, 유효하지 않은 키 값, 게시한 것과 다른 선택자를 쓰는 발신자, 서명 후 메시지를 수정하는 릴레이입니다.

실제 운영에서 자주 발생하는 문제:

1. 잘못된 DNS 호스트. _domainkey.tm1을 tm1._domainkey 대신 게시했습니다.
2. 잘못된 도메인. 메일은 d=mg.example.com으로 서명하지만 선택자는 example.com 아래에 게시했습니다.
3. DNS 구성 분리 오류. 레코드가 권한 있는 네임서버가 아닌 다른 네임서버 집합에 있습니다.
4. 잘린 키. DNS 화면에 붙여 넣는 과정에서 TXT 값 일부가 누락되었습니다.
5. 이전 선택자 사용. 키를 바꿨지만 발신자가 여전히 이전 선택자로 서명합니다.
6. 서명 후 메시지 변경. 전달 서버나 게이트웨이가 서명 대상 헤더 또는 본문을 수정했습니다.

Google 발신자 지침은 DKIM 인증이 잘못된 대량 메일이 속도 제한이나 차단 대상이 될 수 있다고 설명합니다. 전달은 SPF를 실패하게 할 수도 있어 올바른 DKIM 선택자 관리가 중요합니다.

DKIM 선택자 이름은 어떻게 정하나요?

간단하고 운영 목적을 알 수 있는 이름을 쓰세요. 명확한 이름은 여러 업체 화면을 찾지 않고 키의 관리 주체를 파악하도록 도와 사고 대응을 빠르게 합니다.

맥락이 부족한 이름은 default, key1, test 등입니다. 작동할 수는 있어도 시간이 지나면 의미가 불분명해집니다. 더 나은 예시:

• tm1: TrekMail 관리형 발신
• ses2026q1: Amazon SES 키 교체
• crm1: CRM 플랫폼
• mktg2026a: 마케팅 메일

업체가 허용한다면 누가 관리하고 언제 도입했는지 한눈에 알 수 있는 이름을 쓰세요. 여러 도메인을 운영할 때, 특히 다중 도메인 이메일 호스팅 환경에서 점검이 쉬워집니다.

DKIM 선택자를 신중하게 교체하는 방법

새 선택자로 새 키를 게시하고 발신 서명을 전환한 뒤, 기존 메일이 처리될 시간을 확보하고 이전 레코드를 제거합니다.

업체가 명시적으로 요구하지 않는 한 활성 키를 같은 위치에서 덮어쓰지 마세요. 더 신중한 절차:

1. 새 선택자를 만듭니다. 예를 들어 tm1에서 tm2로 변경합니다.
2. 새 DNS 레코드를 게시합니다.
3. DNS에 보일 때까지 기다립니다.
4. 발신자를 새 선택자로 서명하도록 바꿉니다.
5. 테스트 메일에서 새 선택자의 dkim=pass를 확인합니다.
6. 이전 레코드는 여유 기간 동안 유지합니다.
7. 더 이상 이전 키로 서명하지 않고 이동 중인 메시지에도 충분한 시간이 지난 뒤 제거합니다.

여러 발신 시스템을 쓸수록 중요합니다. 기존 방식은 하나의 키를 오래 공유하며 누군가 관리를 잊지 않기만 바랍니다. 개선된 방식은 발신자별 선택자, 계획된 교체, 독립적인 변경을 사용합니다.

TrekMail은 DKIM 선택자를 어떻게 다루나요?

TrekMail은 필요한 DNS 안내와 상태 검사를 제공하며, 요금제 조건에 따라 유료 관리형 발신과 Nano의 BYO SMTP를 지원합니다. 선택자 위치와 DNS 상태를 추측하는 부담을 줄이는 데 도움이 됩니다.

수신 호스팅과 사서함 관리에는 도메인 대시보드, 공유 저장 공간, 초대 기반 생성, 사서함 전달, 내장 IMAP 마이그레이션이 안내됩니다. 발신은 다음 운영 방식 중 선택합니다.

• 유료 요금제는 도메인의 DKIM 키로 서명하는 TrekMail Managed SMTP를 사용할 수 있습니다.
• Nano는 BYO SMTP를 사용하므로 실제 발신 업체가 활성 선택자와 서명 방식을 관리합니다.

이 구분이 중요합니다. 외부 업체가 서명하면 해당 업체의 DNS 안내가 기준이고, TrekMail Managed SMTP가 서명하면 대시보드의 DKIM 레코드를 사용합니다. Starter의 안내 시작 가격은 월 $3.50이며, 유료 요금제는 신용카드가 필요한 14일 무료 체험을 소개합니다. Nano는 체험 기간이 없는 무료 요금제로 안내됩니다. 최신 조건을 확인하세요. 사용자별 과금 대신 정액형 모델을 원한다면 TrekMail 요금을 살펴보세요.

DKIM 선택자 문제 점검 목록

일정한 순서로 확인하세요. 메시지의 선택자, 정확한 호스트의 DNS 레코드, 발신자가 사용하는 선택자, 전송 중 서명 대상 내용의 변경 여부를 점검합니다.

1. 실제 수신 메시지에서 s=와 d=를 기록합니다.
2. DNS에서 selector._domainkey.domain을 직접 조회합니다.
3. 등록업체 화면뿐 아니라 권한 있는 네임서버를 확인합니다.
4. 업체가 TXT 또는 CNAME 중 무엇을 요구하는지 확인합니다.
5. DMARC 정렬을 위해 From 도메인과 서명 도메인을 비교합니다.
6. 전달, 게이트웨이, 메일링 리스트에서 내용이 바뀐다면 그 경로를 거친 뒤 다시 테스트합니다.

직접 보낸 메일은 통과하지만 전달한 메일이 실패한다면 선택자 자체가 아니라 전달 서버가 서명을 깨뜨린 것일 수 있습니다. Google의 전달 지침과 운영 경험에서도 이런 경우를 볼 수 있습니다. 전달을 사용한다면 도메인 이메일을 Gmail로 전달하기도 읽어 보세요.

정리: DKIM 선택자에서 기억할 점

선택자는 수신 서버가 DNS에서 어떤 DKIM 공개키를 가져올지 알려 주는 이름입니다. 이 한 가지를 이해하면 대부분의 DKIM 진단이 쉬워집니다.

정확한 선택자, DNS 호스트, 같은 선택자의 서명은 필요하지만 검증 성공이나 전달을 보장하지는 않습니다. 실패하면 메시지 헤더, DNS, 전송 중 내용 변경 순서로 확인하세요. 발신자별 선택자를 분리하고 기존 키를 덮어쓰기보다 새 이름으로 교체하세요. TrekMail은 다중 도메인 운영을 위한 호스팅, DNS 검사, 마이그레이션 도구, 사용자별 요금이 없는 정액형 가격을 안내하며 최신 제공 범위와 조건을 확인해야 합니다.