DKIM 레코드: 선택자, 키 교체와 오류 진단

열람률 하락은 DNS 오류의 증거가 아닙니다. 개인정보 보호와 추적 방식도 영향을 줍니다. 제목과 대상뿐 아니라 DKIM 레코드를 포함한 인증도 확인하세요.

SPF가 봉투 신원에 대한 발신 IP를 확인한다면 DKIM, DomainKeys Identified Mail은 봉인과 비슷합니다. 서명 도메인과 서명 범위의 무결성을 검증하며 모든 내용이나 사람의 신원을 증명하지는 않습니다. 2024년 이후 Google과 Yahoo는 특정 대량 발신자에 추가 요건을 적용합니다. DKIM 오류가 필터링에 영향을 줄 수 있어도 모든 받은편지함에서 자동으로 사라지거나 스팸이 되는 것은 아닙니다.

창업자에게는 십 분짜리 설정처럼 보일 수 있지만 소요 시간을 보장하지는 않습니다. 도메인 500개를 관리하는 MSP는 키 교체, 선택자와 DNS 구문을 지속적으로 관리해야 하며 금요일 밤 9시에 문제가 발견될 수도 있습니다.

이 실무 가이드에서는 DKIM 레코드의 DNS 동작, TXT 문자열당 255옥텟 제한과 ESP의 확인 표시가 실제 전송 결과와 다를 때의 진단 방법을 설명합니다.

DKIM 레코드란?

DKIM 레코드는 보통 DNS TXT로 공개 암호 키를 게시합니다. 수신자는 서명 도메인의 서명과 해당 정규화 방식에서 서명된 내용의 무결성을 확인합니다. 표시되는 From 도메인이나 모든 메시지 요소를 자동으로 인증하는 것은 아닙니다.

키는 selector._domainkey.yourdomain.com에서 조회하며 selector가 키를 지정합니다. 다음은 축약된 설명용 예로 실제 게시할 수 없습니다.

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

v=DKIM1은 버전, k=rsa는 키 유형, p=는 base64 인코딩된 공개 키입니다. 대응하는 개인 키는 안전한 발송 인프라에 보관하며 DNS에 게시하지 않습니다. DKIM 레코드 생성 설명에서 필드별 구문과 구성을 확인할 수 있습니다.

DKIM의 서명 범위와 의미

DKIM은 단순한 보안 확인 표시가 아닙니다. 서명 도메인과 서명된 내용의 무결성을 연결하지만 모든 헤더나 작성자의 전체 신원을 증명하지는 않습니다.

서버는 From, Subject, Date, To, Message-ID 같은 헤더와 서명 범위의 본문을 선택합니다. From은 서명해야 하며 나머지는 구성에 따라 달라집니다. 보통 SHA-256을 사용하고 개인 키로 서명한 결과를 DKIM-Signature 헤더에 넣습니다. 실제 범위와 정규화는 서명 설정으로 결정됩니다.

Gmail이나 Outlook 같은 수신자는 다음 검사를 수행합니다.

1. DKIM-Signature에서 선택자와 서명 도메인을 읽습니다.
2. DNS의 selector._domainkey.yourdomain.com에서 공개 키를 조회합니다.
3. 공개 키로 암호학적 서명을 검증합니다. 메시지를 복호화하는 작업은 아닙니다.
4. 받은 내용의 정규화된 서명 범위에서 해시를 다시 계산합니다.
5. 일치 여부와 키 및 서명의 다른 조건을 함께 확인해 성공이나 실패를 결정합니다.

통과는 두 가지 속성을 뒷받침합니다. 서명 도메인에 대한 서명의 진정성과 서명된 정규화 내용의 무결성입니다. 허용되는 정규화가 차이를 흡수할 수 있으므로 모든 바이트 변경이 실패를 일으키지는 않습니다. 공개 키로 이러한 검증이 가능합니다. RFC 6376은 기본 동작과 구현 조건을 설명합니다.

전달과 DKIM 유지 조건

