DKIM DNS 레코드 생성기
셀렉터 이름과 공개키(PEM 형식)를 입력하면 DKIM 서명용 DNS TXT 레코드(v=DKIM1; k=rsa; p=...)를 자동으로 생성합니다. 255자를 넘는 긴 공개키는 BIND 존 파일 형식으로 자동 분할됩니다.
팁
- opendkim-genkey나 OpenSSL의 openssl genrsa → openssl rsa -pubout으로 생성한 PEM 파일 내용을 그대로 붙여넣을 수 있습니다. 줄바꿈과 헤더 줄은 자동으로 제거됩니다.
- 테스트 모드(t=y)를 활성화하면 일부 수신 서버가 DKIM 검증 실패 시 바로 거부하지 않고 지켜볼 수 있습니다. 운영 환경으로 전환하기 전 검증 기간에 사용하면 안전합니다.
- 생성한 레코드를 DNS에 등록한 후에는 이 사이트의 메일 전송 진단 도구(SPF/DKIM/DMARC 진단)로 실제로 반영되었는지 확인하는 것을 권장합니다.
- 일반적인 키 길이는 1024비트·2048비트이며, 2048비트 키는 공개키 문자열이 길어져 255자를 넘어 여러 문자열로 분할되는 것이 보통입니다. 분할 자체는 오류가 아닙니다.
- 셀렉터 이름은 자유롭게 정할 수 있지만, 같은 도메인에서 여러 메일 서비스를 사용한다면 "google", "mailgun"처럼 서비스명을 포함하면 관리하기 쉬워집니다.
자주 묻는 질문
여담 ― 공개키 암호가 메일 "위장"을 막는 방식
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 레코드 하나임에도 대규모 메일 인프라에서 오래도록 널리 쓰이는 이유 중 하나입니다.