Email은 기본적으로 "보낸 사람"을 신뢰하기 어려운 구조를 가지고 있음

메일 화면에는 From: cookie01@example.com 처럼 보낸 사람이 표시되지만, 이 값은 메일 본문 헤더에 포함되는 문자열에 가까움
즉, SMTP 자체만 놓고 보면 사용자가 보는 발신자 주소가 실제 그 도메인의 권한있는 발신자인지 보장하기 어려움

그래서 Email 보안에서는 단순히 메일이 도착했는지가 아니라, 다음 질문을 확인해야 함

이 메일은 정말 해당 도메인을 사용할 권한이 있는 발신 경로에서 온 것인가?

이 질문에 대응하기 위한 대표적인 인증 기술이 SPF, DKIM, DMARC임

SPF는 발송 서버의 권한을 확인하고 DKIM은 메일에 포함된 서명을 검증하며, DMRAC는 사용자가 보는 From 도메인을 기준으로 SPF/DKIM 결과를 정책과 연결함

---

이 글에서 다룰 내용

이 글에서는 Email 인증 구조를 SPF, DKIM, DMARC 중심으로 정리함

단순히 각 기술의 정의를 나열하는 것이 아닌, Email 전달 구조에서 왜 인증이 필요한지, 각 인증 기술이 무엇을 검증하는지, 그리고 인증 결과를 보안 관점에서 어떻게 해석해야 하는지 설명함

주요 내용은 다음과 같음:

• Email에서 발신자 위조가 가능한 이유
• SMTP Envelope와 Header From의 차이
• SPF의 발송 서버 권한 검증 구조
• DKIM의 서명 기반 검증 구조
• DMARC의 From 도메인 기준 정책 검증 구조
• SPF, DKIM, DMARC의 관계와 한계
• 인증 성공이 곧 안전한 메일을 의미하지 않는 이유

학습 목표

이 글을 읽고 나면 다음 내용을 이해할 수 있음

• Email 인증이 필요한 이유를 설명할 수 있음
• SFP, DKIM, DMARC가 각각 무엇을 검증하는지 구분할 수 있음
• SPF와 DKIM이 단독으로는 부족한 이유를 이해할 수 있음
• DMARC Alignment의 의미를 이해할 수 있음
• 메일 인증 결과를 보안 탐지 결과와 구분해서 해석할 수 있음

---

⁎ Email 인증의 기본 개념

⁑ Email 인증이 필요한 이유

Email은 오래된 인터넷 프로토콜 구조 위에서 동작함.

SMTP는 기본적으로 메일을 전달하기 위한 프로토콜이지, 강력한 신원 검증을 전제로 설계된 보안 프로토콜은 아님
메일 서버는 상대 서버와 SMTP 세션을 맺고, 발신자와 수신자 정보를 주고받은 뒤, 메일 데이터를 전달함

문제는 이 과정에서 "보낸 사람 주소" 처럼 보이는 값이 여러 계층에 나뉘어 존재한다는 점임

예를 들어 하나의 메일에는 다음과 같은 발시자 관련 값이 존재할 수 있음

SMTP MAIL FROM: bounce@example.com
Header From: security@example.com
DKIM d=example.com
Return-Path:  bounce@example.com

사용자가 메일 클라이언트에서 주로 보는 값은 Header From임
반면 SMTP 서버가 전송 과정에서 사용하는 값은 MAIL FROM, HELO/EHLO, Return-Path 같은 값임

이 값들이 항상 같다고 볼 수 없음.

공격자는 사용자가 보는 Header From 을 신뢰할 만한 조직처럼 꾸밀 수 있기 때문에 수신 측에서는 단순히 From 문자열만 보는 것이 아니라, DNS에 게시된 인증 정보를 기반으로 해당 도메인이 허용한 발송 경로인지 확인해야 함

$Email \ 인증은 \ 이 \ 문제를 \ 해결하기 \ 위한 \ 구조$

⁑ Email에서 말하는 “인증”의 의미

Email에서 말하는 인증은

특정 도메인을 사용한 메일이 그 도메인 소유자가 허용한 방식으로 발송되었는지 확인하는 과정

즉, Email 인증은 도메인 사용 권한을 검증하는 구조

여기서 중요한 기준은 "도메인" SPF, DKIM, DMARC는 모두 개인 사용자 한 명의 실제 신원을 증명하는 기술이 아니라, 특정 도메인이 메일 발송에 어떻게 사용되었는지를 확인하는 기술임

