DKIM 레코드 생성기: TXT와 CNAME 설정

Gmail이나 Google Postmaster Tools에서 인증 실패가 표시되어 DKIM 레코드 생성기를 찾고 있다면 기본 설정부터 점검하세요. 자체 도메인 이메일 만들기 가이드에서 MX, SPF, DKIM, DMARC와 메일 전달에 영향을 주는 DNS 오류를 함께 설명합니다.

많은 웹 도구가 충분히 설명하지 않는 부분이 있습니다. DKIM은 DNS에 게시하는 공개키와 메시지에 서명하는 시스템에 보관하는 개인키로 구성됩니다. 웹사이트가 둘 다 생성한다면 해당 서비스가 개인키에 접근했을 가능성을 검토해야 합니다. 검증 가능한 브라우저 내 생성인지 확인하세요. 이 키는 도메인을 대신해 서명할 수 있는 권한을 제공하지만, 표시되는 발신자의 신원을 직접 증명하지는 않습니다.

이 글에서는 2025-2026 환경에서 DKIM 레코드 생성기를 사용하는 적절한 방법을 설명합니다. 자체 메일 서버라면 OpenSSL로 로컬에서 키를 만들고, TrekMail, Amazon SES, SendGrid, Mailgun 또는 Google Workspace를 사용한다면 실제 발신 제공업체의 DKIM 안내를 따르세요.

DKIM 레코드 생성기란?

DKIM 레코드 생성기는 DomainKeys Identified Mail에 필요한 DNS 데이터를 제공합니다. TXT 레코드용 RSA 키 쌍을 만들거나, 제공업체가 다른 위치에 게시한 DKIM 공개키를 가리키는 CNAME 레코드를 안내할 수 있습니다. 모든 제공업체가 CNAME을 사용하는 것은 아닙니다.

DKIM은 개인키로 발신 메일에 서명합니다. 수신 서버는 DNS에서 대응하는 공개키를 가져와 서명을 검증합니다. 이를 통해 서명 도메인을 대신한 서명과 정규화 규칙에 따른 서명된 데이터의 무결성을 확인합니다.

RFC 8301에 따르면 RSA 서명에서는 rsa-sha256을 사용하고 RSA 키를 최소 1024비트로 설정해야 하며, 2048비트 이상이 권장됩니다. 따라서 적절한 DKIM 레코드 생성기는 RSA 2048을 기본으로 고려해야 하며, 1024를 목표로 삼아서는 안 됩니다.

출처가 불분명한 웹 생성기의 위험

DKIM 키를 만드는 웹사이트를 사용하려면 개인키가 어디서 생성되고 누가 접근할 수 있는지 확인해야 합니다. 검증 가능한 클라이언트 측 생성은 서비스에 키가 노출되는 위험을 줄일 수 있지만, 알 수 없는 도구를 신뢰할 근거는 아닙니다. 유출된 키는 도메인 서명 악용으로 이어질 수 있습니다.

DKIM은 단순한 DNS 문자열 작업이 아니라 도메인을 대신하는 암호학적 서명입니다. 개인키는 서명에 필요한 시스템에서 접근을 통제하며 보관해야 합니다. 외부 사이트가 키를 생성하거나 로그에 기록하거나 저장했다면 나중에 해당 도메인을 대신해 서명할 가능성이 있습니다.

공개키는 DNS에, 개인키는 서명 서버에 둡니다. 웹 양식이 둘 다 제공한다면 개인키가 어디서 만들어졌고 서비스가 접근했는지 확인하세요.

모든 DKIM 레코드 생성기에 적용할 핵심 질문은 개인키의 생성 위치와 접근 주체입니다. 출처가 불명확한 웹사이트에서 만들었다는 사실만으로 운영 환경에서 사용할 키를 신뢰해서는 안 됩니다.

OpenSSL로 로컬에서 키 만들기

자신의 컴퓨터나 서명 서버에서 OpenSSL을 사용하면 웹서비스에 개인키가 노출될 위험을 줄일 수 있습니다. 호스트 보안, 파일 권한과 접근을 적절히 관리한다면 유용한 DKIM 레코드 생성기입니다. 로컬 생성 자체가 안전을 보장하지는 않습니다.

Postfix, Exim, Exchange, OpenDKIM 등 자체 메일 환경에 적합한 방법입니다. 키를 로컬에서 생성하고 개인키를 서명 호스트에 설치한 뒤 공개키만 DNS에 게시하세요.

2048비트 RSA 키 쌍을 생성합니다.

openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key

public.key 파일은 다음과 같은 형태입니다. 아래의 축약된 예시 문자열은 실제로 사용할 수 있는 키가 아닙니다.

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr...
-----END PUBLIC KEY-----

DNS에 게시할 형태로 정리합니다.

