DKIM 키: 권장 길이, DNS 게시와 교체

DKIM 키는 수신 서버가 발신 인증을 검증하는 DNS 구성의 일부입니다. 약하거나 잘못되거나 오래된 키는 인증과 메일 처리에 문제를 줄 수 있습니다. Gmail은 이월부터 적용한 2024년 발신자 인증 요건을 안내하며, 십일월에 시작한 2025년 추가 적용도 설명합니다. 최신 지침을 확인하세요. DNS 기본 설정을 정리하고 있다면 업무 이메일 글부터 읽어 보세요.

핵심 권고는 지원되는 경우 RSA 2048비트 키를 쓰는 것입니다. DNS에 정확히 게시하고, 필요하면 하나의 TXT 레코드 안에서 여러 따옴표 문자열로 나누세요. 선택자로 정기 교체하고, 전환 뒤 이전 선택자는 이동 중인 메일에 충분한 시간을 주며 유지하세요. 오류를 없애는 보장이 아니라 신중한 운영 원칙입니다.

새 도메인을 설정한다면 내 도메인으로 이메일 만들기와 필수 DNS 레코드 목록을 함께 사용해 DKIM, SPF, DMARC를 구성하세요.

DKIM 키란?

여기서는 DKIM 서명 키 쌍의 공개키를 뜻합니다. 발신 시스템은 개인키로 메일에 서명하고 수신 서버는 DNS의 공개키로 서명 대상 내용과 서명 도메인의 권한을 검증합니다. 이것만으로 화면에 보이는 From 작성자의 신원을 증명하지는 않습니다.

DKIM은 DomainKeys Identified Mail의 약자입니다. 개인키는 발신 시스템에 보관하고 공개키는 s1._domainkey.example.com 같은 선택자 이름으로 DNS에 게시합니다.

수신 서버는 헤더의 DKIM 서명을 읽고 DNS에서 키를 가져와 검증합니다. 유효하게 검증되면 다음을 확인할 수 있습니다.

• 서명 대상 헤더와 서명된 본문 부분이 적용된 정규화 규칙에 따라 일치합니다.
• 서명자가 해당 도메인과 선택자의 개인키에 접근할 수 있었습니다.

받은편지함 도착을 보장하지는 않습니다. 다만 현대 메일 필터가 활용할 수 있는 암호학적 인증 신호를 제공합니다.

어떤 DKIM 키 길이를 사용해야 하나요?

RSA 2048비트는 2025년과 2026년의 일반적인 권장 선택입니다. 표준은 1024비트 RSA도 허용하지만, 2048비트는 더 큰 암호학적 여유를 제공하며 DNS 응답 크기와 호환성 부담이 늘어나는 4096비트보다 실용적인 경우가 많습니다. 실제 시스템 지원을 확인하세요.

기준은 RFC 8301에 있습니다. 서명자는 최소 1024비트 RSA를 사용해야 하며 최소 2048비트 사용이 권고됩니다. 이 권고가 운영상의 선택에 중요합니다.

오래된 메일 시스템을 인수했다면 키가 적절하다고 가정하지 마세요. 예전 관리 화면과 메일 시스템은 1024비트를 기본으로 생성하곤 했습니다. 현재 더 강한 키를 지원하는지 확인하세요.

Google 문서도 운영상 중요성을 보여 줍니다. Gmail은 대량 발신자에게 DKIM을 요구하며 FAQ는 인증 실패 시 속도 제한 가능성을 설명합니다. Google 이메일 발신자 지침 FAQ를 참고하세요.

2048비트 DKIM 키가 DNS에서 문제가 되는 이유

2048비트 키의 게시가 실패하는 이유 중 하나는 DNS TXT의 개별 문자열에 255옥텟 한도가 있기 때문입니다. 전체 공개키가 더 길어, 긴 값을 하나로 받는 관리 화면이 이를 거부하거나 자르거나 잘못 저장할 수 있습니다.

이 지점에서 자주 실수합니다. 암호 기술이 아니라 DNS 입력 화면의 문제인 경우가 많습니다.

p=에 들어가는 RSA 2048비트 공개키는 하나의 TXT 레코드 안에서 여러 따옴표 문자열로 나누어야 할 수 있습니다. 문자열은 DKIM 검증 애플리케이션이 이어 붙이며 DNS 리졸버가 단일 문자열로 바꾸는 것은 아닙니다. 잘못 게시하면 검증이 실패할 수 있습니다.