따라서 다음 사항을 구분할 수 있어야 함

• 인증 성공 = 해당 도메인을 사용할 권한이 있는 경로로 발송되었을 가능성이 높음
• 안전한 메일 = 악성 URL, 악성 첨부파일, 피싱 의도, 계정 탈취 정황 등이 없음

두 개념은 서로 다른 개념임

정상 도메인의 계정이 탈취되어 발송된 메일은 SPF, DKIM, DMARC를 올바르게 설정해도 인증은 통과할 수 있음

따라서 Email 인증은 보안의 출발점이지, 최종 판단 기준은 아님

---

⁎ SPF: 발송 서버 권한 검증

⁑ SPF 개요

SPF: Sender Policy Framework

이 IP 주소의 메일 서버가 이 도메인을 사용해서 메일을 보낼 권한이 있는가?

도메인 소유자는 DNS TXT 레코드에 자신의 도메인으로 메일을 보낼 수 있는 서버 정보를 게시함
수신 메일 서버는 메일을 받은 뒤, 발송 서버의 IP 주소가 해당 도메인의 SPF 레코드에 포함되어 있는지 확인함

⁂ SPF가 확인하는 대상

SPF는 주로 SMTP Envelope 영역을 확인함

* SMTP Envelope :
메일 서버가 실제 배달을 위해 사용하는 전송용 정보.
사용자가 보는 Header From과 별개로,
MTA 간 SMTP 통신에서 발신자와 수신자를 판단하는 데 사용

대표적으로 다음 값이 관련됨

• SMTP MAIL FROM
• HELO / EHLO
• Return-Path

SPF는 기본적으로 이 Envelope 기반 도메인을 보고 발송 서버 권한을 확인함. 따라서 SPF만으로는 사용자가 보는 From 도메인이 진짜인지 충분히 확인하기는 어려움

⁂ SPF 동작 흐름

1. 외부 메일 서버가 수신 서버로 메일 전송
2. 수신 서버가 연결된 발송 서버 IP 확인
3. SMTP MAIL FROM 또는 HELO 도메인 확인
4. 해당 도메인의 SPF TXT 레코드 DNS 조회
5. SPF 레코드에 발송 서버 IP가 포함되어 있는지 확인
6. 결과에 따라 pass, fail, softfail, neutral 등으로 판단

⁂ SPF 레코드 예시

SPF 레코드는 DNS TXT 레코드로 게시됨

Example

example.com. TXT "v=spf1 ip4:203.0.113.10 include:_spf.example.net -all"

• 의미

  • v=spf1
    : SPF 버전 표시

  • ip4:203.0.113.0
    : 203.0.113.10 IP는 example.com 도메인으로 메일 발송 가능

  • include:_spf.example.net
    : _spf.example.net에 정의된 발송 서버도 허용

  • -all
    : 위 조건에 맞지 않으면 실패로 판단

SPF 결과 해석

결 과	의 미
pass	발송 서버가 SPF 정책에 부합함
fail	발송 서버가 SPF 정책에 부합하지 않음
softfail	부합하지 않지만 강한 차단보다는 의심 수준으로 처리
neutral	도메인 소유자가 명확한 판단을 제공하지 않음
temperror	일시적인 DNS 오류 등으로 검증 실패
permerror	SPF 레코드 문법 오류 등 영구 오류

⁂ SPF의 한계

SPF는 발송 서버 권한을 확인하는데 유용하지만 한계가 있음

첫째, 사용자가 보는 Header From을 직접 검증하지 않음
SPF가 pass여도 메일 화면에 보이는 From 도메인이 SPF 검증 도메인과 다를 수 있음

둘째, 메일 포워딩 환경에서 실패할 수 있음
메일이 중간 서버를 거쳐 전달되면 최종 수신 서버 입장에서는 원래 발송 서버가 아니라 포워딩 서버의 IP를 보게되기 때문에 원래 도메인의 SPF 레코드에 포워딩 서버 IP가 없으면 SPF fail이 발생할 수 있음

셋째, SPF 레코드를 너무 넓게 설정하면 실효성이 떨어짐
예를 들어 너무 많은 외부 서비스를 include 하거나 +all 처럼 모든 발송자를 허용하는 정책을 사용하면 SPF는 사실상 보소 기능을 하지 못함

넷째, DNS 조회 제한 문제가 있음
SPF는 include, a, mx 등의 메커니즘을 처리하면서 DNS 조회를 수행하는데, 조회가 과도하게 많아지면 permerror가 발생할 수 있음

