DKIM 키 생성기: DNS 설정과 서명 검증

DKIM 키 생성기를 찾고 있다면 도메인이 아직 메일에 서명하지 않거나, 서명은 하지만 수신 서버가 제대로 검증하지 못하는 상황일 수 있습니다. 서명이 없으면 필터링에 불리할 수 있습니다. DKIM 설정 오류는 DMARC 실패로 이어질 수도 있지만, 정렬된 SPF가 통과하면 DMARC는 통과할 수 있습니다. 인증 문제가 생기면 비밀번호 재설정 메일, 청구서, 영업 메일이 스팸함이나 격리 영역으로 분류될 수 있습니다.

다행히 해결 절차는 생각보다 명확합니다. DKIM 키 생성기는 발신 시스템에 보관할 개인키와 DNS에 게시할 공개키를 한 쌍으로 만듭니다. 수신 서버는 공개키로 서명 도메인의 서명과 서명된 데이터의 무결성을 검증합니다. 이때 설정된 정규화 규칙을 적용하며, DKIM만으로 화면에 표시되는 발신자의 신원을 확인하는 것은 아닙니다.

메일 환경을 처음 구성한다면 비즈니스 이메일 종합 가이드부터 읽어 보세요. 이미 자체 도메인을 사용한다면 이 글에서 DKIM 키 생성기의 출력 형식, 키 길이, 선택자의 역할과 DNS 레코드를 안전하게 게시하는 절차를 확인할 수 있습니다.

DKIM 키 생성기가 하는 일

DKIM 키 생성기는 암호화 키 쌍을 만듭니다. 개인키는 발신 시스템에 보관하며 발신 메시지에 서명하는 데 사용합니다. 공개키는 선택자 아래 DNS에 게시합니다. 수신 서버는 이를 조회해 메시지 헤더의 DKIM 서명을 검증합니다.

특별한 마법은 아닙니다. 적절한 DKIM 키 생성기는 다음 작업을 수행합니다.

발신 시스템에서 사용할 개인키를 생성합니다.
개인키에 대응하는 공개키를 추출합니다.
공개키를 selector._domainkey.example.com에 게시할 DNS TXT 레코드 형식으로 정리합니다.

어려운 부분은 암호 계산보다 운영 설정입니다. 선택자, DNS 호스트 이름, 줄바꿈 처리와 발신 시스템 설정이 일치해야 실제 메시지의 서명을 검증할 수 있습니다.

RFC 6376에서는 선택자를 사용해 여러 키를 게시하고 차례로 교체할 수 있도록 합니다. RFC 8301은 RSA 키를 최소 1024비트로 요구하며, 일반적으로 2048비트가 더 적절한 기본 선택입니다. DKIM 키 생성기가 여전히 512비트나 SHA-1을 권한다면 다른 도구를 선택하세요.

올바른 출력 형식

적절한 DKIM 키 생성기는 서명용 개인키와 DNS에 게시할 공개키 레코드를 제공합니다. 레코드는 도메인 루트가 아니라 선택자 호스트 이름에 게시하며, 공개키는 p= 태그에 넣습니다.

기본 형식은 다음과 같습니다.

Host: tm2026._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

온라인 DKIM 키 생성기 대신 OpenSSL로 로컬에서 키 쌍을 만들 수도 있습니다. 웹 도구에는 개인키가 노출될 위험이 있습니다. 아래 마지막 명령도 개인키의 비밀 정보를 출력하므로 결과를 공유하거나 로그에 남기지 마세요.

openssl genrsa -out dkim-private.pem 2048
openssl rsa -in dkim-private.pem -pubout -out dkim-public.pem
openssl rsa -in dkim-private.pem -text -noout

공개키를 대부분의 DNS 관리 화면에서 요구하는 한 줄 값으로 변환합니다.

awk 'NF {sub(/\r/, ""); printf "%s",$0;}' dkim-public.pem \
| sed 's/-----BEGIN PUBLIC KEY-----//; s/-----END PUBLIC KEY-----//g'

DNS 제공업체가 긴 TXT 값을 따옴표로 묶인 여러 문자열로 나누는 것은 같은 레코드 안에서라면 가능합니다. 문자열은 연결해 해석됩니다. 키 중간에 공백을 넣거나 각 부분을 별도 TXT 레코드로 게시하면 안 됩니다.

선택자는 키 자체가 아니라 키를 찾는 이름입니다. 서명에 s=tm2026이 있으면 수신 서버는 tm2026._domainkey.yourdomain.com을 조회합니다. 해당 레코드가 없으면 DKIM을 검증할 수 없습니다.

선택자와 키 길이 정하기

2048비트 키를 생성하고 키 교체에 적합한 선택자 이름을 지정할 수 있는 DKIM 키 생성기를 선택하세요. RSA와 SHA-256을 사용하는 것은 발신 시스템의 서명 설정이지 키 생성기가 정하는 기능이 아닙니다. 선택자는 장식용 이름이 아니라 운영용 버전 표시에 가깝습니다.

