SPF는 수신 서버에 연결한 클라이언트 IP가 SMTP HELO 또는 MAIL FROM 도메인의 정책상 허용된 발신자인지 검사합니다. 화면에 보이는 RFC5322.From 주소를 그 자체로 SPF가 인증하는 것은 아닙니다.
DKIM은 서명 도메인 d=의 공개키를 이용해 서명과 지정된 헤더·본문의 무결성을 검증합니다. 두 검사 모두 메시지를 작성한 사람의 신원이나 안전성을 단독 보증하지 않습니다. 사례는 새로 만든 교육용 예시입니다.
화면 주소, SMTP 봉투, 서명 도메인은 다를 수 있습니다
메일 클라이언트에는 From: billing@shop.example이 보이지만, SMTP 전송 과정의 MAIL FROM은 bounce@mailer.example일 수 있습니다. 또 DKIM 서명에는 d=mailer.example이 적힐 수 있습니다. 세 주소가 서로 다르다고 곧바로 스푸핑이라고 판단할 수도, 같아야 정상이라고 단정할 수도 없습니다. SPF와 DKIM은 각기 다른 단계와 식별자를 확인하기 때문입니다. SPF는 연결 IP와 SMTP의 HELO 또는 MAIL FROM identity를 확인하고, DKIM은 서명 도메인과 서명에 포함된 메시지 내용을 검증합니다.
| 관찰 항목 | 가상 값 | SPF가 보는가 | DKIM이 보는가 | 해석 한계 |
|---|---|---|---|---|
| 화면 From | billing@shop.example | 그 주소만으로 직접 인증하지 않음 | DKIM 서명에는 반드시 포함되어야 함 | 표시 주소가 실제 발신자를 증명하지 않음 |
| SMTP MAIL FROM | bounce@mailer.example | 이 도메인의 SPF 정책과 연결 IP를 검사 | DKIM 서명 도메인과 별도 | 봉투 발신이 허용돼도 표시 From 정렬은 별도 |
| 수신 서버 연결 IP | 192.0.2.44 | SPF 정책이 허용하는지 검사 | DKIM의 공개키 서명 확인 대상이 아님 | 정책이 허용한 전송 서버라는 뜻 |
| DKIM d= 및 h= | d=mailer.example; h=from:subject | SPF와 무관 | From과 선택된 다른 헤더 및 본문 해시의 서명을 검증 | From 서명은 필수지만 서명 도메인의 메시지 부분 검증이지 사람 증명은 아님 |
각 인증 통과가 실제로 말해 주는 범위를 적습니다
수신 시스템이 192.0.2.44에서 연결을 받았다고 합시다. SPF 검사에서 이 IP가 mailer.example의 정책상 MAIL FROM 발신에 허용되어 있으면 해당 SPF 검사가 통과할 수 있습니다. 이 결과는 ‘이 연결 IP가 이 봉투 도메인의 정책으로 허용됐다’는 증거입니다. From 표시의 shop.example까지 같은 도메인이라고 증명하는 결과는 아닙니다. HELO identity 확인도 별도 상황에서 사용될 수 있으므로 SPF를 막연히 ‘발신 주소 검사’로 외우지 말고 어떤 identity를 검사했는지 살펴야 합니다.
DKIM에서는 수신자가 DNS에서 d=mailer.example과 selector에 해당하는 공개키를 찾아 서명을 검증합니다. 서명의 h= 목록은 어떤 헤더 필드를 대상으로 삼았는지, b=는 메시지의 선택된 헤더와 본문 해시를 포함한 서명을 나타냅니다. RFC 6376은 From 헤더를 반드시 h= 목록에 포함하도록 요구합니다. 수신자가 확인한 h=에 From이 없으면 그 DKIM-Signature를 무시하고 PERMFAIL로 처리해야 합니다. 그러므로 From을 서명자가 임의로 빼도 된다고 가르치면 안 됩니다. 검증 성공은 서명된 내용이 검증에 맞고 해당 도메인 키를 가진 주체가 서명했음을 뒷받침합니다. 그렇다고 실제 사람이 billing 계정을 소유한다거나 메시지 내용이 안전하다는 뜻은 아닙니다. 서명 도메인과 표시 From이 다르더라도 DKIM 서명 자체는 유효할 수 있습니다.
헤더를 읽을 때는 네 항목을 별도로 표시합니다
- 사람에게 보이는 RFC5322.From 도메인을 Author Domain 후보로 기록합니다.
- Received-SPF 또는 Authentication-Results에서 검사한 SPF client IP와 MAIL FROM/HELO identity를 확인합니다.
- DKIM-Signature의 d=, s=, h= 항목을 보고 서명 도메인과 선택된 콘텐츠 범위를 확인합니다.
- 각 결과가 통과한 식별자만 결론에 적고 표시 주소·사람·안전성을 추가로 증명했다고 확대하지 않습니다.
SPF와 DKIM의 결과가 서로 달라도 표준상 가능한 경우가 있습니다. 예컨대 발송 플랫폼이 MAIL FROM 전송을 허용받았지만 DKIM 키가 잘못됐거나, DKIM은 통과했지만 SPF에서 현재 연결 IP를 허용하지 않았을 수 있습니다. 결과는 메시지 원본의 여러 헤더와 수신 측 인증 결과를 함께 보고 확인합니다. 이메일 인증을 이해하는 목표는 한 줄의 pass/fail만 외우는 게 아니라, 어떤 도메인과 데이터에 대한 어떤 검사가 통과했는지 설명하는 것입니다.
SPF·DKIM 통과를 ‘안전한 사람’으로 번역하지 않습니다
첫째 흔한 오해는 SPF가 화면 From 주소를 직접 확인한다고 보는 것입니다. RFC7208에서 SPF는 SMTP HELO 또는 MAIL FROM의 도메인과 수신 연결 IP를 이용합니다. 둘째 오해는 DKIM 통과가 메일 내용의 진실성이나 첨부파일 안전성을 보증한다는 것입니다. DKIM은 서명된 부분의 무결성과 서명 도메인 키를 검증할 뿐, 그 도메인의 실제 담당자가 보냈는지 또는 악성 의도가 없는지는 판단하지 않습니다. 이 두 기술의 정렬 정책은 DMARC가 다루는 별도 주제입니다.
검사 대상과 남는 질문을 함께 회상합니다
회상 연습: From은 billing@shop.example이고, MAIL FROM은 bounce@mailer.example이며 SPF는 pass, DKIM은 d=mailer.example로 pass입니다. 어떤 사실이 확인됐고 어떤 사실은 아직 확인되지 않았나요? 답은 연결 IP가 mailer.example의 SPF 허용 정책에 맞고 해당 d= 도메인의 DKIM 서명이 검증됐다는 것입니다. 표시 From과의 정렬 여부, 실제 사람의 신원, 내용의 안전성은 이것만으로 확정되지 않습니다. 사례와 질문은 교육용으로 직접 작성했으며 실제 시험이나 상품 수록 문항을 뜻하지 않습니다. 집중 180제의 실제 구성은 상품 안내에서 확인하세요.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
From은 billing@shop.example, MAIL FROM은 bounce@mailer.example이고 SPF와 d=mailer.example DKIM이 모두 통과했다. 각 pass가 확인하는 사실, DKIM 서명에 반드시 포함할 헤더, 아직 단정할 수 없는 사실을 구분하세요.
정답과 해설 확인
SPF pass는 수신 연결 IP가 MAIL FROM 도메인 정책상 허용됐다는 뜻입니다. DKIM pass는 d= 도메인의 키로 서명된 지정 메시지 부분이 검증됐다는 뜻이며, RFC 6376에 따라 From 헤더는 h= 서명 목록에 포함되어야 합니다. 표시 From과의 DMARC 정렬, 사람의 신원, 메시지 안전성은 단정할 수 없습니다.RFC 6376 §5.4는 From을 반드시 서명하도록 하고 §6.1.1은 From이 h=에 없으면 검증자가 서명 필드를 무시하고 PERMFAIL을 반환하도록 합니다. SPF의 검사 identity와 DKIM의 필수 서명 헤더를 한 항목으로 섞지 않습니다.