---

⁎ DKIM: 메일 내용과 서명 검증

⁑ DKIM 개요

DKIM: DomainKeys Identified Mail
이 메일은 특정 도메인이 서명한 메일이며, 서명된 이후 주요 내용이 변경되지 않았는가?

SPF가 발송 서버 IP를 확인한다면, DKIM은 메일에 포함된 디지털 서명을 검증함

DKIM는 공개 키 기반 구조를 사용함

발송 측은 메일을 보낼 때 개인키로 메일에 서명하고, 수신 측은 DNS에 게시된 공개키를 조회해서 서명을 검증함

⁂ DKIM이 확인하는 대상

DKIM은 메일의 특정 Header와 Body를 대상으로 서명을 생성함

발송 서버는 메일을 보낼 때 DKIM-Signature 헤더를 추가함
이 헤더에는 서명 도메인, 셀렉터, 서명 알고리즘, 서명 대상 헤더 목록, 본문 해시, 실제 서명값 등이 포함됨

Example

DKIM-Signature:
  v=1;
  a=rsa-sha256'
  d=example.com;
  s=selector1;
  h=from:to:subject:date;
  bh=...;
  b=...

주요 값은 다음과 같음

태 그	의 미
v	DKIM 버전
a	서명 알고리즘
d	서명 도메인
s	셀렉터
h	서명 대상 헤더 목록
bh	Body hash
b	실제 서명값

⁂ DKIM 동작 흐름

1. 발송 도메인이 DKIM 키 쌍 생성
2. 공개키는 DNS TXT 레코드에 게시
3. 개인키는 발송 메일 서버에 보관
4. 메일 발송 시 개인키로 메일 Header/Body 일부에 서명
5. 수신 서버가 DKIM-Signature 헤더 확인
6. d= 도메인과 s= 셀렉터를 이용해 DNS에서 공개키 조회
7. 공개키로 서명 검증
8. 서명이 유효하면 d= 도메인 기준 pass

DKIM은 발송 서버 IP에만 의존하지않음.

SPF는 발송 서버 IP를 기준으로 검증하기 때문에 포워딩 환경에서 실패할 수 있음. 반면 DKIM은 메일 자체에 서명이 포함되어있기 때문에 중간에 메일이 다른 서버를 거쳐 전달되더라도, 서명된 Header와 Body가 크게 변경되지 않으면 DKIM 검증은 유지될 수 있음

또한 DKIM은 메일이 발송된 이후 주요 내용이 변경되었는지(무결성) 확인하는 데 도움을 줌.
메일 본문이나 서명 대상 헤더가 변조되면 서명 검증에 실패할 수 있음

⁂ DKIM-Signature와 공개키 조회

DKIM에서 가장 중요한 값은 d=와 s=임

// 서명한 도메인
d=example.com

// 공개키를 찾기 위한 셀렉터
s=selector1

수신 서버는 이 값을 조합해서 DNS에 공개키를 조회함

selector1._domainkey.example.com

해당 DNS TXT 레코드에 공개키가 게시되어 있고, 이 공개키로 서명을 검증할 수 있으면 DKIM 검증이 통과함.

즉 DKIM는 메일 안의 서명값만 보는 것이 아니라, DNS에 게시된 공개키와 메일에 포함된 서명을 함께 비교하는 방식임

⁂ DKIM의 한계

DKIM도 단독으로는 충분하지 않음

첫째, 사용자가 보는 From 도메인이 반드시 해당 도메인은 아님
DKIM은 서명 도메인이 메일을 책임을 가진다는 의미임
예를 들어 d=mailer.example.net 으로 DKIM을 통과했더라도, 사용자가 보는 From이 example.com 일 수 있음

둘째, 공격자가 자신이 소유한 도메인으로 DKIM을 정상 설정하면 DKIM은 pass될 수 있음
DKIM pass는 "서명 검증 성공"으로 "안전한 발신자"를 의미하지 않음

셋째, 메일링 리스트나 일부 보안 솔루션이 메일 본문이나 헤더를 수정하면 DKIM 서명이 깨질 수 있음
예를 들어 제목에 태그를 추가하거나, 본문 하단에 안내 문구를 삽입하거나, 첨부파일 처리 과정에서 구조가 바뀌면 DKIM fail이 발생할 수 있음

넷째, 발송 도메인이 개인키가 유출되면 공격자가 정상 DKIM 서명을 생성할 수 있음
따라서 DKIM 키 관리의 주기적인 키 교체도 중요함

