이메일 인증: SPF, DKIM 및 DMARC

핵심 SMTP 프로토콜은 1970년대에 설계되었으며 발신자 인증 기능이 기본 제공되지 않습니다. 모든 메일 서버는 어느 도메인에서든 이메일을 보낸 것처럼 주장할 수 있으며, 이를 이메일 스푸핑이라고 합니다. 공격자는 이를 악용하여 합법적인 조직(은행, CEO 또는 잘 알려진 공급업체)에서 보낸 것처럼 보이는 피싱 이메일을 발송합니다. 이 문제를 해결하기 위해 DNS 기반 이메일 인증 표준인 SPF, DKIM 및 DMARC가 개발되었습니다. 각 표준은 스푸핑 문제의 서로 다른 측면을 해결하며, 함께 배포할 때 가장 효과적으로 작동합니다.

SPF는 도메인을 대신하여 이메일을 보낼 수 있도록 승인된 메일 서버를 지정하는 DNS TXT 레코드입니다. 수신 메일 서버가 example.com에서 보낸 것이라고 주장하는 메시지를 받으면 example.com의 SPF 레코드를 조회하고 발신 서버의 IP 주소가 등록되어 있는지 확인합니다. IP가 승인되지 않은 경우 메시지를 스팸으로 표시하거나 거부할 수 있습니다. SPF는 사용자에게 표시되는 From 헤더가 아니라 envelope From 주소(SMTP MAIL FROM 명령)를 확인합니다.

SPF에는 두 가지 중요한 한계가 있습니다. 첫째, 전달하면 SPF가 깨집니다. 이메일이 전달되면 전달 서버의 IP가 원래 도메인의 SPF 레코드에 없으므로 정상적으로 전달된 메일에서도 SPF가 실패합니다. 둘째, SPF는 사용자에게 보이지 않는 envelope From만 인증하며 이메일 클라이언트에 표시되는 From 헤더는 인증하지 않습니다. 따라서 공격자는 SPF를 통과하는 envelope From을 사용하면서도 사용자에게 보이는 From 헤더를 스푸핑할 수 있습니다. 이것이 SPF만으로는 충분하지 않은 이유입니다. DKIM과 DMARC가 이러한 공백을 해결합니다.

DKIM은 발신 이메일에 암호화 서명을 추가합니다. 발신 메일 서버는 개인 키를 사용하여 특정 이메일 헤더와 메시지 본문에 서명하고 DKIM-Signature 헤더를 추가합니다. 공개 키는 선택기 하위 도메인의 DNS TXT 레코드로 게시됩니다. 수신 서버는 공개 키를 가져와 서명을 확인함으로써 이메일이 전송 중 변조되지 않았으며 개인 키에 액세스할 수 있는 서버에서 발신되었음을 확인합니다. SPF와 달리 DKIM 서명은 이메일 헤더에 포함되어 전달 과정에서도 유지됩니다.

DKIM은 선택기를 사용하여 하나의 도메인에 여러 공개 키를 동시에 사용할 수 있도록 합니다. 이는 여러 메일 서비스(Google Workspace와 마케팅 플랫폼)를 운영하거나 중단 없이 키를 교체할 때 유용합니다. 선택기 이름은 DKIM-Signature 헤더에 포함되므로 수신 서버는 조회해야 할 DNS 레코드를 알 수 있습니다. 조직은 매년 또는 키가 침해된 것으로 의심될 때 DKIM 키를 교체해야 합니다. 키 길이: 최소 2048비트 RSA 키를 권장하며, 1024비트 키는 더 이상 사용되지 않고 최신 컴퓨팅 환경에서는 해독될 수 있습니다.

DMARC(Domain-based Message Authentication, Reporting, and Conformance)는 SPF와 DKIM을 기반으로 다음 기능을 추가합니다. 정렬 확인(사용자에게 표시되는 From 헤더의 도메인이 SPF 또는 DKIM으로 인증된 도메인과 일치해야 함)과 메시지 인증에 실패했을 때 수신 서버가 취할 조치를 지정하는 정책입니다. DMARC 정책은 none(모니터링만 수행), quarantine(스팸 폴더로 전달), reject(전달하지 않음) 중 하나입니다. 또한 DMARC는 사용자를 대신하여 누가 메일을 보내는지 파악할 수 있도록 도메인 소유자에게 전송되는 집계 보고서 (RUA)와 포렌식 보고서 (RUF)를 지원합니다.

