DKIM
DomainKeys Identified Mail
DKIM(DomainKeys Identified Mail)은 발송 측이 선택한 헤더와 본문에 암호학적 서명을 넣고, 수신 측이 서명 도메인의 DNS 공개키로 이를 검증하는 방식입니다. RFC 6376은 서명 도메인이 메시지에 일정한 책임을 연결하고 공개키 조회로 그 주장을 검증한다고 설명합니다.
AI 보조 조사·작성 후 원문과 대조한 설명입니다. 사례·계산은 별도 출처 표기가 없는 한 이해를 위한 가상 예시이며 실제 고객 성과가 아닙니다.
DKIM은 무엇을 확인하나요?
DKIM(DomainKeys Identified Mail)은 발송 측이 선택한 헤더와 본문에 암호학적 서명을 넣고, 수신 측이 서명 도메인의 DNS 공개키로 이를 검증하는 방식입니다. RFC 6376은 서명 도메인이 메시지에 일정한 책임을 연결하고 공개키 조회로 그 주장을 검증한다고 설명합니다. IETF RFC 6376 DKIM은 메시지가 전송 중 서명 범위에서 변조되지 않았는지 확인하는 데 도움을 줍니다.
키와 선택자는 어떻게 관리하나요?
DKIM-Signature의 `d=`는 서명 도메인, `s=`는 DNS 공개키를 찾는 선택자입니다. 서비스별 선택자를 나누면 키 회전과 장애 격리가 쉬워집니다. 개인키는 발송 시스템에서 보호하고 공개키만 DNS에 둡니다. 키 길이와 회전 절차는 공급자 지원 범위를 확인합니다. Google은 개인 Gmail 발송에 1024비트 이상을 요구하고 가능하면 2048비트를 권고합니다. Google DKIM 요구사항
서명 통과와 실패는 어떻게 생기나요?
마케팅 도구가 `d=news.example.com`, `s=oct2026`으로 서명하면 수신 서버는 `oct2026._domainkey.news.example.com`의 공개키를 조회합니다. 전송 중 서명된 제목이나 본문이 변경되지 않고 키가 맞으면 통과합니다. 중간 시스템이 푸터를 추가하거나 본문을 바꾸면 본문 해시가 달라져 실패할 수 있습니다. 실패가 곧 악성이라는 뜻은 아니지만 DMARC 통과 경로가 DKIM뿐이었다면 정책 처리에 영향을 줄 수 있습니다.
DKIM 통과가 의미하지 않는 것은 무엇인가요?
DKIM은 서명 도메인과 메시지의 책임·무결성 신호이지 표시 발신자가 누구인지, 내용이 사실인지, 스팸이 아닌지를 보증하지 않습니다. 공격자도 자신이 소유한 도메인으로 정상 서명할 수 있습니다. 오래된 선택자의 공개키를 방치하거나 같은 개인키를 여러 시스템에서 공유하면 운영 위험이 커집니다. SPF와 함께 설정하고 DMARC 보고서로 실제 정렬과 실패 원인을 관찰합니다.
자주 묻는 질문
- DKIM과 SPF의 가장 큰 차이는 무엇인가요?
- SPF는 발송 IP의 도메인 사용 권한을 확인하고, DKIM은 메시지에 붙은 서명과 DNS 공개키로 서명 도메인과 무결성을 확인합니다.
- 메일 본문이 조금만 바뀌어도 DKIM이 실패하나요?
- 서명과 정규화 방식, 변경된 부분에 따라 다릅니다. 중간 시스템이 서명 범위의 내용을 바꾸면 실패할 수 있습니다.
- DKIM 키는 한 번 만들면 계속 써도 되나요?
- 장기 고정은 바람직하지 않습니다. 서비스별 선택자, 키 보관, 정기 회전과 폐기 절차를 마련하는 편이 안전합니다.
출처와 확인 범위
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures · IETF · 확인 2026-10-27
DKIM은 서명 도메인과 메시지를 연결하고 DNS의 공개키로 암호학적 서명을 검증합니다.
확인 범위: 서명 통과는 서명 도메인의 책임 연결과 무결성 신호이며 발신 내용의 선의나 받은편지함 도착을 보장하지 않습니다.
- Email sender guidelines · Google · 확인 2026-10-27
Gmail 발신자 지침은 동의 기반 구독, 인증, 쉬운 수신 거부, 스팸률과 도메인·IP 평판 모니터링을 함께 요구합니다.
확인 범위: 개인 Gmail 수신 환경 중심의 사업자 지침이며 한국 법률 준수나 받은편지함 도착을 보장하지 않습니다.