흔한 오류:

• DNS 화면이 255옥텟에서 값을 자릅니다.
• 키에 불필요한 공백이나 줄바꿈이 추가됩니다.
• 여러 문자열을 담은 하나의 TXT가 아니라 여러 TXT 레코드를 게시합니다.
• 길이를 줄이려다 v=DKIM1; k=rsa; p= 일부를 지웁니다.

이 경우 약한 키가 되는 것이 아니라 잘못된 키 게시가 됩니다.

2048비트 DKIM 키를 정확히 게시하기

선택자마다 하나의 TXT 레코드를 게시하고 DNS 문자열 단위로만 나누세요. 수신 애플리케이션이 문자열을 결합합니다. 문법을 유효하게 유지한 뒤 명령줄로 정확한 DNS 응답을 검증하세요.

존 파일 문법:

s1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
  "...rest_of_the_public_key_here...QAB"
)

많은 DNS 웹 화면은 같은 레코드를 한 줄로 요구합니다.

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." "...rest_of_the_public_key_here...QAB"

외부에서 검증하세요. 화면 미리 보기만 믿지 마세요.

dig txt s1._domainkey.example.com +short

완전한 TXT 응답이 보여야 합니다. 따옴표 문자열 두 개는 정상입니다. 누락된 부분, 이상한 이스케이프, 일부 출력만 보인다면 레코드와 조회 명령을 더 확인해야 합니다.

TrekMail에서는 TrekMail 관리형 SMTP 문서와 DNS 마법사를 참고할 수 있습니다. 유료 요금제는 관리형 SMTP와 도메인별 DKIM 레코드 정보를 안내합니다. Starter의 안내 시작 가격은 월 $3.50이며 신용카드가 필요한 14일 무료 체험이 소개됩니다. Nano는 자체 SMTP를 사용하는 무료 요금제로 안내됩니다. 최신 조건을 확인하세요.

예를 들어 2048비트 키를 만든 뒤 긴 TXT 값을 알리지 않고 자르는 등록업체에 붙여 넣을 수 있습니다. 메일은 여전히 발신 서버를 떠나지만 수신 서버는 DKIM 서명을 검증하지 못합니다. 그래서 외부 검증이 필요합니다.

메일 위험을 줄이며 DKIM 키 교체하기

새 선택자를 만들고 공개키를 게시한 뒤 서명을 전환하며 이전 선택자는 적절한 유예 기간 동안 유지합니다. 기존 위치에서 키를 무작정 덮어쓰지 마세요. 선택자 기반 교체는 지연되거나 재시도되는 메일의 검증 실패를 줄이는 데 도움이 됩니다.

신중한 절차:

1. 새 2048비트 DKIM 키 쌍을 만듭니다.
2. s2 같은 새 선택자를 지정합니다.
3. DNS에 s2._domainkey.example.com을 게시합니다.
4. 발신 서명 설정을 s2로 바꿉니다.
5. s1을 최소 며칠 동안 유지하되 대기열과 정책에 맞춰 조정합니다.
6. 기존 서명 메일에 충분한 시간이 지난 뒤 s1을 제거합니다.

실무 예시는 7일의 유예 기간입니다. 모든 지연, 재시도, DNS 캐시가 그 안에 정리된다는 보장은 없습니다. 키가 유출되었다면 유예보다 즉시 폐기가 더 중요할 수 있습니다.

서명, 전달, 캐시의 영향을 이해하지 못한다면 같은 선택자에서 기존 키를 바꾸지 마세요. 대부분의 팀은 모든 예외를 통제하지 못합니다. 선택자를 활용하세요.

여러 발신 시스템을 운영하면 각 선택자의 소유 시스템을 문서화하세요. CRM, 티켓 플랫폼, 웹 앱, 사서함 업체가 같은 도메인을 쓸 때 진단에 중요합니다.

언제 DKIM 키를 교체해야 하나요?

정해진 일정과 함께 개인키 노출, 업체 변경, 발신 플랫폼 이전 때도 교체하세요. 반년 주기는 현실적인 출발점이 될 수 있습니다. 고위험 환경은 더 자주 교체할 수 있으며, 예측 가능한 정책이 무계획한 변경보다 낫습니다.

운영 원칙은 개인키 유출 가능성이 있으면 사고 대응 절차에 따라 즉시 조치하는 것입니다. 문제가 없어도 정기 일정을 따르세요.

