이메일 인증
이메일 인증(Email authentication)은 이메일의 발신 서버 또는 발신 도메인이 정당한 발신자인지를 검증하기 위한 기술이다. 이메일 프로토콜에서는 발신자 정보를 사칭할 수 있기 때문에 이를 방지하기 위한 여러 인증 기술이 개발되었다. 대표적으로 SPF(Sender Policy Framework), DKIM(DomainKeys Identified Mail), DMARC(Domain-based Message Authentication, Reporting, and Conformance)가 사용된다.
현대의 이메일 시스템에서는 SPF와 DKIM을 이용해 발신 도메인을 인증하고, DMARC를 통해 이 인증 결과와 사용자가 보는 발신자 주소의 도메인이 일치하는지를 확인하는 방식이 널리 사용된다.[1]
SPF(Sender Policy Framework)는 특정 도메인의 이메일을 발송할 권한이 있는 서버를 DNS를 통해 지정하는 기술이다. 현재 SPF 규격은 RFC 7208에 정의되어 있다.[2]
도메인 소유자는 DNS의 TXT 레코드에 해당 도메인을 이용해 메일을 발송할 수 있는 서버를 지정한다. 이메일을 수신한 서버는 실제 메일을 전달한 서버의 IP 주소와 SPF 정책을 비교하여 발송 권한이 있는지를 확인한다.
예를 들어 다음과 같은 SPF 레코드를 사용할 수 있다.
example.com TXT "v=spf1 include:_spf.example.net ~all"
이는 `_spf.example.net`의 SPF 정책에서 허용한 서버들이 `example.com` 도메인의 이메일을 발송할 수 있도록 허용한다는 의미이다.
SPF는 주로 SMTP의 `MAIL FROM`에 사용된 도메인을 검사한다.[2] 따라서 사용자가 이메일 프로그램에서 보는 `From:` 주소의 도메인과 SPF가 인증한 도메인이 반드시 같지는 않는다.
또한 이메일이 다른 메일 서버를 거쳐 전달(forwarding)되는 경우 실제 발송 서버의 IP 주소가 변경되면서 SPF 인증에 실패할 수 있다는 한계가 있다.
DKIM(DomainKeys Identified Mail)은 발신 측에서 이메일에 디지털 서명을 추가하고, 수신 서버가 DNS에 공개된 공개키를 이용하여 이를 검증하는 기술이다. DKIM은 RFC 6376에 정의되어 있다.[3]
발신 서버는 이메일을 보낼 때 DKIM 개인키를 이용하여 메시지의 일부 헤더와 본문에 서명하고 `DKIM-Signature` 헤더를 추가한다.
예를 들면 다음과 같다.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail; ...
여기서 `d=`는 서명에 사용된 도메인을 의미하며, `s=`는 공개키를 구분하기 위한 selector를 의미한다.
위의 경우 수신 서버는 다음 DNS 이름에서 공개키를 조회할 수 있다.
mail._domainkey.example.com
수신 서버가 공개키를 이용하여 서명을 정상적으로 검증하면 해당 메시지가 해당 도메인의 DKIM 키를 보유한 시스템에서 서명되었으며, 서명 대상 부분이 전송 과정에서 변조되지 않았음을 확인할 수 있다.[3]
SPF와 달리 DKIM은 발송 서버의 IP 주소 자체를 인증하지 않는다. 따라서 메일이 다른 서버를 거쳐 전달되더라도 DKIM 서명의 대상이 되는 내용이 변경되지 않았다면 서명이 유효하게 유지될 수 있다.
하나의 도메인에서 여러 이메일 서비스를 사용하는 경우 각 서비스가 서로 다른 selector를 사용하는 것도 가능하다.
예를 들어 다음과 같은 DKIM 레코드들이 하나의 도메인에 동시에 존재할 수 있다.
google._domainkey.example.com ses._domainkey.example.com service._domainkey.example.com
DMARC(Domain-based Message Authentication, Reporting, and Conformance)는 SPF와 DKIM의 인증 결과를 사용자가 실제로 보는 `From:` 주소의 도메인과 연결하고, 인증에 실패한 이메일을 어떻게 처리할 것인지에 대한 정책을 도메인 소유자가 공개할 수 있도록 하는 기술이다.[1]
2026년 5월 발표된 RFC 9989가 현재 DMARC의 표준 규격이며, 기존의 RFC 7489와 RFC 9091을 대체하였다.[1]
DMARC 자체가 SPF나 DKIM과 별개의 새로운 암호학적 인증을 수행하는 것은 아니다. 대신 SPF 또는 DKIM을 통해 인증된 도메인과 이메일의 `From:` 헤더에 표시된 도메인의 관계를 검사한다.
예를 들어 다음과 같은 이메일이 있다고 가정한다.
From: [email protected]
SPF가 인증한 `MAIL FROM` 도메인 또는 DKIM으로 인증된 서명 도메인이 `example.com`과 일치하는지 확인한다. 이를 식별자 정렬(Identifier Alignment)이라고 한다.[1]
예를 들어 다음과 같은 이메일이 발송될 수 있다.
From: [email protected] Return-Path: [email protected]
`other.example`의 정상적인 메일 서버에서 발송했다면 `other.example`에 대한 SPF 검사는 성공할 수 있다.
그러나 사용자가 보는 `From:` 주소의 도메인은 `example.com`이고 SPF에서 인증된 도메인은 `other.example`이므로, 두 도메인이 DMARC의 정렬 조건을 만족하지 않는다면 SPF를 이용한 DMARC 인증은 실패한다.
DMARC 정책은 DNS의 `_dmarc` 하위 도메인에 TXT 레코드로 게시한다.[1]
예를 들어 다음과 같다.
_dmarc.example.com TXT "v=DMARC1; p=none;"
주요 정책은 다음과 같다.
| 정책 | 의미 |
|---|---|
p=none
|
DMARC 인증에 실패하더라도 DMARC 정책을 이유로 별도의 차단이나 격리를 요구하지 않는다. 주로 초기 모니터링에 사용한다. |
p=quarantine
|
DMARC 인증에 실패한 메일을 의심스러운 메일로 취급하도록 요청한다. |
p=reject
|
DMARC 인증에 실패한 메일을 거부하도록 요청한다. |
DMARC는 인증 결과에 대한 보고서를 받을 주소도 지정할 수 있다.
v=DMARC1; p=none; rua=mailto:[email protected]
`rua`는 DMARC 집계 보고서(aggregate report)를 받을 URI를 지정한다. 이를 통해 도메인 소유자는 자신의 도메인을 사용하여 어떤 서버에서 메일이 발송되고 있는지와 SPF·DKIM·DMARC 인증 결과 등을 파악할 수 있다.[1]
DMARC를 처음 도입하는 경우 정상적인 발송 시스템이 모두 올바르게 인증되고 있는지 확인하기 위해 `p=none` 정책과 보고 기능을 이용하여 먼저 모니터링할 수 있다. RFC 9989에서도 `p=none`과 집계 보고 주소를 이용한 모니터링 구성을 예시로 제시하고 있다.[1]
SPF, DKIM, DMARC는 서로 대체하는 기술이라기보다는 상호 보완적인 역할을 한다.
| 기술 | 주요 검증 대상 | 역할 |
|---|---|---|
| SPF | 발송 서버 | 해당 서버가 특정 도메인의 이메일을 발송할 권한이 있는지 확인 |
| DKIM | 디지털 서명 | 특정 도메인이 메시지에 서명했는지 확인하고 서명된 부분의 무결성을 검증 |
| DMARC | SPF·DKIM 인증 도메인과 From 도메인의 관계 | 도메인 정렬을 검사하고 인증 실패 시 처리 정책 및 보고 방법 지정 |
일반적으로 정상적인 이메일 발송 환경에서는 다음과 같은 결과를 목표로 한다.
SPF: PASS DKIM: PASS DMARC: PASS
그러나 DMARC가 성공하기 위해 SPF와 DKIM이 모두 성공해야 하는 것은 아니다.
SPF 또는 DKIM 가운데 하나 이상의 인증이 성공하고, 성공한 인증의 도메인이 From 도메인과 DMARC의 정렬 조건을 만족하면 DMARC 인증은 성공할 수 있다.[1]
따라서 DKIM을 지원하지 않는 이메일 서비스라도 SPF에서 인증된 도메인과 From 도메인이 정렬되어 있다면 SPF를 기반으로 DMARC를 통과할 수 있다.
반대로 메일 전달 등의 이유로 SPF가 실패하더라도 유효한 DKIM 서명이 유지되고 DKIM 서명 도메인이 From 도메인과 정렬되어 있다면 DKIM을 기반으로 DMARC를 통과할 수 있다.
이러한 이유로 일반적인 이메일 발송 환경에서는 SPF와 DKIM을 모두 구성하고, 그 위에 DMARC 정책을 적용하는 방식이 사용된다.
SPF, DKIM, DMARC의 주요 목적 가운데 하나는 이메일의 발신 도메인을 무단으로 사용하는 이메일 스푸핑(Email spoofing)을 탐지하고 줄이는 것이다. DMARC는 특히 `From:` 헤더에 표시되는 도메인의 무단 사용을 방지하는 것을 주요 목적으로 한다.[1]
예를 들어 제3자가 자신의 메일 서버에서 다음과 같이 발신자를 사칭할 수 있다.
From: [email protected]
해당 서버가 `example.com`의 SPF 정책에 의해 허용되지 않았고 `example.com`과 정렬된 유효한 DKIM 서명도 없다면 DMARC 인증에 실패한다.
도메인 소유자가 `p=reject` 정책을 게시한 경우 DMARC에 참여하는 수신 서버에 이러한 메일을 거부하도록 요청할 수 있다.
다만 SPF, DKIM, DMARC가 이메일의 내용 자체가 안전하거나 실제 발신자가 신뢰할 수 있는 사람이라는 사실까지 보장하는 것은 아니다. 정상적으로 인증된 도메인의 계정이 탈취되거나 공격자가 유사한 도메인을 별도로 등록하는 경우 등은 이러한 도메인 인증만으로 방지할 수 없다.
- RFC 7208 - Sender Policy Framework (SPF)
- RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
- RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC), RFC Editor.
- ↑ 2.0 2.1 RFC 7208 - Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, RFC Editor.
- ↑ 3.0 3.1 RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures, RFC Editor.
