DKIM은 이메일 메시지에 서명하기 위해 공개/개인 키 암호화를 활용하는 이메일 인증 표준입니다. DKIM 레코드는 수신 이메일이 실제로 DKIM 키가 연결된 도메인에서 발송되었는지 확인하는 데 도움이 됩니다. 따라서 DKIM 레코드를 통해 전송 중에 이메일이 조작되었는지 여부와 이메일을 열어도 안전한지 여부를 확인할 수 있습니다.
DKIM은 DNS에 TXT(텍스트) 또는 CNAME(정규 이름) DNS 레코드로 존재합니다. TXT를 사용해야 하는지 CNAME을 사용해야 하는지는 아래에서 살펴보는 여러 가지 요인에 따라 달라집니다.
주요 내용
- DKIM은 위조된 이메일 발신자 주소를 식별하기 위해 고안된 이메일 인증 표준입니다.
- DKIM 레코드는 항상 TXT 레코드입니다. 그러나 일부 공급업체는 CNAME 위임을 사용하여 도메인이 서버에서 호스팅되는 TXT 레코드를 가리키도록 합니다.
- 이러한 각 방법에는 고유한 장점과 한계가 있습니다.
- 제어와 보안, 간편함과 편리함 중 무엇을 우선시하는지에 따라 둘 중 하나를 선택해야 할지 결정할 수 있습니다.
- 일반적인 함정으로는 잘못된 선택기 형식, 동일한 선택기에 대한 TXT/CNAME 혼용, 키 회전 중 TTL 지연 등이 있습니다.
DKIM 레코드 게시 이해
DKIM 레코드의 구성 요소를 살펴보겠습니다.
DKIM 기록에는 무엇이 있나요?
DKIM 레코드에는 선택기, 공개 키 및 알고리즘이 포함됩니다. 다음을 수행할 수 있습니다. DKIM 레코드 생성 를 생성할 수 있습니다.
DKIM 선택기
DKIM 선택기를 사용하면 수신자의 이메일 서버가 발신자의 공개 키를 찾아서 확인할 수 있습니다. 여러 개의 공개 키 중에서 인증에 사용할 DKIM 공개 키를 식별하는 데 도움이 됩니다. 서명된 각 이메일의 DKIM-서명 헤더에서 찾을 수 있습니다. "s=" 매개변수입니다.
공개 키
DKIM 공개 키는 도메인의 DNS에 TXT 레코드(또는 공급업체의 키를 가리키는 CNAME)로 게시됩니다. 수신 서버에서 발신자의 개인 키를 사용하여 만든 메시지의 해시를 확인하여 이메일 무결성과 신뢰성을 보장하는 데 사용됩니다.
이메일을 보내는 조직에서 제공한 키는 TXT 레코드로 DNS 영역에 바로 삽입됩니다. 또는 제공업체의 DNS에 있는 키를 가리키는 CNAME이 될 수도 있습니다.
알고리즘
해싱에 사용되는 알고리즘은 다음과 같이 정의됩니다. a= 태그(DNS 레코드가 아님)에 정의됩니다. 지원되는 DKIM 서명 알고리즘은 다음과 같습니다:
- rsa-sha256(권장 및 가장 일반적)
- rsa-sha1(보안이 약해져 더 이상 사용되지 않음)
DNS 위치 및 구문
DKIM 레코드는 일반적으로 세미콜론으로 구분되는 여러 개의 태그 값 쌍을 포함하는 TXT 레코드입니다:
v=DKIM1; k=rsa; p=PUBLIC_KEY
- v=DKIM1은 DKIM 버전을 지정합니다.
- k=rsa, 여기서 "k"는 키 유형을 나타냅니다(현재 지원되는 키 유형은 RSA가 유일합니다).
- 서명을 확인하는 데 사용되는 실제 공개 키입니다.
다음은 예시입니다: selector._domainkey.example.com
여기서 "selector"는 DKIM 키의 고유 식별자이고 example.com은 도메인입니다.
방법 1 - TXT 레코드로서의 DKIM
이 방법을 사용하면 DKIM 공개 키가 위치 selector._domainkey.example.com에 DNS TXT 레코드로 게시됩니다. 발신 메일은 개인 키로 서명되고 수신 서버는 DNS의 공개 키를 사용하여 서명을 확인합니다.
장점
- 완벽한 제어: DKIM을 TXT 레코드로 사용하면 DKIM 키와 DNS를 완벽하게 제어할 수 있습니다.
- 타사 종속성 없음: 이 방법을 사용하면 타사 제공업체에 의존할 필요가 없습니다. 데이터의 소유자는 회원님이므로 개인정보 보호 및 보안이 강화됩니다.
단점
- 수동 키 회전: 사용자가 직접 키를 업데이트해야 하므로 기술 전문가가 아닌 사용자에게는 까다로울 수 있습니다.
- 잘못된 구성 위험 증가: DIY 설정은 이메일 보안을 약화시킬 수 있는 오류의 가능성을 높입니다. 저희의 무료 DKIM 검사기 를 사용하여 실수를 방지하세요.
방법 2 - CNAME 위임을 통한 DKIM
이 방법은 첫 번째 방법과 매우 다르게 작동합니다. DKIM 공개 키를 직접 게시하는 대신 이메일 서비스 제공업체(ESP)의 DKIM 레코드를 가리키는 selector._domainkey.example.com에 CNAME 레코드를 만듭니다.
수신 서버가 DKIM 키를 조회하면 DNS 쿼리는 CNAME을 따라 ESP의 DNS로 이동합니다. 여기에서 공개 키가 포함된 실제 TXT 레코드가 호스팅됩니다. SendGrid, Mailchimp, Amazon SES와 같은 주요 제공업체가 이를 사용합니다.
장점
- 자동 키 회전: 이 방법은 수동 업데이트가 필요하지 않으며 키 회전이 자동으로 수행됩니다.
- 간편한 설정: 이 방법은 초보자나 여러 도메인을 관리하는 경우에 더 적합합니다. 번거로운 작업 없이 원활하게 지속적으로 관리할 수 있습니다.
단점
- 가시성 저하: 설정이 쉬워지는 대신 DKIM 키와 DNS에 대한 제어 및 인사이트가 제한됩니다.
- CNAME 제한: 깊게 중첩되거나 체인으로 연결된 CNAME은 DNS 확인 제한에 도달하거나 성능 문제를 일으킬 수 있습니다. 일부 공급업체는 특정 형식을 요구하거나 CNAME 위임을 지원하지 않으므로 이를 따르지 않을 경우 DKIM이 손상될 수 있습니다.
TXT와 CNAME - 어떤 것을 사용해야 하나요?
TXT에서 DKIM을 사용할지 CNAME을 사용할지 결정할 때 따라야 할 몇 가지 일반적인 조언은 다음과 같습니다.
TXT 사용 시...
- 이메일을 직접 호스팅하고 기술적인 전문 지식이 있는 경우
- DKIM 및 DNS에 대한 완전한 제어를 원합니다.
- 키를 직접 관리하고 회전하는 것을 선호합니다.
참고: 경우에 따라 제공업체에서 직접 TXT 입력을 요구할 수 있으므로 이 방법을 선택 사항으로 설정할 수 없습니다.
CNAME 사용 시...
- Mailchimp, SES 또는 SendGrid와 같은 ESP를 사용합니다.
- 자동화된 DKIM 관리를 선호합니다.
- 수동 설정을 위한 시간이나 기술 전문 지식이 부족합니다.
동일한 선택기에 TXT/CNAME 혼합하기
DNS는 동일한 도메인 이름(즉, 동일한 DKIM 선택기)에 TXT 레코드와 CNAME 레코드를 모두 보유하는 것을 허용하지 않습니다. 선택기당 하나의 레코드 유형(TXT 또는 CNAME)만 사용합니다. 수동 제어의 경우 TXT를 선택하고 ESP에 위임하는 경우 CNAME을 선택합니다.
실제 사례
TXT와 CNAME에서 DKIM의 예를 찾고 계신다면 여기에 각각에 대한 간결한 설명이 나와 있습니다.
DKIM TXT 예제
google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG..."
이 레코드는 지정된 선택기 및 도메인 아래의 DNS에 DKIM 공개 키를 직접 저장합니다.
DKIM CNAME 예제
em1234._domainkey.example.com. IN CNAME em1234.example.dkim.emailsvc.com.
이 레코드는 호스팅된 DKIM 레코드를 가리키는 방식으로 타사 제공업체에 DKIM 키 조회를 위임합니다.
요약
TXT와 CNAME에서 DKIM을 선택하는 것은 어려운 일처럼 보일 수 있습니다. 두 방법 모두 잘 작동하고 둘 다 일반적으로 사용되므로 결정은 대부분 사용자에게 달려 있습니다. 선택은 편의성보다 완전하고 직접적인 제어를 우선시하는지, 아니면 그 반대인지에 따라 달라질 수 있습니다.
최종 선택이 무엇이든, 항상 현재 DKIM 설정이 규정을 준수하는지 감사하세요. 이를 통해 보안 공백을 방지하고 커뮤니케이션에 대한 최고 수준의 안전을 보장할 수 있습니다!
- TXT와 CNAME의 DKIM - 주요 차이점 및 모범 사례 - 2025년 5월 14일
- 수신자 주소가 거부되었습니다: 액세스 거부됨 - 원인 및 수정 (SMTP 550 5.7.1) - 5월 9, 2025
- 내 모든 이메일이 스팸으로 전환되는 경우 - 해결 방법은 다음과 같습니다. - 2025년 5월 1일