정렬은 header 스푸핑에 대한 DMARC의 강력한 방어력을 만들어 내는 요소입니다. SPF 정렬에서는 SMTP Envelope From의 도메인이 눈에 보이는 From header의 도메인과 일치해야 합니다. DKIM 정렬에서는 서명 도메인(DKIM-Signature의 d=)이 From header의 도메인과 일치해야 합니다. 엄격 모드에서는 도메인이 정확히 일치해야 합니다. 완화 모드에서는 하위 도메인도 허용됩니다. SPF 또는 DKIM 중 하나가 올바르게 정렬된 상태로 통과하면 이메일은 DMARC를 통과하며, 둘 다 통과할 필요는 없습니다. 이 조합은 SPF만 사용할 때 눈에 보이는 header 스푸핑에 남는 허점을 차단합니다.

Organization은 정상적인 이메일의 흐름을 방해하지 않도록 DMARC를 점진적으로 배포해야 합니다. Stage 1: 모든 메일 흐름에 SPF와 DKIM을 배포합니다. Stage 2: RUA Reporting이 포함된 p=none DMARC 레코드를 게시합니다. 2~4주 동안 보고서를 분석하여(도구: DMARC Analyzer, dmarcian) 정상적인 모든 발신 소스를 파악합니다. Stage 3: p=quarantine; pct=10으로 변경하고 pct를 점진적으로 100%까지 높입니다. Stage 4: 정상적인 모든 메일 흐름이 통과하면 p=reject로 변경합니다. 모든 메일 흐름을 파악하기 전에 서둘러 reject로 변경하면 정상적인 이메일까지 거부됩니다.

BIMI는 DMARC를 기반으로 구축된 새로운 표준입니다. 도메인의 DMARC policy가 quarantine 또는 reject인 경우 이메일 클라이언트(Gmail, Apple Mail)는 받은 편지함에서 발신자 이름 옆에 브랜드의 인증된 로고를 표시할 수 있습니다. BIMI를 사용하려면 상표 소유권을 확인하는 승인된 발급자의 Verified Mark Certificate (VMC)가 필요합니다. BIMI는 아직 Security+ 시험 범위에 포함되지 않았지만, 한눈에 인증된 발신자와 스푸핑된 발신자를 시각적으로 구분할 수 있도록 하는 이메일 인증의 방향을 보여 줍니다.

이 세 표준은 완전한 이메일 인증 시스템을 구성합니다. SPF는 발신 Server가 도메인 소유자의 승인을 받았는지 확인합니다. DKIM은 메시지 무결성과 발신 Organization이 개인 키를 보유하고 있는지를 확인합니다. DMARC는 두 표준을 눈에 보이는 From header와 연결하고, 실패 시 policy를 적용하며, Reporting을 제공합니다. 단일 표준만으로는 충분하지 않습니다. SPF만으로는 눈에 보이는 header 스푸핑을 방지할 수 없고, DKIM만으로는 실패한 메시지를 거부하도록 강제하지 않으며, SPF나 DKIM 없이 사용하는 DMARC는 확인할 대상이 없습니다. 도메인 스푸핑을 완전히 방어하려면 세 표준을 모두 함께 배포해야 합니다.

피싱과 BEC에 대응하는 실용적인 심층 방어 방법은 Organization 외부에서 시작된 모든 메시지에 External Email 경고 배너를 추가하는 것입니다. 일반적으로 SEG가 삽입하는 이 배너는 표시 이름이 동료나 임원처럼 보이더라도 이메일이 외부 발신자에게서 왔음을 직원에게 알립니다. 공격자가 유사 도메인이나 표시 이름 스푸핑을 사용하는 BEC 시도를 표시하는 데 배너가 특히 효과적입니다. 배너는 시각적으로 쉽게 구분되도록(색상이 있는 Header 또는 footer) 만들고, 의심스러운 메시지를 Reporting하는 방법을 안내해야 합니다.

이 lesson에서 다룬 CompTIA Security+ (SY0-701) 개념을 제대로 이해했는지 확인해 보십시오.

이 lesson에서는 다음을 학습했습니다. SPF는 DNS TXT 레코드를 사용하여 발신 IP를 승인하지만 눈에 보이는 header가 아니라 Envelope From만 확인합니다. DKIM은 메시지 무결성을 검증하고 전달 과정에서도 유지되는 암호화 서명을 추가합니다. DMARC는 정렬 확인과 적용 가능한 policy(none/quarantine/reject), 그리고 Reporting을 통해 SPF와 DKIM을 눈에 보이는 From header에 연결합니다. 다음으로는 보안 이메일 게이트웨이와 스팸 방지 제어를 살펴봅니다.