---

⁎ DMARC: From 도메인 기준 정책 검증

⁑ DMARC 개요

DMARC: Domain-based Message Authentication, Reporting, and Conformance
SPF 또는 DKIM이 통과했는가?
그리고 통과한 인증 도메인이 사용자가 보는 From 도메인과 일치하거나 같은 조직 도메인인가?
실패했다면 도메인 소유자가 요청한 정책은 무엇인가?

SPF와 DKIM은 각각 유용하지만, 단독으로는 사용자가 보는 Header From 도메인을 충분히 보호하기 어려움

SPF는 Envelope 도메인을, DKIM은 서명 도메인을 검증하지만 사용자가 실제로 보는 것은 Header From 도메인임

DMARC은 이 간극을 연결함. SPF와 DKIM을 기반으로 하되, 최종 기준을 Header From 도메인에 맞추는 정책 구조임

⁂ DMARC가 필요한 이유

Header From: security@example.com
MAIL FROM: bounce@sender.example.net
DKIM d=sender.example.net

위와 같은 메일일때 SPF가 sender.example.net 기준으로 pass될 수 있으며, DKIM도 sender.example.net 기준으로 pass 될 수 있지만 사용자가 보는 From은 example.com임

그렇다면 sender.example.net의 인증 성공을 example.com의 인증 성공으로 볼 수 있는가?

DMARC는 이 문제를 Alignment로 판단함

⁂ SPF/DKIM Alignment

Alignment는 SPFG 또는 DKIM에서 인증된 도메인이 Header From 도메인과 정렬되어 있는지 확인하는 개념

DMARC에서 중요한 도메인

1. Heacer From domain: 사용자가 보는 From 도메인
2. SPF domain: SMTP MAIL FROM 기반 SPF 검증 도메인
3. DKIM d= domain: DKIM 서명 도메인

DMARC가 pass 되려면 다음 조건 중 하나가 만족되어야 함

SPF pass + SPF domain이 Header From domain과 Alignment

    OR

DKIM pass + DKIM d= domain이 Header From doamin과 Alignment

둘중 하나만 만족해도 DMARC는 pass 될 수 있음

DMARC Alignment의 주요 조건 두가지

• Relaxed Alignment
  : 조직 도메인이 같으면 정렬된 것으로 판단

• Strict Alignment
  : 도메인이 정확히 동일해야 정렬된 것으로 판단

Example

From: user@example.com
d=mail.example.com

• Relaxed Alignment
  pass = example.com이라는 조직 도메인이 같기 때문

H e a d e r   F r o m	인 증  도 메 인	R e l a x e d	S t r i c t
example.com	example.com	pass	pass
example.com	mail.example.com	pass	fail
example.com	example.net	fail	fail

⁂ DMARC 정책

도메인 소쥬자는 DNS에 DMARC 정책을 게시할 수 있음

DMARC 레코드는 일반적으로 다음 위치에 TXT 레코드로 게시됨

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-report@example.com

주요 값은 다음과 같음

태 그	의 미
v	DMARC 버전
p	기본 정책
rua	Aggregate Report 수신 주소
ruf	Failure Report 수신 주소
adkim	DKIM Alignment 모드
aspf	SPF Alignment 모드
sp	서브 도메인 정책

• 핵심 정책 값

  • p=none
    : 인증 결과를 모니터링하지만 별도 처리 요청은 하지 않음

  • p=quarantine
    : DMARC 실패 메일을 스팸함 등으로 격리하도록 요청

  • p=reject
    : DMARC 실패 메일을 거부하도록 요청
    
    다만 DMARC 정책은 도메인 소유자의 요청 정책에 가까움
    최종적으로 메일을 어떻게 처리할지는 수신 측 메일 시스템의 정책에 따라 달라질 수 있음
    
    예를 들어 도메인 소유자가 p=reject를 게시했더라도, 수신 측은 자체 정책과 평판, 예외 조건, 사용자 설정 등을 함께 고려할 수 있음.

• DMARC 보고서

  • rua 태그를 사용하면 수신 측 메일 시스템이 Aggregate Report를 보낼 수 있음
    이 보고서는 특정 도메인을 사용한 메일이 어느 IP에서 발송되었는지, SPF/DKIM/DMARC 결과가 어땠는지 확인하는데 사용됨
    ex: rua=mailto:dmarc-report@example.com
    
    
  • 확인 가능 사항
    • 정상 발송 시스템이 SPF/DKIM/DMARC를 통과하는지
    • 외부 SaaS 발송 시스템이 누락되어 있는지
    • 알 수 없는 IP에서 도메인을 사칭하고 있는지
    • DMARC 정책을 none에서 quarantine, reject로 강화해도 되는지