대표가 보낸 청구서를 거래처가 개인 Gmail로 전달하는 상황을 생각해 보세요. 원래 봉투 발신자가 유지되고 전달 서버 IP가 허용되지 않았다면 SPF가 실패할 수 있습니다. DMARC는 통과하고 정렬된 SPF도, 유효하고 정렬된 DKIM 서명도 없을 때 실패합니다. 이후 분류와 거부는 수신 정책에 달려 있습니다.

DKIM은 관련 서명 헤더와 본문이 유효하게 유지되고 키와 다른 조건도 맞으면 전달 후에도 통과할 수 있습니다. 최종 수신자가 원래 서명을 DNS로 검증할 수 있지만 중간 서비스의 변경으로 무효화될 수도 있습니다.

따라서 SPF만 의존하지 마세요. 적절한 SPF 설정과 DKIM을 함께 구성하고 이메일용 SPF 가이드로 기반을 확인하세요. DMARC는 정렬된 두 인증 방식 중 하나로 통과할 수 있지만 전달 자체를 보장하지 않습니다.

TrekMail은 SRS (Sender Rewriting Scheme)를 통한 전달을 설명합니다. 봉투 주소를 바꿔 전달 서비스의 SPF에 도움이 될 수 있지만 원래 From 정렬을 복구하지 않습니다. 실제 관리형 또는 자체 SMTP 경로에서 DKIM 서명이 활성화되어 있는지 현재 구성을 확인하세요.

선택자로 여러 DKIM 키 관리하기

DKIM 선택자는 수신자가 조회할 공개 키를 지정합니다. 잘못된 선택자나 DNS 이름은 중요한 원인 중 하나이지만 대부분의 실패 원인이라고 단정할 근거는 없습니다.

SPF는 평가되는 DNS 이름별 정책 하나를 사용하고 DKIM은 selector._domainkey.yourdomain.com에 여러 선택자를 둘 수 있습니다. 예를 들어 서비스별로 열 개를 동시에 운영할 수 있지만 실제 제공업체와 DNS 한도를 확인해야 하며 무제한 기능을 약속하는 것은 아닙니다.

여러 선택자가 필요한 이유

Google Workspace와 Mailchimp 등 여러 서비스를 사용한다면 별도 키와 선택자가 일반적으로 바람직합니다. 개인 키 공유는 노출 범위를 넓히고 철회를 어렵게 합니다. 기술적으로 가능한지와 서비스가 지원하는 구성을 확인하세요. 다음 이름은 현재 값이 아닌 예시입니다.

• Google Workspace: 선택자가 google이면 google._domainkey.yourdomain.com에 키를 게시할 수 있습니다.
• Mailchimp: k1이나 k2를 사용할 수 있습니다. k1._domainkey.yourdomain.com에 필요한 TXT 또는 CNAME을 실제 지침으로 확인하세요.
• TrekMail: tm1과 tm1._domainkey.yourdomain.com은 예입니다. 현재 지원하는 TXT 또는 CNAME 구성을 사용하세요.

분리하면 마케팅 서비스 사고 후 k1 같은 해당 키만 철회할 수 있습니다. 다른 키를 함께 철회할 필요를 줄이지만 캐시, 공유 구성과 평판 때문에 무중단을 보장하지는 않습니다. 선택자 가이드에서 이름, 구문과 ESP가 배정한 값 확인법을 살펴보세요.

흔한 DNS 이름 오류

google._domainkey.yourdomain.com을 의도했지만 패널이 도메인을 다시 붙여 google._domainkey.yourdomain.com.yourdomain.com으로 만들 수 있습니다. 원래 위치의 조회가 NXDOMAIN을 반환할 수 있고 ESP 표시는 오래된 결과일 수 있습니다. DNS 상태 확인 문서로 실제 이름과 DNS 응답을 조사하세요.

키 길이와 교체 정책

키는 DKIM 보안의 중요한 요소입니다. 오 년 전의 설정은 현재 알고리즘, 길이, 보관 방식과 수신 요건으로 다시 평가할 필요가 있습니다.

2048비트 키 권장

