DKIM 설정은 자체 도메인의 발신 인증을 갖추는 데 중요합니다. 키가 없거나 손상되거나 잘렸거나 잘못된 도메인으로 서명되면 받은편지함 도착에 불리할 수 있습니다. 이 가이드는 운영 절차를 설명합니다. 키를 생성하고 DNS 레코드를 게시한 뒤 명령줄에서 검증하고, 정상 표시가 나와도 DMARC를 실패하게 할 수 있는 정렬 오류까지 확인합니다.
MX, SPF, 사서함, 메일 클라이언트를 포함한 전체 도메인 설정은 내 도메인으로 이메일 만들기부터 읽어 보세요. 플랫폼을 먼저 선택한다면 업무 이메일 글에서 전체 선택 기준을 살펴볼 수 있습니다.
문제는 대개 단순합니다. DKIM 설정 실패는 암호 기술 자체보다 DNS 복사 오류, 도메인을 중복으로 붙이는 관리 화면, 손상된 2048비트 키, 사용자 도메인 대신 업체 도메인으로 서명하는 이메일 서비스 제공업체 때문에 발생합니다. 엉뚱한 원인을 찾느라 시간을 낭비하지 않으려면 반복 가능한 절차가 필요합니다.
DKIM 설정이 실제로 하는 일
DKIM은 공개키를 DNS에 게시하고 메일 서버가 대응하는 개인키로 메시지에 서명하게 합니다. 수신 서버는 서명을 검증해 서명 도메인의 발신 권한을 확인하고, 서명 대상 헤더나 본문이 전송 중 바뀌었는지 감지할 수 있습니다.
DKIM은 비대칭 암호 기술을 사용합니다. 발신 시스템은 개인키를 보관하고 DNS에는 공개키를 게시합니다. 발신 메시지에는 DKIM-Signature 헤더가 붙으며, 서명 도메인(d=)과 선택자(s=)가 담깁니다. 수신 서버는 DNS에서 해당 선택자를 조회해 메시지 내용과 서명을 검증합니다. 이 방식은 RFC 6376에 정의되어 있습니다.
Google은 2024년 이월부터 대량 발신자 요건을 강화했습니다. Google은 SPF와 DKIM을 모두 설정하고, 둘 중 하나 이상이 화면에 보이는 From 헤더의 도메인과 정렬되어 DMARC 정렬을 충족해야 한다고 안내합니다. 최신 문구는 Google의 발신자 지침 FAQ에서 확인하세요.
유효한 서명이 목적에 맞는 서명과 항상 같은 것은 아닙니다. 잘못되거나 정렬되지 않은 DKIM 설정은 스팸 분류, DMARC 문제 또는 둘 모두에 영향을 줄 수 있습니다.
DNS를 수정하기 전 준비
먼저 누가 실제로 메일에 서명하는지 확인하세요. 당연해 보여도 마이그레이션, 전달 설정 변경, 업체 전환 과정에서 문제가 생기는 지점입니다. DKIM 레코드를 생성하거나 받아야 할 위치는 발신 경로에 달려 있습니다.
먼저 질문하세요. 이 도메인의 발신 메일은 누가 보내나요?
- Google Workspace가 보낸다면 Google Admin에서 DKIM 키를 생성합니다.
- Microsoft 365가 보낸다면 그곳에서 DKIM을 활성화합니다.
- SendGrid, Mailgun 또는 Amazon SES가 보낸다면 해당 업체에서 도메인을 인증합니다.
- TrekMail Managed SMTP가 보낸다면 TrekMail에 표시된 DKIM 값을 사용합니다.
- TrekMail은 사서함만 관리하고 외부 SMTP를 쓴다면 SMTP 업체의 서명 안내를 따르고 필요에 따라 TrekMail에서 SMTP를 설정합니다.
TrekMail은 두 경로를 지원합니다. Nano는 BYO SMTP를 사용하며 유료 요금제는 조건에 따라 관리형 SMTP를 사용할 수 있습니다. Bring Your Own SMTP 문서에는 SES, SendGrid, Mailgun 예시가 있습니다. 전달 문제 해결 문서에는 Managed SMTP가 사용자 도메인의 DKIM 키로 서명한다고 설명되어 있습니다. 서명이 유효하고 정렬된 상태로 유지되면 전달이나 릴레이를 거칠 때 DMARC를 충족하는 데 도움이 될 수 있습니다.
예를 들어 사서함은 TrekMail에 있지만 발신은 SendGrid를 거친다면 SendGrid가 서명해야 합니다. TrekMail이 사서함을 저장한다고 SendGrid의 DKIM 설정까지 자동으로 처리되는 것은 아닙니다.
첫 번째 원칙은 메시지에 서명하는 시스템에서 키를 생성하는 것입니다. 다른 곳에서 생성하면 DNS 레코드는 있어도 실제 서명에 쓰이지 않을 수 있습니다.
DKIM 레코드 유형: TXT와 CNAME
보통 공개키를 담은 TXT 레코드를 게시합니다. 일부 업체는 자체 호스팅 키를 가리키는 CNAME 레코드를 하나 이상 게시하도록 요구합니다. 두 방식 모두 사용할 수 있으며, 실제 발신자가 제공한 값을 정확히 쓰는 것이 중요합니다.
일반적인 TXT 기반 DKIM 레코드 위치:
selector._domainkey.example.com값은 다음과 같은 형태입니다.
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...관리형 서비스는 사용자에게 DNS 변경을 다시 요청하지 않고 키를 교체하기 위해 CNAME을 자주 사용합니다. TXT는 직접 관리할 수 있지만 키를 교체해야 할 때 업데이트 책임도 사용자에게 있습니다.
| 방식 | 게시 내용 | 주요 용도 | 주요 위험 |
|---|---|---|---|
| TXT | DNS에 전체 공개키 게시 | Google Workspace, 자체 관리 및 직접 업체 설정 | 긴 키가 잘리거나 잘못 붙여 넣어짐 |
| CNAME | 업체 호스팅 DKIM 레코드의 별칭 | 관리형 플랫폼과 간편한 키 교체 | 대상이 잘못되거나 필요한 레코드 일부 누락 |
호스트 입력란이 함정입니다. 도메인이 example.com이고 선택자가 k1이라면 일반적으로 호스트는 다음과 같습니다.
k1._domainkey다음 값이 아닙니다.
k1._domainkey.example.com많은 DNS 관리 화면이 기본 도메인을 자동으로 붙입니다. 그런 화면에 전체 이름을 넣으면 k1._domainkey.example.com.example.com이 게시됩니다. 수신 서버가 찾는 위치와 달라집니다.
TrekMail의 DNS 설정 기준은 필수 DNS 레코드를 참고하세요. 일부 DNS 업체는 DKIM TXT 값을 따옴표로 묶은 여러 문자열로 나누어 입력하도록 요구한다는 설명도 있습니다.
DNS에서 DKIM 설정하기
실무 절차는 짧습니다. 선택자를 받아 레코드를 게시하고 DNS 반영을 기다린 뒤 정확한 응답을 검증합니다. 업체가 마지막 활성화 단계를 요구하면 서명도 켭니다. 검증을 건너뛰면 추측에 의존하게 됩니다.
다음 절차를 따르세요.
- 발신 업체에서 DKIM 레코드를 생성하거나 표시합니다.
- 선택자를 정확히 복사합니다. 업체가 지원하지 않는 한 이름을 바꾸지 마세요.
selector._domainkey에 DNS 레코드를 생성합니다.- 전체 TXT 값 또는 CNAME 대상을 제공된 그대로 붙여 넣습니다.
- 다른 값을 쓸 이유가 없다면 TTL을 3600으로 설정합니다.
- DNS 반영을 기다립니다.
- 실제 운영 메일을 보내기 전에
dig또는nslookup으로 검증합니다. - 업체 화면에 최종 활성화 스위치가 있다면 서명을 켭니다.
TXT 기반 DKIM 예시:
; DNS record
k1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."CNAME 기반 DKIM 예시:
; DNS record
s1._domainkey.example.com. 3600 IN CNAME s1.domainkey.u123456.wl.provider.net.DNS 변경은 빠르게 보일 때가 많지만 즉시 반영되지는 않습니다. TrekMail의 문제 해결 문서는 많은 업데이트가 약 5분에서 15분 사이에 보인다고 안내합니다. 고정된 보장 시간은 아니며 TTL과 캐시에 따라 더 걸릴 수 있습니다. 이후에도 상태가 바뀌지 않으면 형식, 중복 레코드, 호스트 이름을 확인하세요.
DKIM과 2048비트 키 문제
업체와 DNS 호스트가 지원한다면 RSA 2048비트 키를 사용하세요. 더 강력하지만 길이도 길어 오래된 DNS 관리 화면에서 문제가 생길 수 있습니다. 키가 잘리면 레코드는 있는 것처럼 보여도 검증이 실패해 진단이 어려워집니다.
Google은 지원되는 경우 2048비트 키를 권장하고 긴 레코드를 처리하지 못하는 호스트에는 1024비트를 대안으로 안내합니다. 실무 문제는 DNS 자체보다 앞단의 관리 화면에 있는 경우가 많습니다.
2048비트 DKIM 키 문제의 흔한 형태:
- 관리 화면이 알리지 않고 값을 자릅니다.
- 따옴표로 묶은 여러 문자열을 요구하지만 이를 안내하지 않습니다.
- base64 키 안에 줄바꿈을 넣습니다.
- 업체가 예상하지 않은 방식으로 문자를 이스케이프합니다.
DNS 호스트가 문자열 분할을 요구한다면 다음처럼 게시합니다.
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
"restOfTheKeyContinuesHereWithoutAddingSpacesInsideTheBase64Data"수신 서버는 따옴표로 묶인 부분을 이어 붙입니다. 정상적인 동작입니다. 하지만 실제 키 데이터 안에 공백을 추가하면 안 됩니다. 문자 하나만 잘못 들어가도 검증이 실패할 수 있습니다.
여러 도메인을 관리하면 이 지점에서 운영 비용이 드러납니다. 어떤 등록업체는 긴 TXT 값을 잘 처리하고, 다른 업체는 못 하며, 또 다른 업체는 값을 바꿉니다. 그래서 대행사는 사용 업체를 줄이거나 가능한 경우 업체 호스팅 CNAME 서명을 선택합니다. 여러 고객을 관리하는 모델은 다중 도메인 이메일 호스팅에서 살펴보세요.
DNS와 실제 메일로 DKIM 검증하기
대시보드의 “활성” 표시만으로는 충분하지 않습니다. 공개 DNS를 직접 조회해 반환된 레코드를 확인하고, 실제 메일 헤더에 예상한 서명 도메인과 선택자가 있는지 검사해야 합니다. 그보다 적게 확인하면 부분적인 점검입니다.
먼저 명령줄을 사용하세요.
# macOS / Linux
dig txt k1._domainkey.example.com +short
# Windows
nslookup -type=txt k1._domainkey.example.com전체 v=DKIM1 레코드 또는 합치면 전체 키가 되는 따옴표 문자열이 보여야 합니다. 응답이 비어 있다면 순서대로 확인하세요.
- 선택자가 정확합니다.
- 호스트 입력란에서 도메인이 중복되지 않았습니다.
- 레코드 유형이 업체 안내와 같습니다.
- 값이 완전하며 잘리지 않았습니다.
- 이전 레코드가 캐시에 남아 있지 않습니다.
그다음 Gmail이나 헤더를 확인할 수 있는 사서함에 테스트 메일을 보내세요. 인증 결과와 DKIM 서명 줄을 찾습니다.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...
Authentication-Results: ... dkim=pass header.d=example.com ...DNS는 정상인데 받은편지함 도착이 좋지 않다면 더 넓게 점검하세요. TrekMail의 메일이 스팸으로 가는 문제 안내는 DNS 점검, 도메인 워밍업, 수신자 목록 품질, 내용을 강조합니다. DKIM은 인증을 갖추는 것이지 발신 평판을 자동으로 주는 것이 아닙니다.
전달 시의 예외도 확인하세요. 전달된 메일은 SPF가 실패할 수 있습니다. 서명 대상 내용이 바뀌지 않고 유효한 정렬된 DKIM 서명이 유지되면 DMARC를 충족하는 데 도움이 됩니다. 이메일 전달을 읽고 전달 과정의 SPF 실패를 전체 인증 실패와 혼동하지 마세요.
DKIM과 정렬의 함정
정렬은 “정상 작동”하던 DKIM 설정이 기대에 못 미치는 지점입니다. 서명이 유효해도 서명 도메인이 사용자에게 보이는 From 도메인과 정렬되지 않고 SPF도 유효한 정렬 경로를 제공하지 않으면 DMARC가 실패할 수 있습니다. DNS 문제일 때도 있지만 보통 업체 설정을 확인해야 합니다.
흔한 예시:
From: ceo@example.com
DKIM 서명 도메인:d=sendgrid.net
결과: DKIM은 통과할 수 있지만 서명 도메인이example.com과 정렬되지 않아 DKIM 기반 DMARC 정렬은 실패할 수 있습니다.
Google은 대량 발신자의 화면상 From 도메인이 조직 도메인 수준에서 SPF 또는 DKIM과 정렬되어야 한다고 안내합니다. 업체가 자체 도메인으로 서명하면 서명 자체는 유효해도 DKIM 정렬 목적에는 맞지 않을 수 있습니다.
업체에 따라 도메인 인증, 화이트 라벨링, 사용자 지정 return-path라는 설정 이름을 볼 수 있습니다. return-path는 SPF 정렬에 영향을 주며 DKIM 서명 도메인을 직접 바꾸지는 않습니다. DKIM은 도메인 인증을 통해 최종 서명이 다음과 같도록 구성합니다.
DKIM-Signature: ... d=example.com; s=s1; ...이런 DKIM 설정이 DMARC를 충족하는 데 도움이 됩니다. 정렬되지 않은 도메인의 서명만으로는 그 목적에 충분하지 않습니다.
DKIM 설정의 기존 방식과 개선된 방식
기존 방식은 수동적이고 오류에 취약합니다. 도메인, 업체, 선택자, DNS 특이 사항을 매번 직접 처리합니다. 개선된 방식은 표준화입니다. 반복 가능한 발신 모델을 정하고 DNS 검사를 한곳에 모아 도메인마다 같은 문제를 다시 풀지 않게 합니다.
| 기존 방식 | 개선된 방식 |
|---|---|
| 임의의 도구에서 키를 만들고 발신자와 맞기를 기대 | 실제 발신 시스템에서 DKIM 생성 |
| TXT 값을 하나씩 붙여 넣고 지원 요청을 기다림 | 가능하면 업체 관리형 서명을 사용하고 명령줄로 검증 |
| 도메인마다 특별한 사례로 처리 | 고객과 팀 도메인에 공통 절차 사용 |
| 캠페인 실패 후 스팸 문제 진단 | 첫 운영 발신 전에 DNS, 정렬, 헤더 점검 |
TrekMail은 이 모델에 맞는 기능을 안내합니다. 한 대시보드에서 여러 자체 도메인을 운영하고, 사서함별 과금 대신 공유 저장 공간을 사용하며, 기존 사서함을 IMAP으로 옮기고, 요금제에 따라 BYO SMTP 또는 포함된 SMTP를 선택할 수 있습니다. 유료 요금제의 안내 시작 가격은 월 $3.50이며 현재 결제 조건을 확인해야 합니다. 메일 인프라 관리 부담을 줄이려는 팀, 중소기업, 대행사, MSP를 대상으로 합니다.
DNS보다 프로세스가 문제라면 고객 이메일 관리를 읽어 보세요. 다중 도메인 환경의 전달 문제는 레코드보다 관리 책임에서 먼저 비롯되는 경우가 많습니다.
최종 DKIM 점검 목록
올바른 DKIM 설정에는 실제 서명 시스템, 정확한 DNS 호스트 이름, 완전한 키, 공개 DNS 검증, DMARC용 정렬된 서명이 필요합니다. 이 중 하나라도 잘못되면 전체 인증 흐름이 약해질 수 있습니다.
- 발신 메일에 서명하는 시스템을 확인합니다.
- 업체의 선택자와 레코드 유형을 정확히 게시합니다.
- DNS 호스트가 전체 이름을 명시적으로 요구하지 않는 한 호스트 입력란에
selector._domainkey를 사용합니다. - 2048비트 키를 온전히 유지합니다. DNS 화면이 요구할 때만 따옴표 문자열을 나눕니다.
dig또는nslookup으로 검증합니다.- 테스트 메일의 헤더에서
dkim=pass와 정렬된header.d를 확인합니다. - 운영 시작 후 DMARC 결과를 확인합니다.
핵심은 정확성입니다. 관리 요소를 줄이고 싶다면 TrekMail에서 도메인과 발신 경로를 표준화하고 DNS를 한곳에서 확인하며, 매번 개별적으로 해결하는 대신 공통 운영 절차를 사용하세요.