⁂ DMARC의 한계

DMARC는 SPF와 DKIM의 한계를 보완하지만, 모든 메일 위협을 막는 기술은 아님

첫째, DMARC는 도메인 사용 권한을 검증함
메일 본문의 URL이 악성인지, 첨부파일이 위험한지, 문장이 피싱인지까지 판단하는 기술은 아님

둘째, 정상 도메인의 계정이 탈취된 경우 DMARC가 통과할 수 있음
공격자가 실제 조직 계정으로 메일을 발송하면 SPF, DKIM, DMARC가 모두 정상일 수 있음

셋째, 공격자가 유사 도메인을 등록해 SPF, DKIM, DMARC를 정상 설정할 수 있음
예를 들어 example.com이 아니라 examp1e.com 같은 도메인을 사용하면 인증은 통과할 수 있음

넷째, Display Name 공격은 별도 문제
예를 들어 From 표시 이름을 Microsoft Support 처럼 설정하고, 실제 수조는 전혀 다른 도메인을 사용하는 방식

From: Microsoft Support <notice@attacker-domain.com>

이 경우 공격자 도메인에 대한 인증은 정상일 수 있으나 사용자는 표시 이름만 보고 신뢰할 수 있음

따라서 DMARC는 강력한 도메인 인증 정책이지만, 피싱·악성 URL·첨부파일·계정 탈취 탐지와 함께 사용해야함

---

⁎ Email 인증 결과의 해석

⁑ SPF, DKIM, DMARC 비교

SPF, DKIM, DMARC는 서로 대체 관계가 아닌 보완 관계

구 분	SPF	DKIM	DMARC
검증 대상	발송 서버 IP	메일 서명	From 도메인 기준 정책
기준 식별자	MAIL FROM, HELO	DKIM d= 도메인	Header From 도메인
DNS 레코드	SPF TXT	DKIM TXT	DMARC TXT
주요 목적	허용된 서버인지 확인	서명과 무결성 확인	SPF/DKIM 결과와 From 정렬 확인
장점	구조가 단순함	포워딩 환경에 상대적으로 강함	사용자에게 보이는 From 기준 보호
한계	Header From 직접 검증 아님	서명 도메인과 From이 다를 수 있음	콘텐츠 안전성 판단은 아님

세 기술의 관계를 한 문장으로 정리하면 다음과 같음

• SPF는 어디서 보냈는지 확인하고,
• DKIM은 누가 서명했는지 확인하며,
• DMARC는 그 결과가 사용자가 보는 From 도메인과 맞는지 확인함

⁑ 인증 결과를 어떻게 해석해야 하는가

수신 메일 서버나 보안 게이트웨이는 SPF, DKIM, DMARC 검증 결과를 메일 헤더에 기록할 수 있음.

대표적으로 Authentication-Results 헤더가 사용됨.

Example

Authentication-Results: mx.example.com;
 spf=pass smtp.mailfrom=example.com;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com

이 결과는 다음처럼 해석할 수 있음.

//SPF 검증 통과
spf=pass

//SPF 검증에 사용된 MAIL FROM 도메인
smtp.mailfrom=example.com

//DKIM 서명 검증 통과
dkim=pass

//DKIM 서명 도메인
header.d=example.com

//DMARC 검증 통과
dmarc=pass

//DMARC 기준이 된 Header From 도메인
header.from=example.com

보안 분석 시에는 단순히 spf=pass, dkim=pass, dmarc=pass만 볼 것이 아니라, 어떤 도메인을 기준으로 pass되었는지 확인해야 함.

특히 다음을 구분해야 함.

• SPF가 pass된 도메인
• DKIM이 pass된 도메인
• 사용자가 보는 Header From 도메인
• DMARC Alignment 결과

이 네 가지가 맞물려야 발신 도메인 인증 결과를 제대로 해석할 수 있음.

⁑ 운영 관점에서의 점검 포인트

Email 인증은 단순히 DNS 레코드 하나를 추가하는 것으로 끝나지 않음.
실제 운영 환경에서는 메일을 발송하는 시스템이 여러 개일 수 있음.

예를 들어 다음과 같은 발송원이 존재할 수 있음

• 사내 Mail Server
• Cloud Mail
• Marketing SaaS
• CRM
• 고객지원 시스템
• 알림 발송 시스템
• 그룹웨어
• 보안 솔루션
• 외부 위탁 발송 서비스