1024비트 RSA는 오랫동안 사용되었습니다. Google은 최소 길이를 유지하면서 더 강한 구성에 2048비트를 권장합니다. Yahoo의 최신 지침은 별도로 확인하세요. cPanel이나 Postfix가 1024비트로 구성된 시점이 2019년 이전이라면 점검이 필요하지만 모든 검증이 반드시 실패한다고 볼 수는 없습니다.

512비트는 현대 요건에 부족합니다. dkim=perm_fail과 "weak key" 또는 "policy"가 보이면 전체 이유를 조사하세요. 2048비트 새 키와 검증된 전환을 고려하고 유출이면 즉시 사고 대응을 하세요. Google 발신자 가이드라인을 참고하세요.

교체 주기

연간 교체는 내부 관리 정책의 예이지 보편적인 DKIM 의무는 아닙니다. 위험과 제공업체 운영으로 주기를 정하세요. 개인 키가 유출되면 공개 키로 검증할 수 있는 동안 공격자가 서명할 수 있으므로 즉시 대응해야 합니다. 이메일 도메인 평판도 모니터링하세요.

개인 키를 중요한 비밀 정보로 취급하세요. 오 년간 같은 키를 사용했다면 정책과 위험을 재평가해야 합니다. 안전한 저장, 접근 통제와 사고 대응도 교체 일정만큼 중요합니다.

DNS의 255옥텟 제한과 해결 방법

2048비트로 전환하면 길이가 문제가 될 수 있습니다. 2048비트 공개 키는 base64로 대략 400자이고 DNS TXT 문자열은 최대 255옥텟입니다. 패널은 분할, 거부 또는 잘못된 처리를 할 수 있으며 대부분 몰래 잘라낸다고 단정할 수는 없습니다.

긴 값은 같은 TXT 레코드 안의 여러 인용 문자열로 나눌 수 있습니다. RFC 6376에 따라 수신자는 이를 연결해 검증합니다. 실제 키를 축약하거나 예시 텍스트로 대체해서는 안 됩니다.

축약된 예시로 게시할 수 없습니다. 긴 입력 처리 방식은 제공업체마다 다릅니다.

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

문자열 두 개를 연결하는 도식적 예입니다. 자리표시자를 완전한 키로 바꿔야 합니다.

( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3"
  "...rest_of_key_here..." )

입력 방식은 DNS 서비스마다 다릅니다. 괄호 표기는 영역 파일 문법일 수 있어 모든 패널에 그대로 입력할 수는 없습니다. 주요 제공업체 DNS 설정에서 Cloudflare, Route 53, GoDaddy 등의 현재 지침을 확인하세요.

지원되는 CNAME 구성은 공개 키 게시를 위임할 수 있습니다. 설명된 모델은 255자보다 긴 키 대신 짧은 CNAME 하나를 게시합니다. 로컬 작업을 줄일 수 있지만 대상 TXT, 키 일치와 캐시를 점검해야 합니다. 같은 CNAME이 유지된다고 키 교체가 자동으로 안전한 것은 아니며 동일 이름에 TXT를 함께 둘 수 없습니다.

설정 검증 절차

ESP의 "Verified"는 몇 시간 또는 며칠 전 데이터일 수 있습니다. 현재 DNS와 실제 서명된 테스트 메시지를 함께 확인하세요. DNS 조회만으로 발신 서버의 서명을 검증할 수 없고 조회 자체도 캐시를 사용할 수 있습니다.

단계 1: 이름과 레코드 확인

Linux와 macOS 터미널에서 확인하세요. Windows에서는 nslookup을 사용할 수 있습니다.

# macOS / Linux
dig txt selector._domainkey.yourdomain.com +short

# Windows
nslookup -q=txt selector._domainkey.yourdomain.com

selector와 yourdomain.com을 실제 선택자와 도메인으로 바꾸세요.

키 값이 v=DKIM1으로 시작할 수 있지만 이 버전 태그는 모든 유효한 키 레코드에서 필수인 것은 아닙니다. NXDOMAIN을 받으면 조사하세요. NXDOMAIN은 해당 응답에서 이름이 없음을 나타냅니다. 선택자, 게시 위치와 캐시를 확인하고 30분 후 재시도는 고정된 반영 시간이 아닌 예로 보세요.

단계 2: 키 내용 확인

