⋯1번째 줄 근처
+추가: ## 개요
+추가: DKIM(DomainKeys Identified Mail, 도메인키 식별 메일)은 이메일 메시지에 도메인 이름과 연결된 디지털 서명을 첨부하여, 발신 도메인의 소유자가 해당 메시지를 승인했음을 수신자가 검증할 수 있게 하는 이메일 인증 기술이다. 이메일 스푸핑(spoofing)을 탐지하고 피싱 및 스팸 메일에서 악용되는 위조 발신자 주소 문제를 완화하기 위해 설계되었다[1][2][3]. DKIM은 인터넷 표준(Internet Standard)으로, RFC 6376(2011년 9월)에 정의되었으며 이후 RFC 8301, RFC 8463, RFC 8553, RFC 8616 등으로 갱신되었다[2][3].
+추가: DKIM의 핵심 아이디어는 메시지 전송 과정에서 도메인 수준의 책임을 암호학적으로 증명하는 것이다. 발신 측 메일 서버(또는 서명 대행자)는 개인 키로 메시지의 헤더와 본문 일부를 서명하여 `DKIM-Signature:` 헤더 필드를 추가하고, 수신 측은 DNS에 게시된 해당 도메인의 공개 키를 조회해 서명을 검증한다. 유효한 서명은 서명 시점 이후 서명된 헤더 필드와 본문(첨부 파일 포함 가능)이 변경되지 않았음을 보장한다[2][3]. 일반적으로 DKIM 서명은 최종 사용자에게 노출되지 않으며, 메일 전송 인프라(MTA, 제출 에이전트 등)가 자동으로 첨부하고 검증한다[2][3].
+추가:
+추가: DKIM은 SMTP 엔벨로프(RFC 5321)가 아닌 RFC 5322 메시지(헤더와 본문) 위에서 동작하므로, 기본적인 릴레이 과정을 거쳐 여러 메시지 전송 에이전트(MTA)를 통과해도 서명이 유지된다[3]. 이는 기존 이메일 인프라와의 호환성을 높이는 설계 선택이다[3].
+추가:
+추가: ## 기능과 사용법 개요
+추가: ### 무엇을 만드는가: 도메인 수준의 메시지 서명 및 검증 체계
+추가: DKIM은 발신 도메인이 자사에서 발송된 메시지에 대해 암호학적 책임을 지게 하고, 수신 측이 이를 검증할 수 있게 하는 프레임워크를 제공한다. 이를 통해 다음과 같은 목적을 달성한다[2][3].
+추가:
+추가: - 발신 도메인 인증: 수신자가 "이 메시지가 실제로 example.com 도메인의 승인을 받았는가"를 확인 가능
+추가: - 내용 무결성 보장: 서명된 헤더 필드와 본문(선택적으로 길이 제한 가능)이 전송 중 변조되지 않았음을 보장
+추가: - 책임 주체 명시: 서명 도메인(d= 태그)과 선택자(s= 태그)로 누가 서명했는지 식별
+추가:
+추가: ### 대상 사용자
+추가: - 메일 서비스 제공자(ESP), 기업 메일 시스템 운영자, ISP, 호스팅 업체 등 대량 메일 발송 인프라를 운영하는 조직
+추가: - 자사 도메인을 사칭한 피싱·스팸으로부터 브랜드 평판을 보호하려는 도메인 소유자
+추가: - 수신 측 스팸 필터·평판 시스템 운영자: DKIM 검증 결과를 평판 데이터베이스와 연계하여 필터링 정확도 향상
+추가: - 보안 감사·포렌식 분석가: DKIM 서명의 부인방지(non-repudiation) 특성을 활용해 유출 메일의 진위 판별
+추가:
+추가: ### 서명 과정(Signing)
+추가: 서명 주체(작성자, 제출 에이전트, 사이트, 중간 전송자, 또는 이들을 대행하는 독립 서비스)는 하나 이상의 `DKIM-Signature:` 헤더 필드를 메시지에 삽입한다[3]. 사양은 서명할 헤더 필드를 서명자가 선택할 수 있게 하되, `From:` 필드는 반드시 포함하도록 강제한다[3]. 서명 헤더는 태그=값 쌍의 리스트로 구성되며, 주요 태그는 다음과 같다[3].
+추가:
+추가: - `b`: 헤더와 본문 내용을 암호화한 실제 디지털 서명(Base64 인코딩)
+추가: - `bh`: 본문 해시(선택적으로 본문 앞쪽 `l` 옥텟만 해시)
+추가: - `d`: 서명 도메인(공개 키가 게시된 DNS 도메인)
+추가: - `s`: 선택자(selector) — 동일 도메인 아래 여러 키를 운영하기 위한 식별자
+추가: - `h`: 서명에 포함된 헤더 필드 이름 목록(순서대로 해시)
+추가: - `c`: 헤더/본문 정규화 알고리즘(simple 또는 relaxed)
+추가: - `a`: 서명 알고리즘(예: rsa-sha256, ed25519)
+추가: - `t`: 서명 생성 시각(Unix 타임스탬프)
+추가: - `x`: 서명 만료 시각(선택)
+추가: - `z`: 서명 시점에 존재했던 헤더 필드 전체 목록(이름+값, 선택)
+추가: - `i`: AUID(Agent or User Identifier, 선택) — 서명 도메인 또는 그 하위 도메인 형태의 이메일 주소로, 더 세밀한 책임 범위를 표현
+추가:
+추가: 서명 생성 절차는 크게 두 단계 해시로 이루어진다[3].
+추가:
+추가: 1. 본문 해시: 메시지 본문의 처음부터 순서대로 해시하며, `l` 태그로 길이 제한 가능(0이면 본문 전체).
+추가: 2. 헤더 해시: `h` 태그에 나열된 헤더 필드를 아래에서 위로(Received 필드가 쌓이는 순서와 동일) 순회하며 해시. 존재하지 않는 필드는 빈 문자열로 처리되어 나중에 해당 필드가 추가되면 서명이 깨진다. 생성 중인 `DKIM-Signature:` 필드 자체(`bh`는 계산값, `b`는 빈 문자열)도 암묵적으로 두 번째 해시에 포함되나, 그 이름은 `h`에 나타나지 않아야 한다(나타나면 기존 다른 서명을 가리킴).
+추가:
+추가: 두 해시 결과는 지정된 정규화 알고리즘(`c` 태그)에 따라 정규화된 뒤, 서명자의 개인 키로 암호화되고 Base64로 인코딩되어 `b` 태그 값이 된다[3].
+추가:
+추가: ### 검증 과정(Verification)
+추가: 수신 측 SMTP 서버(또는 검증 모듈)는 `d` 태그(도메인)와 `s` 태그(선택자)를 이용해 DNS TXT 레코드 조회를 수행한다[3]. 조회 대상은 `selector._domainkey.domain` 형태이며, 국제화 도메인 이름(IDN)인 경우 IDNA 인코딩 후 조회한다[3]. 응답 레코드에는 공개 키(`p` 태그), 키 타입(`k` 태그, 기본 rsa), 서비스 타입(`t` 태그, 예: `s`는 서명 전용), 플래그 등이 태그=값 형태로 들어 있다[3]. CNAME 레코드로 다른 TXT 레코드를 가리키게 할 수도 있어, 타 조직이 대행 발송하는 경우에 유용하다[3].
+추가:
+추가: 검증기는 공개 키로 `b` 태그 서명을 복호화해 해시 값을 얻고, 수신한 메시지의 동일 헤더/본문으로 계산한 해시와 비교한다. 일치하면 해당 도메인의 개인 키로 서명되었음과 전송 중 변조되지 않았음이 암호학적으로 증명된다[3]. 검증 실패 시 메시지를 즉시 거부하지는 않으며, 실패 사유를 하위/상위 프로세스에 전달한다(예: `Authentication-Results:` 헤더 추가(RFC 7001), FBL 메시지 발송 등)[3].
+추가:
+추가: ### 키 관리와 선택자
+추가: 선택자(`s` 태그)는 동일 도메인에서 여러 키 쌍을 동시에 운영하거나 키 순환(key rotation)을 용이하게 한다. 도메인 운영자는 `selector._domainkey.example.com` 형태의 여러 DNS 레코드를 게시할 수 있으며, 서명 시 사용할 키를 선택자로 지정한다. 키 순환은 키 유출 시 영향 범위를 줄이기 위해 권장되며, 만료된 공개 키를 DNS에서 제거하면 과거 서명 검증이 불가능해지지만, `x` 태그(만료 시각)로 공식 만료를 표현할 수도 있다(검증기가 무시할 수 있음)[3].
+추가:
+추가: ## 사용 사례·작품
+추가: ### 대량 메일 발송자의 도메인 평판 보호
+추가: 기업·서비스 제공자가 자사 도메인으로 발송하는 모든 메일에 DKIM 서명을 적용하면, 수신 측 평판 시스템이 "이 도메인의 서명된 메일" 스트림을 식별해 화이트리스트·평판 점수에 반영할 수 있다. 이로써 자사 도메인을 사칭한 피싱 메일이 수신함에 도달할 확률을 낮추고, 자사 발송 메일의 전달률(deliverability)을 높인다[3].
+추가:
+추가: ### 스팸 필터링 보조
+추가: DKIM 자체는 스팸을 직접 차단하지 않지만, 광범위한 DKIM 배포로 스패머가 발신 도메인을 위조하기 어려워지면, 평판 기반 필터링, 도메인 기반 블랙리스트/화이트리스트, 머신러닝 분류기 등 기존 필터링 기법의 효과가 상승한다[3]. 알려진 양성 도메인의 서명 메일은 필터링을 생략하고 의심스러운 메일에 자원을 집중하는 운영도 가능하다[3].
+추가:
+추가: ### 피싱 방지
+추가: 피싱 표적이 되는 주요 도메인(금융, 전자상거래, 이메일 제공자 등)이 모든 정식 메일에 DKIM 서명을 적용하고, [[일반:DMARC|DMARC]] 정책으로 `p=reject` 또는 `p=quarantine`을 선언하면, 서명 없는 위조 메일을 수신 측이 거부·격리하도록 유도할 수 있다. 예: eBay, PayPal 등이 DMARC로 전량 인증 정책을 게시해 Gmail 등 대형 수신자가 미인증 메일을 거부하게 함[3].
+추가:
+추가: ### 포렌식·부인방지 활용
+추가: DKIM 본문 서명은 발송자가 나중에 "내가 보낸 게 아니다"라고 부인하기 어렵게 만든다. 위키리크스(WikiLeaks) 같은 언론 기관이 유출 이메일의 진위를 입증하는 데 DKIM 서명을 활용한 사례가 있다[3]. 다만 키 순환과 공개 키 삭제로 과거 메일 검증이 어려워지는 실무적 한계가 있다[3].
+추가:
+추가: ### 선택적 공개·영지식 증명 응용
+추가: 최근 연구·구현에서는 DKIM 서명된 메일의 일부만 공개하면서도 서명의 유효성을 제3자가 검증할 수 있게 하는 영지식 증명(zero-knowledge proof) 기법이 제안된다. 정규식·마스킹으로 민감 정보를 가린 채로 헤더/본문의 서명된 부분이 원본과 일치함을 증명할 수 있어, 익명 게시판에서 소속 인증, 발신자 주장 검증 시 수신자 익명성 유지 등에 응용 가능하다[3].
+추가:
+추가: ## 평가
+추가: ### 장점
+추가: - 기존 이메일 인프라(SMTP, DNS, RFC 5322)와 완전 호환. DKIM을 지원하지 않는 시스템에도 투명하게 동작[3].
+추가: - 도메인 수준 인증으로 평판 시스템·화이트리스트 효과 극대화[3].
+추가: - 피싱·스팸 완화에 실질적 기여. DMARC와 결합 시 정책 집행력 강화[3].
+추가: - 암호학적 무결성·부인방지 제공. 포렌식·감사 용도로 유용[3].
+추가: - 스패머에게 계산 비용 부과(메시지당 암호 연산). 해시캐시(hashcash)와 유사하게 대량 스팸 발송 비용 증가[3].
+추가: - 키 순환, 선택자, 만료 태그, CNAME 위임 등 운영 유연성 제공[3].
+추가: - S/MIME, PGP, DNSSEC 등 타 보안 표준과 충돌 없음[3].
+추가:
+추가: ### 한계·약점
+추가: - 엔벨로프 수신자(RCPT TO) 및 반환 경로(Return-Path)는 서명 대상이 아님. 오배송·릴레이 공격 표면 잔존[3].
+추가: - 메시지 재전송(replay) 공격 가능: 유효한 서명 메일을 대량 포워딩해 악용. 메시지별 고유 키, DNS 조회 추적, 만료 태그 등으로 완화 시도[3].
+추가: - 임의 포워딩(arbitrary forwarding): 평판 좋은 도메인 사용자가 악성 메일을 서명받아 파일로 추출한 뒤 봇넷 등으로 대량 재전송 가능. `l` 태그(본문 길이 제한)로 변조 여지 증가. 발송자는 사용자 차단 가능하나 이미 서명된 메일 확산은 막기 어려움. 만료 태그로 수명 제한 권장[3].
+추가: - ADSP(RFC 5617)는 2013년 11월 구식(Historic) 강등. 대신 DMARC 사용 권장[3].
+추가: - 키 순환·공개 키 삭제로 과거 메일 검증 곤란. 아카이브·키 복구 수단 별도 필요[3].
+추가: - 매튜 그린(Matthew D. Green) 등 일부 보안 연구자는 부인방지 특성이 원치 않는 기능이라 비판. 만료 키 공개로 위조 서명 가능하게 해 무력화 제안[3].
+추가: - 계산 오버헤드: 발송 측 메시지당 암호 연산 필요. 대량 발송 인프라에 CPU 비용 추가[3].
+추가:
+추가: ### 전반적 평가
+추가: DKIM은 이메일 인증의 핵심 기반 기술로 자리 잡았으며, [[일반:전송자 정책 프레임워크|SPF]], [[일반:DMARC|DMARC]]와 함께 현대 이메일 보안 아키텍처의 3대 축을 이룬다. 단독으로는 발신자 위조 방지에 한계가 있으나, DMARC 정책 계층과 결합했을 때 실질적인 피싱·스팸 완화 효과를 낸다. 배포 초기에는 키 관리·정규화·릴레이 호환성 등 운영 난이도가 높았으나, 현재 주요 메일 서비스·MTA·클라우드 플랫폼이 기본 지원하면서 진입 장벽이 크게 낮아졌다. 다만 재전송 공격, 키 순환에 따른 과거 검증 곤란, 부인방지 특성의 양면성 등은 여전히 운영·정책 차원의 보완이 필요한 영역이다.
+추가:
+추가: 이 문서는 GGWiki AI가 공개 자료(아래 출처)를 조사해 새로 쓴 초안입니다. 틀린 내용은 편집하거나 이의 제기로 알려 주세요.