이 발송원들이 SPF, DKIM, DMARC 구조에 제대로 반영되어야 함

1. 발송원 목록 식별

가장 먼저 해야 할 일은 우리 도메인으로 메일을 보내는 시스템을 식별하는 것임.
정상 발송원을 모르고 DMARC 정책을 강하게 적용하면 정상 메일이 차단될 수 있음.

따라서 다음을 먼저 정리해야 함.

• 어떤 시스템이 우리 도메인으로 메일을 보내는가?
• 어떤 IP 또는 서비스가 사용되는가?
• SPF include가 필요한가?
• DKIM 서명은 어느 도메인으로 되는가?
• Header From 도메인과 Alignment가 맞는가?

2. SPF 레코드 과도 확장 방지

SPF 레코드에 include를 계속 추가하면 구조가 복잡해지기 때문에 필요한 발송원만 허용해야 함
불필요한 include가 많아지면 허용 범위가 넓어지고, DNS 조회 제한 문제도 발생할 수 있음.

피해야 할 설정 예시: v=spf1 +all

이 설정은 사실상 모든 발송자를 허용하는 의미이므로 보호 효과가 없음.

3. DKIM 키 관리

DKIM은 개인키가 중요함.
개인키가 유출되면 공격자가 정상 DKIM 서명을 생성할 수 있기 때문에 DKIM 키는 안전하게 보관하고, 필요 시 주기적으로 교체해야 함.

또한 여러 발송 시스템을 사용하는 경우 각 시스템의 DKIM 서명 도메인과 selector를 관리해야 함

4. DMARC는 단계적으로 강화

DMARC는 일반적으로 다음 흐름으로 적용하는 것이 안정적임

p=none
모니터링

↓ 보고서 분석

p=quarantine
의심 메일 격리 요청

↓ 정상 발송원 정리

p=reject
실패 메일 거부 요청

처음부터 p=reject를 적용하면 정상 발송 시스템 중 일부가 인증 구조에 반영되지 않았을 때 업무 메일이 차단될 수 있음

따라서 DMARC 보고서를 기반으로 정상 발송원을 정리한 뒤 정책을 강화하는 방식이 적절함.

5. 인증 결과와 보안 정책 연결

SPF, DKIM, DMARC 결과는 보안 정책의 중요한 입력값이지만 인증 결과만으로 최종 허용/차단을 결정하기보다는 다른 보안 신호와 함께 판단해야 함

예시 조합:

• DMARC fail + 신규 도메인 + 의심 URL
  → 차단 또는 격리

• DMARC pass + 정상 도메인 + 악성 첨부 탐지
  → 차단

• DMARC pass + 정상 거래처 + 평소와 다른 송금 요청
  → 추가 검증 또는 경고

• SPF fail + DKIM pass + DMARC pass
  → 포워딩 또는 중간 경로 가능성 검토

즉, 인증 결과는 중요한 신뢰 신호지만, 단독 판단 기준은 아님.

---

⁎ 정리

Email 인증은 메일이 실제로 해당 도메인을 사용할 권한이 있는 방식으로 발송되었는지 확인하기 위한 구조

SPF, DKIM, DMARC의 역할

• SPF: 발송 서버 IP가 허용된 서버인지 확인
• DKIM: 메일에 포함된 도메인 서명과 무결성 확인
• DMARC: SPF/DKIM 결과가 사용자가 보는 From 도메인과 정렬되는지 확인하고 정책 적용

SPF는 발송 서버 권한을 확인하지만 Header From을 직접 검증하지 않음.
DKIM은 메일 서명을 검증하지만 서명 도메인과 사용자가 보는 From 도메인이 다를 수 있음.
DMARC는 이 둘을 From 도메인 기준으로 연결해 도메인 사칭 방어를 강화함.

다만 인증 성공이 곧 안전한 메일을 의미하지는 않음

정상 계정이 탈취될 수 있고, 공격자도 자신이 소유한 도메인에 SPF, DKIM, DMARC를 정상 설정할 수 있음.
또한 악성 URL, 첨부파일, 사회공학적 문구는 인증 기술만으로 판단할 수 없음.

따라서 Email 보안에서는 인증을 다음처럼 이해해야 함.

• Email 인증 = 도메인 사용 권한 검증

• Email 보안 = 인증 결과 + 콘텐츠 분석 + 평판 + 행위 분석 + 정책 판단