레코드가 있어도 실패한다면 원시 출력을 확인하세요.

dig txt selector._domainkey.yourdomain.com +short

두 가지를 점검합니다.

• 잘림: base64 값이 200자보다 짧은데 2048비트 키라고 표시된다면 전체 디코딩 키를 확인할 단서입니다. 제공업체가 잘랐다는 확정 증거는 아닙니다.
• 문자 처리: base64의 줄바꿈, 공백과 이스케이프 처리 방식을 확인하세요. 모든 시각적 변화가 키를 바꾸지는 않습니다. 실제 게시되고 디코딩된 값을 의도한 공개 키와 비교하세요.

단계 3: 테스트 전송과 헤더 검토

자체 Gmail 계정에 보내 점 세 개 메뉴의 "원본 보기"를 여세요. Authentication-Results 중 수신 서비스가 추가한 신뢰할 수 있는 결과만 사용하세요. 다음은 예입니다.

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=selector header.b=AbCdEfGh;
  spf=pass (...);
  dmarc=pass (...)

dkim=pass는 해당 시험의 성공입니다. fail, neutral, perm_fail, temperror는 전체 이유와 구현 표기를 함께 읽으세요. neutral이 항상 오류인 것은 아닙니다. DKIM 설정 설명과 TrekMail의 최초 설정 체크리스트로 관련 인증을 확인하세요.

DKIM 실패: 세 가지 사례

올바른 선택자의 레코드만으로 유효한 서명을 보장하지는 않습니다. 계속 실패하면 메시지 처리, 실제 키와 DNS 응답을 조사해야 합니다.

상세 DKIM 실패 가이드가 추가 정보를 제공합니다. 다음 세 가지는 자주 만나는 사례이지만 모든 운영 문제의 검증된 순위는 아닙니다.

사례 1: "Body Hash Did Not Verify"

이메일 전달률에서 이 오류는 본문 해시가 일치하지 않음을 뜻합니다. 서명 후 해당 내용이 변경되었을 수 있습니다. 헤더 서명 검증이 별도로 성공했다는 증거는 아니므로 두 검사를 모두 조사하세요.

가능한 원인:

• 외부 발신자 배너: 게이트웨이가 "EXTERNAL EMAIL: CAUTION"을 넣을 수 있습니다. 검증 전에 서명 본문을 허용 정규화 밖에서 변경하면 실패할 수 있습니다. Microsoft 365 메일 흐름 규칙도 확인하세요.
• 법적 고지: 서명 후 게이트웨이가 15줄 고지를 추가하면 본문 해시가 달라질 수 있습니다. 자체 발신 경로에서는 최종 내용을 서명하세요.
• 보안 URL 재작성: Mimecast, Proofpoint와 Defender for Office 365가 google.com을 protect.mimecast.com/s/...으로 바꿀 수 있습니다. 서명 범위의 변경은 검증을 깨뜨릴 수 있으며 시점과 범위가 중요합니다.

직접 관리하는 마지막 내용 수정 후 서명하세요. 일부 로컬 오류를 줄이지만 수신자나 전달 서비스의 이후 변경까지 막지는 못합니다. TrekMail의 실제 서명 경로와 현재 설정을 확인하고 발송 오류 문제 해결 문서로 조사하세요.

사례 2: 정렬 문제

유효한 서명과 DMARC 실패가 함께 나타날 수 있습니다.

dkim=pass (signature was valid)

DKIM은 통과하지만 필요한 도메인의 서명인지 확인해야 합니다. DKIM 정렬과 다른 유효한 인증을 조사하세요. DMARC 실패가 모든 서비스의 자동 스팸 분류는 아닙니다.

DMARC는 d= 서명 도메인과 Header From 도메인을 비교합니다. 엄격 정렬은 정확한 일치, 완화 정렬은 조직 도메인 일치를 사용할 수 있습니다. 유효하고 정렬된 DKIM 서명 하나 또는 통과하고 정렬된 SPF면 충분합니다.

예를 들면 다음과 같습니다.

Header From:        ceo@yourcompany.com
DKIM d= tag:        sendgrid.net