BEGIN PUBLIC KEY와 END PUBLIC KEY 줄을 제거합니다.
모든 줄바꿈을 제거합니다.
DKIM 태그를 추가합니다.

수동 TXT 레코드는 일반적으로 다음과 같습니다. 예시 문자열을 전체 공개키로 바꿔 사용하세요.

default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."

키 문자열만으로는 충분하지 않습니다. 적절한 DKIM 레코드 생성기는 보통 v=DKIM1을 명시합니다. 이 태그는 선택 사항이지만 넣는 경우 반드시 맨 앞에 와야 합니다. p=는 필수 태그입니다. s=email이나 t=s 같은 선택 태그도 있지만 기본 구성에서는 대부분 필요하지 않습니다.

DNS 문자열당 255옥텟 제한

DNS TXT 레코드는 개별 문자열에 길이 제한이 있으므로 DKIM 레코드 생성기의 출력이 부적절한 입력란에서 처리되지 않을 수 있습니다. 2048비트 RSA 공개키는 길어서 같은 TXT 레코드 안에서 따옴표로 묶인 여러 문자열로 나눠야 할 수 있습니다.

오래된 DNS 관리 화면은 레코드를 거부하거나 자르거나 키 일부만 저장할 수 있습니다. 이 경우 permerror, 잘못된 키 형식 오류 또는 선택자가 있는데도 DKIM 검증이 실패하는 결과가 나타날 수 있습니다.

DNS 관리 화면이 긴 값을 자동으로 처리하지 못한다면 같은 TXT 레코드 안에서 여러 문자열로 나누세요.

default._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArFirstPart"
  "SecondPartOfTheSamePublicKey"
)

DKIM 검증기나 애플리케이션은 문자열을 공백 없이 연결해 하나의 논리적 값으로 해석합니다. 각 부분을 별도 TXT 레코드로 만드는 것이 아닙니다. 적절한 DKIM 레코드 생성기는 분할이 필요한 경우와 DNS 관리 화면의 처리 방식을 설명합니다.

발신 제공업체에 키 관리 맡기기

많은 기업에는 직접 키를 관리하는 것보다 발신 제공업체의 DKIM 레코드 생성기를 사용하는 편이 실용적입니다. 일부 업체는 CNAME을, 다른 업체는 TXT를 제공합니다. 개인키를 보관하고 키 교체를 지원할 수 있지만 자동화와 DNS 변경 조건은 서비스마다 다릅니다.

TrekMail, Amazon SES, Google Workspace, SendGrid 또는 Mailgun으로 보낸다면 실제 발신 경로의 안내를 따르세요. CNAME 위임에서는 지정된 선택자 CNAME을 게시하고 업체가 대상 호스트 이름에 DKIM 공개키를 게시합니다. TXT 구성이라면 제공된 TXT 값을 사용합니다.

항목	직접 관리	제공업체 관리
키 생성	RSA 키를 직접 만들고 보관	제공업체가 키 관리
DNS 레코드	긴 TXT 값	제공업체 안내에 따른 CNAME 또는 TXT
키 교체	수동 작업이므로 일정 관리 필요	제공업체의 지원 방식에 따름
오류 가능성	문법 오류, 값 잘림, 오래된 키	DNS 오류, 누락된 레코드 또는 발신 설정
적합한 환경	자체 운영 MTA	호스팅 이메일 및 SMTP 플랫폼

TrekMail에서는 도메인 설정과 인증 검사를 하나의 흐름으로 관리할 수 있습니다. 직접 관리해야 하는 범위는 발신 경로에 따라 다릅니다. 도메인을 추가할 때는 도메인 추가의 현재 DNS 안내를 따르세요.

TrekMail 설정은 발송 방식에 따라 달라집니다. Nano는 발신용으로 자체 SMTP를 사용합니다. 여기서 설명하는 가격 구성에서는 유료 요금제에 관리형 SMTP가 포함되며 Starter는 월 $3.50부터 시작합니다. 유료 요금제에는 신용카드가 필요한 14일 무료 체험이 적용될 수 있습니다. 설명된 Nano 조건에는 체험 기간이나 카드 요구가 없습니다. 현재 가격과 조건은 별도로 확인하세요.

TrekMail 사용자의 적절한 DKIM 레코드 생성기는 발신 경로에 따라 결정됩니다.

TrekMail이 관리형 SMTP로 서명한다면 대시보드에 표시된 DNS 레코드를 사용하세요.
자체 SMTP를 사용한다면 중계 제공업체에서 도메인 서명을 설정하고 확인한 뒤 해당 업체의 DKIM 레코드를 게시하세요.
업체가 선택자 CNAME을 제공한다면 그대로 사용하세요. 블로그에서 TXT만 설명한다고 TXT로 바꾸지 마세요.