키의 사용 시점과 발신 시스템을 알아볼 수 있는 이름을 사용하세요. 다음과 같은 이름이 적절합니다.

tm2026
app1q1
marketing2026

다음 방식은 피하는 편이 좋습니다.

default를 계속 사용하기
운영 환경에서 test 사용하기
모든 발신 시스템에 dkim을 재사용하기

선택	사용 여부	이유
1024비트 RSA	불가피한 경우에만	일부 환경에서 허용되지만 권장 목표가 아니라 최소 기준입니다.
2048비트 RSA	사용 권장	현대적인 발신 및 DNS 환경에서 일반적으로 적절한 기본값입니다.
영구 선택자 하나	권장하지 않음	키 교체가 복잡해지고 사고 대응이 늦어질 수 있습니다.
버전별 선택자	사용 권장	기존 키를 폐기하기 전에 새 키를 게시할 수 있습니다.

RFC 8301은 1024비트를 최소 기준으로 정하고 2048비트를 권장합니다. Google의 대량 발신자 지침도 SPF와 DKIM을 요구하며, 개인 Gmail 계정으로 직접 보내는 메일에서는 SPF 또는 DKIM 중 적어도 하나가 From 도메인과 정렬되어야 합니다. 적용 조건은 Google의 발신자 지침 FAQ에서 확인하세요.

DKIM 키 생성기를 선택할 때 단순히 키 생성 가능 여부만 보지 마세요. 2048비트 지원, 명확한 선택자 이름과 편리한 키 교체 절차가 실제 운영에서 더 중요합니다.

메일 운영을 고려한 DNS 레코드 게시

DKIM 키 생성기 사용은 작업의 일부일 뿐입니다. 발신 시스템이 사용하는 정확한 선택자 호스트 이름에 TXT 레코드를 게시하고 DNS 캐시를 고려해 공개키 조회 여부를 확인한 다음 서명을 활성화하세요.

자주 발생하는 오류는 다음과 같습니다.

@에 TXT 레코드를 게시하고, 올바른 위치인 selector._domainkey를 사용하지 않습니다.
base64 키만 넣지 않고 PEM 시작과 끝 표시까지 DNS에 붙여 넣습니다.
DNS에서 레코드를 조회할 수 있기 전에 서명을 활성화합니다.
메일 플랫폼에 잘못된 선택자를 설정합니다.

TrekMail에 도메인을 설정할 때는 플랫폼의 DNS 안내를 따르세요. 도메인 추가 문서에 해당 DKIM TXT 값을 포함한 필수 레코드가 설명되어 있습니다. 자체 SMTP를 사용한다면 실제 발신 제공업체의 키와 선택자를 사용해야 합니다. 저장 후에는 내장 검증 절차를 실행하세요. 문제가 남아 있으면 DNS 상태 확인을 이용할 수 있습니다.

전달된 메일에서는 SPF가 실패해도 DKIM이 통과할 수 있습니다. DKIM 서명이 From 도메인과 정렬되어 있다면 DMARC도 통과할 수 있습니다. 다만 서명된 내용이 정규화 규칙상 검증에 영향을 주는 방식으로 변경되지 않아야 합니다. 전달 과정에서 SPF만 실패하는 것은 예상 가능한 상황입니다. 관련 내용은 도메인 이메일을 Gmail로 전달하기를 참고하세요.

DKIM 키가 실제로 작동하는지 확인하기

DKIM 키 생성기를 사용하고 레코드를 게시한 뒤 실제 메시지 헤더로 확인하세요. DNS 조회가 정상이라는 것만으로 끝내지 마세요. 발신 메일에서 dkim=pass가 나타나는지, 도메인 정렬이 DMARC 조건을 충족하는지 점검해야 합니다.

Gmail 사서함으로 메시지를 보내 원본 헤더를 확인하세요. 정상 결과는 다음과 같은 형태일 수 있습니다.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=tm2026 header.b=...
       spf=pass smtp.mailfrom=example.com
       dmarc=pass header.from=example.com

DKIM이 실패하면 다음 순서로 확인하세요.

DKIM-Signature 헤더의 s= 선택자를 확인합니다.
dig로 해당 DNS 호스트 이름을 정확히 조회합니다.
DNS 공개키가 발신 시스템의 개인키와 한 쌍인지 확인합니다.
발신 시스템이 d=에 올바른 서명 도메인을 사용하는지 확인합니다.
메일링 리스트, 자동 바닥글 또는 중계 서버가 서명된 헤더나 본문을 변경했는지 확인합니다.

dig +short TXT tm2026._domainkey.example.com

선택자 호스트 이름, 검증과 정렬을 설명하지 않는 DKIM 키 생성기는 문제 해결을 어렵게 만들 수 있습니다. DNS에 키가 있어도 d= 도메인이 표시되는 From 도메인과 정렬되지 않으면 DKIM으로 DMARC 조건을 충족하지 못합니다. 완화된 정렬에서는 조직 도메인이 같으면 되지만 엄격한 정렬에서는 정확히 일치해야 합니다. 이 경우에도 정렬된 SPF가 통과하면 DMARC는 통과할 수 있습니다.