서명은 sendgrid.net에 대해 유효합니다. 그러나 적용되는 DMARC 정책은 수신자 도메인이 아니라 표시 발신 도메인 yourcompany.com의 정책입니다. sendgrid.net != yourcompany.com이므로 이 서명은 정렬되지 않습니다. 다른 정렬된 인증도 없다면 DMARC가 실패합니다.

ESP의 도메인 인증이나 사용자 지정 서명을 확인하세요. 지원되는 자체 DKIM 키를 통해 d=를 yourcompany.com으로 설정해 sendgrid.net을 대신할 수 있습니다. 기능은 서비스와 요금제마다 다릅니다. DMARC 정렬도 이해하고 실제 경로를 시험하세요.

사례 3: 오래되거나 약한 키

dkim=perm_fail에 "policy"나 "weak key"가 있으면 512비트 또는 768비트 키가 관련될 수 있지만 다른 원인도 있습니다. 실제 키와 전체 설명을 확인하세요. 오래된 길이는 최신 요건에 부족할 수 있으나 표기만으로 특정 길이를 확정할 수는 없습니다.

필요하면 2048비트 키와 새 선택자를 생성하세요. 게시와 검증 후 서명을 전환하고 전송 중인 정상 메시지에 필요한 동안 이전 공개 키를 유지합니다. 유출이라면 신속한 철회가 우선일 수 있습니다. 아래 로컬 생성 지침을 참고하세요.

키 생성 방식의 안전성

DKIM에는 적절한 공개 키와 보호되는 개인 키가 필요합니다. 키를 화면에 표시하는 웹사이트를 발견했다면 어디서 생성하고 누가 볼 수 있는지부터 확인하세요.

알 수 없는 서버가 생성한 개인 키는 저장되거나 노출되었을 수 있습니다. 신뢰할 수 있는 로컬 브라우저 생성처럼 화면 표시만으로 유출을 확정할 수는 없지만, 불명확한 웹서비스에 운영 비밀을 맡기지 마세요. 노출되면 대응해야 하며 철회 후에도 무한히 유효한 것은 아닙니다.

생성 방식 비교

자체 서버에서는 OpenSSL로 로컬 생성할 수 있습니다. 다음 예를 실행하기 전에 파일 권한과 저장을 보호하세요.

# Generate the private key
openssl genrsa -out dkim-private.key 2048

# Extract the public key
openssl rsa -in dkim-private.key -pubout -out dkim-public.key

# View the public key for DNS (strip headers, format as single line)
cat dkim-public.key

개인 키를 보호하고 올바르게 인코딩된 공개 키 내용만 DNS에 넣으세요. 표시 명령은 PEM 헤더를 자동 제거하지 않습니다. "검증"을 위해 개인 키를 이메일로 보내지 말고 신뢰할 수 있는 경로로 요청을 확인하세요.

창업자, 운영자와 에이전시에는 제공업체 관리가 편리할 수 있습니다. 해당 서비스가 생성, 보호와 교체를 실제 지원하는지 확인하세요.

수동 관리와 자동화 비교

키 교체는 운영 비용이 드러나는 부분입니다. 다음 연간 일정은 정책 예이며 제공업체가 작업해도 적절한 확인이 필요합니다.

도메인별 연간 수동 교체 예

1. s2026 같은 새 선택자로 RSA 키를 만듭니다.
2. s2026._domainkey.yourdomain.com에 새 공개 키를 게시합니다.
3. 예에서는 DNS에 48시간을 잡지만 실제 대기는 TTL, 캐시와 검증 결과로 정합니다.
4. 서버를 새 개인 키로 전환하고 시험합니다.
5. 예에서는 선택자 둘을 7일 유지하지만 실제 겹침은 대기열, 서명 유효 기간과 위험에 맞춥니다.
6. 적절한 기간 후 이전 선택자를 제거하되 유출 시 더 빠른 철회가 필요할 수 있습니다.
7. 보존 정책에 따라 이전 개인 키를 안전하게 폐기합니다.