조기 교체 사유:

• 발신을 다른 업체로 옮겼습니다.
• 서명 권한을 가진 업체와 계약을 종료했습니다.
• 안전하지 않은 절차로 키를 내보냈습니다.
• 관리 주체가 불분명한 옛 공용 관리자 계정을 발견했습니다.

미루면 안 되는 이유:

• “시간이 나면 나중에 하죠.”
• “현재 키가 통과하니 괜찮아요.”
• “개인키가 어디 있는지 기억이 안 나요.”

많은 고객 도메인에서는 암호 기술보다 운영 문제입니다. 다중 도메인 이메일 호스팅이 중요해지는 지점입니다. 도메인 하나는 수동 작업이지만 쉰 개는 절차가 필요합니다.

DKIM에 Ed25519를 써야 하나요?

Ed25519는 RSA-2048보다 짧은 키로 긴 TXT 값 문제를 줄입니다. 고려할 점은 수신 서버의 호환성입니다. DKIM용으로 RFC 8463에 표준화되었지만 RSA-2048이 폭넓은 상호 운용을 위한 더 일반적인 기본 선택입니다.

운영상 이점은 크기입니다. Ed25519 공개키는 RSA보다 훨씬 작아 DNS 게시가 간단해질 수 있습니다.

단점은 지원 차이입니다. 일부 서버와 도구는 잘 처리하지만 다른 환경은 검증이 필요합니다. 폭넓은 호환성에는 RSA-2048이 일반적인 선택이나 보편적인 보장은 아닙니다. 이중 서명을 지원하고 전달 경로를 이해한다면 RSA와 함께 Ed25519를 테스트할 수 있습니다.

대부분의 운영자는 다음을 고려하세요.

• 기본 DKIM 키는 RSA-2048을 사용합니다.
• 수신 호환성을 이해하고 검증할 수 있을 때 Ed25519를 사용합니다.
• DNS 레코드가 짧다는 이유만으로 Ed25519만 쓰도록 바꾸지 않습니다.

기존 방식과 개선된 방식: 대규모 DKIM 관리

기존 방식은 TXT를 수동 편집하고 여러 등록업체 화면에 긴 키를 붙여 넣으며 교체를 잊지 않기를 바라는 것입니다. 개선된 방식은 반복 가능하고 필요에 따라 위임된 DNS 및 서명 관리로, 키 수명 주기를 플랫폼 운영에 포함합니다.

기존 방식:

• 도메인마다 다른 DNS 화면을 사용합니다.
• 키 교체가 누군가 무시하는 일정 알림에 달려 있습니다.
• 등록업체의 오타가 고객 인증을 깨뜨려도 전달률이 떨어질 때까지 모릅니다.

개선된 방식:

• 여러 도메인에 공통 절차를 사용합니다.
• 관리형 SMTP가 설정된 방식으로 서명합니다.
• 긴 TXT와 인증 불일치를 반복해서 진단하는 부담을 줄입니다.

TrekMail은 사용자별 과금이 아닌 정액형 다중 도메인 호스팅을 안내합니다. 소개된 기능은 공유 저장 공간, IMAP 사서함, 내장 IMAP 마이그레이션, catch-all, 전달, Nano의 BYO SMTP, 유료 요금제의 관리형 SMTP이며 제공 범위는 조건에 따릅니다. 전달 규칙을 쓰면 인증 결과의 차이가 문제가 될 수 있으므로 도메인 메일을 Gmail로 전달하기도 참고하세요.

팀과 대행사에 중요한 것은 DNS를 마법처럼 바꾸는 것이 아니라 반복 작업과 불확실성을 줄이는 것입니다. Starter의 안내 시작 가격은 월 $3.50이며 현재 결제 조건을 확인하세요.

DKIM 키에 대한 정리

일반적으로 RSA-2048을 선택하고 DNS에 정확히 게시하며 실제 조회로 검증하고 선택자를 이용해 정기 교체하세요. 1024비트를 쓴다면 업그레이드를 검토하세요. DNS 화면이 긴 값을 손상시키면 게시 방식을 고치거나 지원되는 플랫폼에 관리를 맡기세요.

DKIM만 따로 보지 마세요. SPF, DMARC, 발신 인프라도 올바르게 구성되어야 유용합니다. 전체 구성을 점검하려면 필수 DNS 레코드와 내 도메인으로 이메일 만들기를 읽어 보세요.