DKIM 레코드 설정·확인 방법 (DNS TXT)

DKIM이 실제로 하는 일

DKIM(DomainKeys Identified Mail, RFC 6376)은 보내는 모든 메일에 암호 서명을 붙입니다. 메일 서버가 개인키로 발신 메일을 서명하고, 짝이 되는 공개키를 DNS에 발행합니다. 수신 서버는 그 공개키를 가져와 서명을 검증하고, 메일이 정말 당신 도메인에서 왔으며 전송 중 변조되지 않았음을 확인합니다.

개인키는 발신 측에 남고 밖으로 나가지 않습니다. DNS에 들어가는 것은 공개키 절반뿐입니다. 어떤 설정 안내가 개인키를 DNS 레코드에 붙여넣으라고 하면 멈추세요 — 그건 전혀 다른, 아주 위험한 일입니다.

레코드의 위치

DKIM은 특정한 TXT 레코드 위치 하나를 씁니다.

<셀렉터>._domainkey.<도메인>

셀렉터는 메일을 서명하는 쪽이 정하는 라벨입니다 — Google Workspace는 google, Microsoft 365는 selector1·selector2, 대량 발송 서비스는 s1·k1 같은 짧은 값을 씁니다. 셀렉터가 있는 이유는 한 도메인이 여러 키를 동시에 발행할 수 있게 하기 위해서입니다 — 발송 서비스별 키를 따로 두고, 옛 키를 깨지 않고 새 키로 교체(rotation)할 수 있습니다. 셀렉터와 발행할 값은 제공자가 알려줍니다.

값에 들어가는 것

레코드는 세미콜론으로 구분된 태그 목록입니다. 최소 형태는 이렇습니다.

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

• v=DKIM1 — 버전. 있을 때는 맨 앞에 와야 합니다.
• k= — 키 유형. 기본값은 rsa이고, ed25519는 RFC 8463에 정의되어 훨씬 짧은 레코드를 만듭니다(다만 아직 모든 수신 서버가 검증하지는 않음).
• p= — base64 공개키. 필수 부분입니다. 빈 p=는 버그가 아니라 키를 **폐기(revoke)**하는 방법입니다.

“왜 안 되지” 문의를 가장 많이 만드는 선택 태그 두 개: t=y는 키를 테스트 중으로 표시하고, t=s는 키를 정확한 서명 도메인에만 묶습니다. t=y는 아래에서 더 다룹니다.

조용히 깨뜨리는 세 가지 실수

1. 2048비트 키를 레코드 하나가 아니라 두 개로 쪼개기. 2048비트 공개키는 약 392자이고 전체 레코드는 420자에 육박합니다 — DNS TXT 문자열 하나의 255자 한도를 훌쩍 넘습니다. 올바른 방법은 값을 레코드 하나 안에서 여러 따옴표 조각으로 나누는 것입니다: "앞255자" "나머지". 리졸버가 다시 이어붙입니다. 같은 셀렉터에 TXT 레코드를 두 개 만드는 것이 전형적인 무증상 실패입니다 — 수신 서버가 한 이름에 후보 키 두 개를 보게 되어, 붙여넣은 문자 하나하나가 정확해도 어느 키가 서명했는지 결정하지 못해 검증이 실패합니다.

2. 가동 후 t=y를 그대로 두기. 온보딩 마법사는 키를 테스트 모드로 발행하는 경우가 많습니다. t=y가 붙은 레코드는 실제 동작하는 통제가 아니라 리허설입니다 — 수신 서버는 서명 실패를 중요하지 않게 취급하라고 안내받고, 일부는 검증을 아예 건너뜁니다. 실제 메일이 서명되는 것을 확인했다면 t=y를 제거하세요.

3. 셀렉터 불일치. 실제 메일의 DKIM-Signature: 헤더 안 s= 태그가 DNS에 발행한 셀렉터와 일치해야 합니다. 서버가 s1으로 서명하는데 s2._domainkey를 발행했다면, 수신 서버는 엉뚱한 이름을 조회해 아무것도 찾지 못하고 서명 없는 메일로 처리합니다.

DechoNet으로 확인

• 이메일 인증 점검은 도메인의 SPF·DKIM·DMARC를 한꺼번에 해석해, DKIM 키가 실제로 발행되고 파싱되는지 — 단순히 TXT 레코드가 있는지가 아니라 — 보여줍니다.
• DNS 조회는 정확히 <셀렉터>._domainkey.<도메인> 이름을 직접 조회합니다. 레코드가 완전한 키 하나로 해석되는지, 2048비트 값이 잘리거나 두 레코드로 쪼개지지 않았는지 확인하는 데 쓰세요.

설정 체크리스트

• 메일 제공자의 관리 콘솔에서 셀렉터와 공개키 값을 받습니다 — 호스팅 서비스라면 직접 키를 생성하지 마세요.
• <셀렉터>._domainkey.<도메인> 이름의 TXT 레코드 하나를 제공자 값으로 만듭니다.
• 2048비트 키라 DNS 호스트가 길이를 문제 삼으면, 값을 여러 따옴표 문자열로 나누되 같은 레코드 안에서 하고, 두 레코드로 만들지 마세요.
• DNS 조회로 레코드를 해석해, 꼬리가 잘리지 않은 완전한 키 하나로 돌아오는지 확인합니다.
• 본인이 통제하는 주소로 테스트 메일을 보내, DKIM-Signature 헤더의 s= 셀렉터가 발행한 값과 일치하는지 확인합니다.
• 실제 메일이 검증되면 t=y 테스트 플래그를 제거합니다.
• 그 뒤에야 DMARC를 조입니다 — p=reject가 안전하려면 DKIM 정렬(서명 d= 도메인이 From 도메인과 일치)이 먼저 되어 있어야 합니다.

레코드 문제가 아닐 때

발행한 키가 정확하고 완전하며 서명 셀렉터와 일치하는데도 메일이 DKIM에 실패한다면, 문제는 DNS가 아니라 발신 측입니다: 서버가 아예 서명하지 않거나, 공개키를 아직 발행하지 않은 교체된 키로 서명하거나, 서명 후 메일을 변경(메일링 리스트나 포워더가 본문을 다시 쓰면 설계상 서명이 깨짐)하고 있을 수 있습니다. 먼저 레코드가 맞는지 확인한 뒤, 실제로 서명된 메일의 헤더를 들고 메일 플랫폼 담당자에게 가세요.