예는 도메인당 연간 7단계입니다. 도메인 50개에는 350작업이지만 실제 업무량을 고정하는 수치는 아닙니다. 단계 5의 겹침을 생략하면 전송 중인 메일의 검증에, 단계 6을 잊으면 오래된 키의 유지 기간에 영향을 줄 수 있습니다. 자동화와 검증을 함께 사용하세요.

도메인 하나는 수동 관리가 가능할 수 있습니다. 50개에서는 자동화가 반복 작업과 일정을 도울 수 있습니다. 그러나 어느 방식도 자동으로 불가능하거나 무결점은 아닙니다. 게시, 교체와 시험 기록을 남기세요.

TrekMail의 DKIM 관리

TrekMail은 별도 프로젝트 다섯 개를 운영하는 창업자부터 고객 도메인 800개를 관리하는 MSP까지 여러 도메인 관리자를 대상으로 합니다. 실제 발송 경로의 현재 DKIM 구성을 평가하세요.

CNAME을 이용한 키 게시 위임

설명된 모델은 도메인 추가 시 CNAME 하나를 제공합니다. 다음은 예시이며 현재 대상 이름과 지원 여부를 확인해야 합니다.

tm1._domainkey.yourdomain.com  CNAME  tm1._domainkey.trekmail.net

로컬 참조가 유지되는 동안 업체가 키 게시를 관리할 수 있습니다. 하지만 새 선택자, 캐시와 이전 서명의 겹침을 어떻게 처리하는지 확인하세요. 같은 선택자의 키를 단순 교체하면 전송 중인 메일의 이전 서명 검증이 실패할 수 있습니다. 도메인 80개에서도 모니터링과 사고 대응이 필요하며 중단이나 작업이 없다는 보장은 아닙니다.

Pro 월 $8로 도메인 100개를 관리하며 연간 수동 작업 700개를 비교한 수치는 선택한 절차의 예시 계산입니다. 실제 절약이나 최신 가격을 보장하지 않습니다.

안내형 DNS 마법사

설명된 마법사는 MX, SPF, DKIM, DMARC 작성을 돕고 설정을 확인합니다. 현재 기능, 권한 있는 DNS와 관련 캐시 및 실제 서명 메일을 검증하세요. 대시보드 표시는 모든 경로의 완전한 검증이 아닙니다. 필수 DNS 레코드를 참고하세요.

플랫폼 요금 모델

설명에서 Starter는 월 $3.50에 도메인 50개와 도메인당 사용자 100명, Pro는 월 $8에 도메인 100개와 사용자 300명, Agency는 도메인 1,000+개입니다. 저장 공간은 공유로 설명됩니다. 최신 가격과 한도 및 기능을 확인하세요. 모든 추가 사서함이 항상 무료인 것은 아닙니다.

DKIM은 DNS 설정의 일부로 설명됩니다. 자체 SMTP를 포함해 현재 각 요금제와 경로에서 실제 지원하는 인증을 확인하세요.

DKIM 레코드 관리: 자체 운영과 위임

결론

올바른 DKIM 레코드는 현대 인증과 2025년 이후 적용되는 발신 요건에 중요합니다. DKIM이 없다고 정렬된 SPF가 통과하는 상황에서도 DMARC가 반드시 실패하는 것은 아닙니다. 모든 전달이 평판을 손상시키는 것도 아닙니다. 두 방식과 수신 정책을 확인하세요.

2048비트 RSA 같은 적절한 키, 올바른 선택자, 완전한 TXT 게시와 Header From에 대한 정렬부터 확인하세요. 이후 안전한 교체, DMARC 정책과 Google Postmaster Tools 등의 가용 데이터 모니터링을 구성하세요.

SPF, DKIM, DMARC 비교는 각 역할을 설명합니다. 실제 문제가 있다면 스팸함 분류 문제 줄이기로 우선순위를 정하고 구체적인 오류에 맞춰 조사하세요.

여러 도메인에서는 키, 게시와 정렬 오류가 관련 경로에 영향을 줄 수 있습니다. 위임은 수작업을 줄이지만 이 오류들을 완전히 없애지는 않습니다. 요금제 확인과 함께 신용카드 없이 도메인 10개를 제공한다고 설명된 무료 상품의 최신 조건을 확인하세요.