자체 도메인으로 메일을 보낸다면 DNS에 DKIM 레코드를 설정해야 합니다. 올바른 설정은 발신 인증에 중요하며 전달 가능성을 지원할 수 있습니다. DKIM 서명이 없으면 수신 서버는 DKIM으로 서명 대상 내용의 전송 중 변경 여부를 검증할 수 없습니다. Google, Yahoo, Microsoft는 대량 발신자에게 DKIM 요건을 적용하며, 소량 발신 도메인에도 중요한 인증 요소입니다.
이 가이드는 키 생성, DNS 레코드 게시, 서명 활성화, 검증까지 설명합니다. 필요한 절차와 문법, 자주 걸리는 함정에 집중합니다. 수동으로 설정하든 관리형 플랫폼을 사용하든 기본 원리는 같습니다.
DKIM 레코드란?
DKIM 레코드는 암호화 키 쌍의 공개키를 담은 DNS TXT 항목입니다. 발신 시스템은 개인키로 메시지에 서명합니다. 수신 서버는 DNS에서 공개키를 받아 서명을 검증하고, 서명 도메인의 발신 권한과 서명 대상 헤더 및 본문의 변경 여부를 확인할 수 있습니다. DKIM은 RFC 6376에 정의된 현대 이메일 인증의 핵심 요소입니다.
4단계로 DKIM 레코드 만들기
1단계: DKIM 키 쌍 생성하기
먼저 키 쌍이 필요합니다. 개인키는 발신 시스템에 보관하고 공개키는 DNS에 게시합니다. 생성 방법은 구성에 따라 다릅니다.
호스팅 이메일 서비스인 Google Workspace, Microsoft 365, Zoho 등을 사용한다면 업체가 보통 키 정보와 DNS 안내를 제공합니다. 제공된 레코드를 복사하세요. Google Workspace에서는 관리 콘솔 > 앱 > Google Workspace > Gmail > 이메일 인증으로 이동해 “새 레코드 생성”을 선택합니다.
자체 메일 서버로 Postfix, Exim, OpenDKIM을 운영한다면 명령줄에서 키 쌍을 생성합니다.
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem지원되는 경우 2048비트 키를 사용하세요. 오래된 문서는 1024비트를 언급하기도 하지만, 2026년에는 더 약한 선택입니다. 수신 서버의 1024비트 서명 처리 방식은 다를 수 있습니다.
이 키를 구분하는 이름인 선택자도 정해야 합니다. 선택자를 이용해 키를 교체하거나 서비스별로 다른 키를 쓸 수 있습니다. 흔한 이름은 google, s1, mail2026, 서비스 이름인 sendgrid 등입니다.
2단계: 공개키를 DNS에 추가하기
도메인의 DNS에 실제 DKIM 레코드를 게시하는 단계입니다. Cloudflare, Route 53, GoDaddy, Namecheap 등의 DNS 업체에 로그인해 발신 시스템의 안내에 따라 TXT 레코드를 추가하세요. 업체에 따라 CNAME을 요구할 수도 있습니다.
호스트/이름 입력란:
selector._domainkey.yourdomain.comselector를 1단계에서 정한 이름으로 바꿉니다. 선택자가 s1이고 도메인이 example.com이면 전체 레코드 이름은 다음과 같습니다.
s1._domainkey.example.com값 입력란:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2K4PavXoNY8eGK2u...truncated...base64encodedpublickeyp= 태그에는 전체 공개키가 하나의 base64 문자열로 들어갑니다. -----BEGIN PUBLIC KEY----- 같은 PEM 머리말과 줄바꿈을 제거하세요. 키 데이터는 이어진 문자열이어야 합니다.
중요: DNS TXT의 개별 문자열에는 255자 한도가 있습니다. 2048비트 키는 여러 문자열에 나누어 담아야 합니다. 일부 업체는 자동으로 나누지만, 그렇지 않으면 최대 255자씩 큰따옴표로 묶어 입력해야 합니다. 레코드 처리 시 각 부분이 이어 붙여집니다.
3단계: 메일 서버에서 DKIM 서명 활성화하기
DNS 레코드만으로는 메일에 서명하지 않습니다. 발신 시스템이 개인키로 발신 메시지에 실제 서명해야 합니다.
Google Workspace: 키를 생성한 관리 화면에서 “인증 시작”을 선택합니다.
OpenDKIM(Postfix/Exim): /etc/opendkim.conf를 수정합니다.
Selector s1
KeyFile /etc/opendkim/keys/example.com/dkim_private.pem
Domain example.com
Socket inet:8891@localhost그다음 Postfix의 /etc/postfix/main.cf에 milter를 추가합니다.
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891두 서비스를 다시 시작합니다.
sudo systemctl restart opendkim
sudo systemctl restart postfix외부 발신 서비스인 SendGrid, Mailgun, Amazon SES는 각자 활성화 절차가 있습니다. 일반적으로 제공된 CNAME 또는 TXT 레코드를 DNS에 추가한 뒤 업체 대시보드에서 검증합니다.
4단계: 레코드 검증하기
작동한다고 가정하지 말고 바로 검증하세요.
명령줄에서 확인:
dig TXT s1._domainkey.example.com +short응답에 공개키가 보여야 합니다. 비어 있다면 이름과 레코드 유형도 점검하세요. DNS 캐시나 아직 반영되지 않은 변경 때문일 수도 있습니다. 최대 48시간을 기다리라는 안내가 쓰이기도 하지만 고정된 보장 시간은 아닙니다. 많은 변경은 수분 안에 보입니다.
테스트 메일로 확인: Gmail 주소로 메일을 보내 원본 헤더를 확인합니다. 다음 결과를 찾으세요.
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=s1dkim=pass는 해당 테스트 메시지의 서명이 검증되었다는 뜻입니다. DMARC 정렬도 확인하세요. dkim=fail 또는 dkim=neutral이라면 구성을 점검하고 아래의 흔한 실수를 살펴보세요.
DKIM 레코드 문법 이해하기
처음 설정할 때는 문법을 이해하는 것이 중요합니다. 전체 구조는 다음과 같습니다.
v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQE...| 태그 | 필수 여부 | 의미 |
|---|---|---|
v=DKIM1 | 필수 | 버전. DKIM1이어야 합니다. |
k=rsa | 선택 | 키 유형. RSA가 기본이며 널리 사용됩니다. Ed25519 지원 여부는 발신 및 수신 시스템마다 다릅니다. |
p= | 필수 | base64 공개키. 빈 p=는 키가 폐기되었다는 뜻입니다. |
t=s | 선택 | 서명 ID i=의 도메인을 서명 도메인 d=와 정확히 같게 제한합니다. 이 플래그가 없으면 i=에 그 하위 도메인도 사용할 수 있습니다. DMARC의 From 정렬과는 다른 규칙입니다. |
t=y | 선택 | 테스트 모드. 규격상 수신자는 검증 실패 메시지를 서명 없는 메일과 다르게 처리해서는 안 됩니다. 실제 처리는 수신 정책에도 달려 있습니다. 테스트를 마치면 제거하세요. |
DKIM 레코드 설정의 흔한 실수
처음 설정하는 팀은 비슷한 실수를 반복하곤 합니다.
1. 공개키 안의 줄바꿈. 흔한 문제입니다. PEM 파일에서 복사한 키를 줄바꿈과 함께 DNS 값에 넣으면 잘못된 값이 될 수 있습니다. base64 키 데이터에서 줄바꿈과 공백을 제거하세요.
2. DNS 이름의 잘못된 선택자. 키는 s1으로 생성했는데 서버 설정은 default를 사용하면 수신 서버는 default._domainkey.example.com을 조회해 필요한 키를 찾지 못합니다. DNS 선택자는 서명에 쓰는 선택자와 정확히 같아야 합니다.
3. 같은 선택자에 여러 DKIM 레코드 게시. 도메인마다 하나의 레코드를 써야 하는 SPF와 달리 DKIM은 여러 선택자를 사용할 수 있습니다. 하지만 각 선택자는 명확해야 합니다. s1._domainkey에 TXT 레코드를 두 개 게시하면 키 조회가 모호하거나 유효하지 않을 수 있습니다.
4. 서명 활성화를 잊음. DNS 레코드는 공개키만 게시합니다. 발신 시스템이 개인키로 메시지에 서명해야 합니다. 서명이 없으면 레코드만으로는 인증에 도움이 되지 않습니다.
5. 1024비트 키 사용. 기술적으로 작동할 수 있지만 Google 발신자 지침과 보안 권고는 지원되는 경우 2048비트를 권장합니다. 새 키 쌍을 생성해 새 선택자로 공개키를 게시하고 발신 설정을 바꾸세요. 이전 키로 서명되어 이동 중인 메일의 검증 시간을 확보한 뒤 기존 p= 값을 비워 폐기합니다.
DKIM, SPF, DMARC: 전체 인증 구성
DKIM은 독립적인 완성형 인증이 아니라 세 가지 메커니즘 중 하나입니다.
SPF는 발신 서버 IP가 도메인에서 허용되었는지 확인합니다. 전달 과정에서 발신 IP가 바뀌면 실패할 수 있습니다. 아직 설정하지 않았다면 SPF 레코드 설정 가이드와 이메일에서 SPF가 작동하는 방식을 읽고 DNS 조회 유발 항목 10개 한도와 기타 제약을 이해하세요.
DKIM은 발신 IP가 아니라 메시지 내용에 연결되므로 전달 후에도 유효할 수 있습니다. 단, 서명 대상 내용이 검증을 실패하게 할 만큼 변경되지 않아야 합니다. 그래서 SPF를 보완합니다.
DMARC는 둘을 연결합니다. 유효하고 정렬된 SPF 또는 DKIM 경로가 없을 때 격리, 거부, 모니터링 중 어떤 처리를 요청하는지 알립니다. SPF와 DKIM 중 하나 이상이 통과해야 하며 From 도메인과 정렬되어야 합니다.
SPF와 DKIM 모두 유효하게 정렬되도록 구성하고, 정상 발신 경로를 검증한 뒤에 p=reject를 적용하세요. 도메인 보호에 도움이 되지만 좋은 도메인 평판이나 받은편지함 도착을 보장하지는 않습니다.
기업에는 이 구성이 안전한 이메일 운영의 중요한 기반이지만 모든 보안 위험을 없애지는 않습니다.
TrekMail이 DKIM 설정을 지원하는 방식
한 도메인은 수동 관리가 가능하지만 수십 개 도메인에서는 자동화가 더 유용해집니다. 키 교체, 서비스별 선택자 관리, 잘못된 설정 감지에 운영 부담이 생깁니다.
TrekMail은 선택한 발신 경로에 맞는 SPF, DKIM, DMARC DNS 안내를 제공하는 마법사를 소개합니다. 관리형 발신에서는 TrekMail에 표시된 DKIM 정보를 사용합니다. 외부 SMTP의 키와 서명 설정은 실제 발신 업체에서 받아야 합니다. DNS 검사는 오류를 발견하는 데 도움이 되지만 모든 전달 문제를 미리 막는 것은 아닙니다.
- Nano($0): Amazon SES, Mailgun 등의 BYO SMTP를 사용합니다. 해당 업체의 DKIM 안내를 따르세요. 카드가 필요 없는 요금제로 안내되며 최신 조건을 확인해야 합니다.
- Starter(월 $3.50): 관리형 SMTP와 TrekMail의 DKIM 정보를 사용합니다. 키 생성 및 교체 지원 범위는 현재 조건을 확인하세요. 안내된 무료 체험은 14일이며 카드가 필요합니다.
- Pro(월 $10): 여러 발신 도메인과 각 DKIM 설정의 제공 범위는 요금제 조건에 따릅니다. 안내된 무료 체험은 14일입니다.
- Agency(월 $23.25): 고객 도메인의 중앙 관리를 지향합니다. 안내된 100+ 도메인, 키 교체와 모니터링 범위는 최신 조건에 따라 달라집니다. 안내된 무료 체험은 14일입니다.
단순한 편의성만의 문제는 아닙니다. 잘못된 DKIM 레코드는 인증 문제가 드러날 때까지 발견하지 못할 수 있습니다. 자동 검증은 오류를 더 일찍 찾는 데 도움이 됩니다.
결론
올바른 설정에는 네 가지가 필요합니다. 지원되는 경우 2048비트 키 쌍, 정확한 선택자의 DNS TXT 레코드, 실제로 서명하는 발신 시스템, 검증입니다. 한 도메인의 작업은 약 십 분 안에 끝날 수도 있지만 DNS 대기와 업체 설정에 따라 더 오래 걸립니다.
DKIM이 작동해도 거기서 끝내지 마세요. SPF와 DMARC를 함께 사용해 도메인 악용 위험을 줄이세요. 전체 구성이 인증과 브랜드 보호를 지원하지만 모든 전달 및 보안 위험을 제거하지는 않습니다.
DNS를 수동 관리하는 부담을 줄이고 싶다면 TrekMail 무료 요금제를 살펴보고 마법사가 제공하는 설정 안내를 활용하세요.