전달, 별칭과 실제 사서함 중에서 선택한다면 도메인 이메일 별칭과 사서함 비교 및 이메일 별칭 전달을 읽어 보세요. 이 선택은 실제 발신 시스템과 필요한 DKIM 설정에 영향을 줍니다.

선택자를 게시하는 위치

DKIM 레코드 생성기의 레코드는 도메인 루트에 게시하지 않습니다. DKIM 키는 default._domainkey, google._domainkey 또는 tm1._domainkey 같은 선택자 호스트 이름에서 조회합니다.

DNS 관리 화면마다 입력 방식이 다릅니다. 일부는 호스트 레이블만, 다른 곳은 전체 호스트 이름을 요구합니다. 영역 이름을 자동으로 붙이는 화면에 전체 도메인을 입력하면 default._domainkey.example.com.example.com 같은 중복 이름이 생깁니다. 이 위치의 레코드는 원래 선택자 조회에 사용되지 않습니다.

자주 사용하는 형태는 다음과 같습니다.

default._domainkey
selector1._domainkey
tm1._domainkey

여러 고객 도메인을 관리하면 동일한 오류가 반복되기 쉽습니다. 일회성 수정 대신 반복 가능하고 검증할 수 있는 DNS 절차를 마련하세요. 다중 도메인 이메일 호스팅 가이드에서 많은 도메인의 운영 방법을 설명합니다.

DKIM 레코드 생성 결과 검증하기

대시보드의 정상 표시만 믿지 말고 명령줄에서 DNS 응답도 확인하세요. DKIM 레코드 생성기의 결과는 dig로 선택자를 직접 조회해 점검할 수 있습니다.

먼저 직접 조회합니다.

dig txt default._domainkey.example.com +short

TXT 레코드가 게시되어 있다면 DKIM 값 또는 따옴표로 묶인 여러 문자열이 표시됩니다. DNS 변경 후 공개 리졸버에서도 확인할 수 있습니다. 다만 해당 응답이 모든 DNS 캐시의 갱신을 의미하지는 않습니다.

dig txt default._domainkey.example.com @8.8.8.8 +short

다음 항목을 확인하세요.

응답 없음: 잘못된 선택자나 호스트 이름, DNS 캐시 또는 다른 조회 문제일 수 있습니다. 전체 응답을 확인하세요.
일부만 보이는 응답: 표시 방식이나 TXT 분할 때문일 수 있으므로 전체 값을 비교한 뒤 잘림 여부를 판단하세요.
같은 선택자에 충돌하는 DKIM TXT 레코드가 여러 개 있음: 수정한 뒤 다시 테스트하세요.
DNS는 정상인데 메일 인증 실패: 헤더를 검사하고 발신 시스템이 대응하는 선택자와 개인키를 사용하는지 확인하세요.

Google의 대량 발신자 지침은 SPF, DKIM과 DMARC를 요구합니다. DKIM 오류는 적용 조건에 따라 전송 속도 제한이나 거부에 영향을 줄 수 있습니다. 다만 정렬된 SPF가 통과하면 DKIM 실패가 곧 DMARC 실패를 의미하지는 않습니다. 현재 적용 내용은 Google의 이메일 발신자 지침 FAQ를 참고하세요.

TrekMail 사용자도 발신 경로를 확인해야 합니다. IMAP 및 SMTP 설정 문서는 Nano의 자체 SMTP와 유료 요금제의 TrekMail SMTP 사용 방식을 설명합니다. DNS가 정상인데 스팸함으로 분류된다면 메일이 스팸함으로 들어가는 문제를 점검하세요.

결론: 메일 구조에 맞는 DKIM 구성 선택

적절한 DKIM 레코드 생성기는 메일 구조에 맞아야 합니다. 자체 서버는 일반적으로 로컬 키 생성이 적합합니다. 호스팅 플랫폼은 제공업체의 TXT 또는 CNAME 안내를 따르고 키 교체 방식도 확인하세요.

자체 MTA라면 OpenSSL을 로컬에서 사용하고 개인키를 운영용 인증 정보처럼 보호하세요. TrekMail, SES 또는 다른 발신 제공업체를 사용한다면 해당 업체가 제공하는 레코드를 따르세요. 경고 표시를 없애려고 알 수 없는 웹 양식의 키를 붙여 넣지 마세요.

명확한 검증 절차를 갖춘 통합 관리 방식은 도메인별 수동 DNS 작업과 오류 가능성을 줄이는 데 도움이 될 수 있습니다. 여러 브랜드나 고객 도메인을 관리하거나 마이그레이션을 진행 중이라면 더욱 중요합니다. 환경을 구성하는 단계라면 먼저 도메인 이메일을 Gmail로 전달하기를 읽고, TrekMail 요금제를 비교하세요.

DKIM 레코드 생성기는 이해할 수 없는 블랙박스가 아니라 메일 환경에서 통제 가능한 절차여야 합니다.