SPF, DKIM, DMARC
SPF · DKIM · DMARC메시지가 정말 그 도메인에서 왔는지를 가리는 세 가지 장치. SPF는 보내는 서버를 인가하고, DKIM은 메시지에 암호 서명을 하며, DMARC는 둘을 공개된 정책에 묶습니다.
SPF(Sender Policy Framework)는 어떤 서버가 그 도메인의 메일을 보낼 수 있는지 나열한 DNS 레코드로, 받는 서버는 접속해 온 주소를 그 목록과 대조합니다. DKIM(DomainKeys Identified Mail)은 한 걸음 더 나아가, 보내는 도메인이 본문과 선택한 헤더들을 개인 키로 서명하고 DKIM-Signature 헤더를 붙입니다. 누구든 DNS에 공개된 공개 키로 검증할 수 있죠. DMARC는 그 위에 서서, 이 검사들이 실패했을 때 무엇을 할지 수신자에게 알려 주고, 인증된 도메인이 눈에 보이는 From: 주소와 일치할 것을 요구합니다.
보관된 메일함에서 이 모든 것의 실질적인 흔적은 Authentication-Results 헤더입니다. 받는 서버가 배달 시점에 기록하는 것으로, 그때 내려진 판정 — pass, fail, none — 을 남깁니다. 바로 그 점이 핵심입니다. 메시지가 도착했을 때 알려져 있던 사실을 붙잡아 두니까요.
DKIM 서명은 원리상 몇 년 뒤에도 다시 검증할 수 있지만, 도메인이 대응하는 공개 키를 계속 게시하는 동안에만 그렇습니다. 그리고 운영자들은 그 키를 일상적으로 교체합니다. 따라서 더 이상 검증되지 않는 서명은 위조의 증거가 아닙니다. 대개는 그저 만료된 키일 뿐이죠. 보관된 메일을 무언가의 증거로 내놓을 때면 늘 중요한 뉘앙스입니다.
관련 용어
이메일 메시지 시작 부분의 구조화된 메타데이터 블록으로, From, To, Subject, Date 필드와 메시지가 어떻게 작성되고 라우팅되며 인코딩되었는지를 설명하는 수많은 기술적 필드를 포함합니다.
메시지가 지나갈 때마다 각 메일 서버가 덧붙이는 헤더. 아래에서 위로 읽으면 Received 줄들이 그 메시지가 실제로 지나온 경로를 되살려 줍니다.
전자 기록 — 무엇보다 이메일 — 을 찾아내고, 보전하고, 검토하고, 제출하는 법적 절차. 대부분의 사람이 언젠가 메일함을 특정 메시지 묶음으로 줄여야 하는 이유가 바로 이것입니다.