DKIM DNS 레코드 생성기
셀렉터 이름과 공개키(PEM 형식)를 입력하면 DKIM 서명용 DNS TXT 레코드(v=DKIM1; k=rsa; p=...)를 자동으로 생성합니다. 255자를 넘는 긴 공개키는 BIND 존 파일 형식으로 자동 분할됩니다.
DKIM용 DNS 레코드를 짜 내기
셀렉터 이름과 PEM 형식의 공개 키를 넣으면, DKIM 서명을 검증하는 데 쓰는 DNS TXT 레코드(`v=DKIM1; k=rsa; p=...`)를 짜 냅니다. 놓을 자리는 `셀렉터._domainkey.도메인`입니다.
**여기서 누구나 부딪히는 것이, DNS의 TXT는 문자열 하나가 255자까지라는 제약입니다.** RSA 2048비트의 공개 키는 Base64로 약 390자여서 **그대로는 한 문자열에 담기지 않습니다.** 존 파일에서는 괄호로 감싸 여러 문자열로 나누어 적고, **받는 쪽이 그것들을 이어 하나의 값으로 읽습니다.** 이 도구는 그 나눔까지 대신 해 줍니다. **또 하나 결코 틀려서는 안 될 것이, DNS에 두는 것은 공개 키라는 점입니다.** 비밀 키는 서명하는 서버에만 두고 밖으로 내보내서는 안 됩니다.
사용하는 방법
- 도메인과 셀렉터 이름을 넣습니다 셀렉터는 마음대로 지을 수 있는 이름이며, 키를 갈 때마다 새 이름을 씁니다.
- 공개 키를 PEM 형식으로 붙여 넣습니다 **`-----BEGIN PUBLIC KEY-----`로 시작하는 쪽이며 비밀 키가 아닙니다.**
- 만들어진 레코드를 확인합니다 **255자를 넘으면 괄호로 나눈 꼴로 나옵니다.**
- DNS에 등록합니다 `셀렉터._domainkey.도메인`에 TXT 레코드로 둡니다.
더 잘 활용하기 위한 팁
- opendkim-genkey나 OpenSSL의 openssl genrsa → openssl rsa -pubout으로 생성한 PEM 파일 내용을 그대로 붙여넣을 수 있습니다. 줄바꿈과 헤더 줄은 자동으로 제거됩니다.
- 테스트 모드(t=y)를 활성화하면 일부 수신 서버가 DKIM 검증 실패 시 바로 거부하지 않고 지켜볼 수 있습니다. 운영 환경으로 전환하기 전 검증 기간에 사용하면 안전합니다.
- 생성한 레코드를 DNS에 등록한 후에는 이 사이트의 메일 전송 진단 도구(SPF/DKIM/DMARC 진단)로 실제로 반영되었는지 확인하는 것을 권장합니다.
- 일반적인 키 길이는 1024비트·2048비트이며, 2048비트 키는 공개키 문자열이 길어져 255자를 넘어 여러 문자열로 분할되는 것이 보통입니다. 분할 자체는 오류가 아닙니다.
- 셀렉터 이름은 자유롭게 정할 수 있지만, 같은 도메인에서 여러 메일 서비스를 사용한다면 "google", "mailgun"처럼 서비스명을 포함하면 관리하기 쉬워집니다.
이럴 때 쓸 수 있습니다
DKIM을 처음 들일 때
**키를 만든 뒤 DNS에 어떻게 적어야 할지를 알 수 있습니다.**
키를 교체할 때
**새 셀렉터로 레코드를 더하고, 갈아탄 뒤 옛것을 지웁니다.**
나눔의 서식을 확인할 때
긴 키를 어떻게 나눌지는 손으로 적으면 틀리기 쉬운 대목입니다.
발송 서비스의 안내를 검증할 때
**바깥 서비스가 건넨 레코드가 바른 꼴인지 확인할 수 있습니다.**
DKIM 용어
- 셀렉터
- 키를 가려내는 이름입니다. **`selector._domainkey.example.com`의 머리에 해당하며 키마다 다른 이름을 붙입니다.**
- 공개 키
- **DNS에 두는 쪽의 키입니다.** 받는 쪽이 이것으로 서명을 검증합니다.
- 비밀 키
- 서명을 만드는 데 쓰는 키입니다. **보내는 서버에만 두고 결코 공개해서는 안 됩니다.**
- 255자의 제약
- **TXT 레코드의 문자열 하나에 대한 상한입니다.** 넘으면 여러 문자열로 나누어 적습니다.
- v=DKIM1
- 레코드의 판을 알리는 태그로, 맨 앞에 둡니다.
- k=rsa
- 키의 종류입니다. RSA 말고도 훨씬 짧은 Ed25519를 쓰는 방식이 있습니다.
자주 묻는 질문
여담 ― 공개키 암호가 메일 "위장"을 막는 방식
DKIM(DomainKeys Identified Mail)은 2004년 Yahoo!와 Cisco가 각각 개발하던 기술(DomainKeys와 Identified Internet Mail)을 통합하는 형태로 표준화되었습니다. 핵심은 공개키 암호입니다. 발신 측은 메일 헤더와 본문 일부에서 계산한 해시값을 비밀키로 암호화해 DKIM-Signature 헤더에 첨부합니다. 수신 측은 DNS에 공개된 공개키로 이 서명을 검증하며, 키 쌍이 올바르게 대응한다면 "발송 후 내용이 변조되지 않았음"을 수학적으로 확인할 수 있습니다.
SPF가 발신 IP 주소라는 네트워크 수준의 정당성을 검증하는 것과 달리, DKIM은 메일 내용 자체에 전자서명을 적용한다는 점에서 본질적으로 다릅니다. 그래서 메일이 정상적인 중계 서버를 여러 번 거쳐 전달되더라도(SPF는 이런 종류의 전달에 취약한 것으로 알려져 있습니다) 본문이 변경되지 않는 한 DKIM 서명은 유효성을 유지합니다. 이러한 특성 때문에 메일링 리스트처럼 전달을 거치는 배송 경로에서는 DKIM이 SPF보다 신뢰도 높은 인증 수단으로 평가받습니다.
셀렉터라는 구조도 실무에서 중요합니다. 하나의 도메인이 여러 메일 서비스(자체 서버·Gmail·SendGrid 등)를 함께 사용할 때, 각 서비스에 별도의 키 쌍과 셀렉터 이름을 할당하면 서비스별로 독립적으로 키를 폐기·갱신할 수 있습니다. 키 하나가 유출되어도 다른 셀렉터에는 영향을 주지 않는다는 운영상의 유연함이, DKIM이 단순한 DNS 레코드 하나임에도 대규모 메일 인프라에서 오래도록 널리 쓰이는 이유 중 하나입니다.