LETO

DKIM

DKIM은 보내는 메일에 도메인 이름으로 전자서명을 붙여, 받는 쪽이 발신 도메인과 내용의 변조 여부를 확인하게 하는 방식입니다. 공개키는 DNS에 둡니다.

작성

DKIM(DomainKeys Identified Mail)은 보내는 메일에 도메인 이름으로 전자서명을 붙여, 받는 쪽이 그 도메인에서 보낸 메일이 맞는지와 전달 중 내용이 바뀌지 않았는지를 확인하게 하는 방식입니다. 발신 서버가 개인키로 서명을 만들어 메일 헤더에 넣고, 받는 서버는 DNS에 공개된 공개키로 그 서명을 검증합니다. 접속한 서버의 IP만 보는 SPF와 달리 메일 자체에 증거가 실려 있어서, 중간에 전달을 거쳐도 서명은 유지됩니다.

셀렉터와 공개키 레코드

공개키는 도메인의 DNS에 둡니다. 위치는 셀렉터(selector)라는 이름표로 정해지며, 규칙은 아래와 같습니다.

<셀렉터>._domainkey.<도메인>

셀렉터가 s1 이고 도메인이 example.co.kr이면 s1._domainkey.example.co.kr 에 공개키를 둡니다. 메일 헤더에는 사용한 셀렉터와 서명 도메인이 함께 적혀 있어서, 받는 서버는 그 정보로 조회할 이름을 조립합니다. 셀렉터가 있기 때문에 한 도메인에 공개키를 여러 개 둘 수 있고, 발신 서비스별로 이름을 다르게 해서 나란히 운영할 수 있습니다.

레코드 값은 다음과 같은 모양입니다.

s1._domainkey.example.co.kr. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ..."

p= 뒤가 공개키 본문이고, 2048비트 키는 길어서 255자 조각으로 나뉩니다. 자세한 제한은 TXT 레코드 항목에 있습니다.

무엇에 서명하는가

서명 대상은 본문과 지정된 헤더들입니다. 헤더 목록은 서명 자체에 h= 로 기록되며, 보통 From, Subject, Date, To, Message-ID 등이 들어갑니다. From 헤더는 서명에 반드시 포함되어야 하고, 이 점이 DMARC가 DKIM 결과를 쓸 수 있는 근거가 됩니다.

서명에 포함된 헤더나 본문이 전달 중 한 글자라도 바뀌면 검증은 실패합니다. 메일링 리스트가 제목에 태그를 붙이거나 본문 끝에 안내문을 덧붙이는 경우가 대표적입니다. 반대로 서명에 넣지 않은 헤더는 바뀌어도 영향이 없습니다.

키 교체와 제공 방식

공개키를 어떤 레코드로 넣는지는 서비스마다 다릅니다.

제공 방식넣는 레코드특징
값을 직접 안내TXT키를 우리가 보관. 교체할 때 직접 값을 바꿔야 함
자기 이름을 안내CNAME키 관리와 교체를 서비스가 대신함. 한 번 넣으면 유지

CNAME으로 위임하는 방식이 관리 부담이 적지만, 그 서비스의 레코드가 사라지면 검증도 멈춥니다. 어느 쪽이든 안내받은 종류와 이름을 글자 그대로 넣고, 콘솔이 도메인 이름을 자동으로 덧붙이는지 확인해 _domainkey 가 두 번 들어가지 않게 해야 합니다.

설정 순서는 SPF, DKIM, DMARC 설정, 서비스 연결 전반은 외부 서비스 연결에서 다룹니다.

자주 묻는 질문

메일 서비스가 알려 준 셀렉터 이름 뒤에 _domainkey 를 붙인 이름에 넣습니다. 서비스가 TXT 값을 주면 TXT로, 자기 쪽 이름을 가리키는 CNAME을 주면 CNAME으로 넣습니다. 두 방식은 목적이 같으니 안내받은 종류를 그대로 따르면 됩니다.

네. DKIM은 셀렉터로 구분되므로 발신 서비스마다 서로 다른 이름에 각자의 공개키를 둘 수 있습니다. SPF처럼 하나로 합칠 필요가 없고, 서비스별로 따로 추가하는 것이 정상입니다.

DKIM은 발신 도메인과 내용이 바뀌지 않았음을 증명할 뿐, 그 메일이 원하는 메일인지는 판단하지 않습니다. 분류에는 발송 이력, 수신자 반응, 본문 내용이 함께 반영되므로 서명만으로 받은메일함이 보장되지는 않습니다.

관련 가이드