DKIM 설정 방법: 키 생성부터 DNS 등록·검증까지

DKIM(DomainKeys Identified Mail)은 발신 서버가 개인키로 메일에 전자 서명을 붙이고, 수신 서버가 DNS에 게시된 공개키로 그 서명을 검증하는 이메일 인증 방식이다. 서명이 유효하면 "이 메일은 해당 도메인 관리자가 승인한 서버에서 나왔고, 본문·주요 헤더가 전송 중에 바뀌지 않았다"는 것이 증명된다. Gmail·네이버 같은 대형 수신자는 DKIM이 없는 대량 메일을 스팸으로 강등하거나 아예 거부하기 때문에, 도메인으로 메일을 보낸다면 DKIM은 선택이 아니라 필수다.

이 가이드는 DKIM의 동작 원리와 selector 개념부터 Google Workspace·Microsoft 365·자체 호스팅(opendkim)의 실제 설정 절차, DNS 레코드 해부, 그리고 정상 동작 검증까지 전 과정을 다룬다. 설정을 마친 뒤에는 DKIM 레코드 조회로 공개키가 제대로 게시됐는지 바로 확인할 수 있다.

DKIM이 동작하는 원리 — 서명, selector, 공개키 조회

흐름은 세 단계다. 암호를 몰라도 이 그림만 이해하면 설정 화면의 모든 항목이 이해된다.

1. 발신 서버가 서명: 메일을 내보내기 직전에 발신 서버가 개인키(private key)로 본문 해시와 주요 헤더(From, Subject, Date 등)를 서명하고, 그 결과를 DKIM-Signature: 헤더에 붙인다.
2. 수신 서버가 공개키를 DNS에서 조회: 서명 헤더 안의 도메인(d=example.com)과 selector(s=google)를 조합해 google._domainkey.example.com 위치의 TXT 레코드를 질의한다. 여기에 공개키가 들어 있다.
3. 검증: 공개키로 서명을 풀어 해시가 일치하면 dkim=pass. 본문이 1바이트라도 변조됐거나 키가 다르면 dkim=fail이 된다.

selector는 "키의 이름표"다. 한 도메인이 여러 개의 DKIM 키를 동시에 가질 수 있게 해주는 장치로, 두 가지 이유로 여러 개를 쓴다. 첫째 키 회전(rotation) — 새 selector로 새 키를 게시하고 서명을 전환한 뒤 옛 키를 제거하면 무중단으로 키를 교체할 수 있다. 둘째 서비스별 분리 — Google Workspace는 google, Microsoft 365는 selector1/selector2, Mailchimp는 k1처럼 발송 서비스마다 자기 selector로 키를 게시하므로 서로 충돌하지 않는다.

DNS 레코드 해부 — v=DKIM1; k=rsa; p=…

DKIM 공개키 레코드는 selector._domainkey.도메인 이름의 TXT 레코드이며, 값은 세미콜론으로 구분된 태그 목록이다.

• v=DKIM1 — 버전. 항상 이 값이며 맨 앞에 온다.
• k=rsa — 키 알고리즘. 대부분 RSA이고, 최신 스택은 ed25519도 지원한다.
• p=MIIBIjANBg... — Base64로 인코딩된 공개키 본체. 이 태그가 비어 있으면(p=;) "이 키는 폐기됐다"는 의미다.
• t=y(선택) — 테스트 모드. 운영 전환 시에는 제거한다.

키 길이는 2048비트를 권장한다. 1024비트는 현재 컴퓨팅 파워로 위험 수준에 근접했고, Google도 2048비트 생성을 기본값으로 안내한다. 다만 2048비트 공개키는 Base64 문자열이 255자를 넘기 때문에, DNS 관리툴이 긴 TXT를 지원하지 않으면 값을 두 개의 따옴표 문자열로 쪼개 넣어야 한다(대부분의 관리형 DNS는 자동 처리).

제공업체별 설정 경로 — 어디서 켜고 무엇을 게시하나

Microsoft 365는 TXT가 아니라 CNAME 두 개를 게시한다는 점이 다르다. selector1._domainkey.내도메인 → selector1-내도메인-com._domainkey.테넌트.onmicrosoft.com 형태로 위임하면 실제 공개키는 Microsoft가 관리하고, 회전도 selector1↔selector2를 번갈아 쓰며 자동으로 처리한다. CNAME 두 개가 전파된 뒤 Defender 포털에서 "서명 활성화" 스위치를 켜야 실제 서명이 시작된다.

자체 호스팅이라면 opendkim이 표준이다. opendkim-genkey -b 2048 -d example.com -s mail2026으로 키 쌍을 만들면 mail2026.private(개인키)와 mail2026.txt(DNS에 넣을 TXT 레코드 완성본)가 생성된다. TXT를 게시하고 KeyTable/SigningTable에 도메인·selector·키 경로를 등록한 뒤 Postfix에 milter로 연결하면 된다.

실전 예시 — Google Workspace 처음부터 끝까지

example.com 도메인을 Google Workspace에서 쓰는 상황을 가정한 전체 절차다.

1. 키 생성: 관리 콘솔(admin.google.com) → 앱 → Google Workspace → Gmail → 이메일 인증으로 이동. 도메인 선택 후 "새 레코드 생성"에서 키 길이 2048비트, selector 접두어 google(기본값)을 선택한다.
2. TXT 게시: 화면에 표시된 값을 DNS에 그대로 등록한다. 실제 레코드는 이런 모습이다.
   호스트: google._domainkey.example.com
   값: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Fh9K2...IDAQAB (p= 뒤 약 390자의 Base64 공개키)
3. 전파 확인: 등록 후 DKIM 레코드 조회에 도메인 example.com과 selector google을 넣어 공개키가 조회되는지 확인한다. TTL에 따라 몇 분~1시간 걸릴 수 있다.
4. 서명 활성화: 다시 관리 콘솔의 이메일 인증 화면에서 "인증 시작" 버튼을 누른다. 이 버튼을 눌러야 실제 발신 메일에 서명이 붙는다 — TXT만 게시하고 이 단계를 빼먹는 실수가 가장 흔하다.
5. 실제 메일로 검증: Gmail 주소로 테스트 메일을 보내고, 받은 메일에서 ⋮ 메뉴 → 원본 보기를 연다. 상단 요약에 DKIM: 'PASS'(도메인: example.com)가 보이고, 헤더의 Authentication-Results에 dkim=pass header.i=@example.com이 있으면 성공이다.

정렬(alignment) — DKIM만으로는 끝이 아니다

DMARC 관점에서 중요한 것은 서명의 d= 도메인이 보낸사람(From:) 도메인과 일치(정렬)하느냐다. 예를 들어 발송 대행 서비스가 자기 도메인(d=mailer.com)으로 서명하면 DKIM 자체는 pass여도 DMARC 정렬은 실패한다. 그래서 SaaS 발송 도구를 쓸 때는 반드시 내 도메인 이름의 CNAME(위 표의 Mailchimp·SES 방식)을 게시해 d=를 내 도메인으로 맞춰야 한다.

DKIM이 통과하면 이메일 인증 3종 세트를 완성하자. 발신 IP 목록인 SPF는 SPF 레코드 조회로 점검하고, 두 결과를 묶어 정책을 선언하는 DMARC 레코드는 DMARC 레코드 생성기로 만들어 p=none부터 시작하면 된다. SPF + DKIM + DMARC가 모두 갖춰져야 Gmail·Yahoo의 대량 발송자 요건을 충족한다.