전체 구성을 점검하려면 자체 도메인 이메일 만들기, 이메일 전달 설정과 TrekMail의 스팸 문제 해결 문서도 참고하세요.

개별 DKIM 도구와 통합 운영 방식 비교

DKIM 키 생성기, DNS 관리 화면, 앱 메일용 SMTP 업체, 뉴스레터 업체와 불완전한 DMARC 설정을 따로 관리하면 변경 사항을 놓치기 쉽습니다. 제공업체 변경, 잘못된 키 교체나 메일 전달 과정에서 숨겨져 있던 인증 문제가 드러날 수 있습니다.

통합 운영 방식에서는 도메인, 사서함, DNS 검사와 발신 설정을 하나의 흐름으로 관리합니다.

TrekMail에서는 요금제와 구성에 따라 다음 기능을 이용할 수 있습니다.

하나의 대시보드에서 자체 도메인과 IMAP 사서함 관리.
Nano의 자체 SMTP 또는 해당 유료 요금제에 포함된 관리형 SMTP.
기존 메일을 IMAP으로 가져오는 내장 마이그레이션.
요금제에 포함되는 경우 캐치올, 사서함 전달과 API 접근.
SPF, DKIM과 DMARC를 함께 고려하는 DNS 및 인증 설정 흐름.

여러 도메인을 관리하는 대행사나 MSP라면 사용자별 요금뿐 아니라 여러 도메인의 인증 오류도 부담이 됩니다. 여기서 소개하는 TrekMail 요금은 Starter가 월 $3.50부터이며, 자체 SMTP를 사용하는 무료 Nano는 $0에 최대 10개 도메인과 5GB를 제공합니다. 현재 가격과 한도는 별도로 확인하세요. 유료 요금제에는 신용카드가 필요한 14일 무료 체험이 적용될 수 있으며, 안내된 Nano 조건에는 신용카드가 필요하지 않습니다.

인증 설정을 정비하면서 기존 메일도 옮겨야 한다면 TrekMail의 IMAP 마이그레이션 절차로 Gmail, Microsoft 365 또는 일반 IMAP의 메시지를 TrekMail 사서함으로 가져올 수 있습니다. 실제 결과는 원본 접근 권한, 인증 방식과 지원되는 데이터에 따라 달라집니다.

키 교체, 폐기와 장기 유지 관리

DKIM 키 생성기는 한 번 사용하고 끝나는 도구가 아닙니다. 키 교체를 계획하고 기존 선택자를 적절히 폐기하세요. 사고 영향을 줄이거나 문제 분석에 도움이 된다면 발신 시스템별로 선택자를 분리하세요.

다음 절차를 사용할 수 있습니다.

새 선택자에 사용할 2048비트 키를 생성합니다.
새 공개키를 DNS에 게시합니다.
발신 시스템이 새 선택자로 서명하도록 전환합니다.
새 메일에서 dkim=pass가 나타나는지 확인합니다.
대기 중이거나 지연된 메일이 처리될 때까지 기존 선택자를 유지합니다.
전환 기간이 끝나면 기존 공개키를 제거합니다.

개인키가 노출되었다면 교체하고 필요한 대응을 검토하세요. default를 계속 사용하는 것보다 선택자에 버전을 두는 편이 유리한 이유입니다.

DKIM 키 생성기만으로 잘못된 발송 관행을 해결할 수는 없습니다. 인증은 기본 조건이며 평판도 중요합니다. Google의 대량 발신자 지침은 스팸 신고 관리, SPF와 DKIM 인증 및 DMARC 사용을 요구합니다. DNS를 올바르게 유지하고 관련성 있는 메일의 발송량을 점진적으로 늘리며, 동의 없는 대량 발송을 피하는 것이 중요합니다. 이런 조치가 받은편지함 도착을 보장하지는 않습니다.

결론: 키 생성 이후의 검증까지 마무리하기

DKIM 키 생성기는 시작점입니다. 선택자, DNS 공개키와 발신 시스템의 개인키가 맞아야 하며, 실제 메일에서 dkim=pass와 적절한 DMARC 정렬을 확인해야 합니다.

2048비트 키, 버전이 있는 선택자와 올바른 TXT 레코드를 사용하고 실제 헤더로 검증하세요. 여러 제공업체와 도메인을 관리한다면 운영 흐름을 통합하는 것이 도움이 될 수 있습니다. TrekMail은 요금제에 따라 자체 도메인, IMAP 사서함, 공유 저장 공간, IMAP 마이그레이션과 DNS 및 인증 관리 기능을 제공합니다. 현재 기능과 사용자별 과금 여부 등 가격 조건을 확인하세요. trekmail.net에서 무료 옵션을 확인하거나 trekmail.net/pricing에서 요금제를 비교할 수 있습니다.