최근 PHP 보안 취약점과 관련한 소식이 이어지면서 서버 보안에 대한 관심이 높아지고 있습니다.

PHP, Nginx, 운영체제의 보안 패치를 적용하는 것은 당연히 중요합니다.
그런데 사이트를 운영하는 입장에서 한 가지 더 관심을 가져야 할 부분이 있습니다.

바로 이메일 보안입니다.

웹사이트의 관리자 계정, 비밀번호 재설정, 회원 인증, 호스팅과 도메인 관리까지 이메일에 의존하는 경우가 많습니다.
서버를 아무리 안전하게 관리하더라도
이메일 계정이 탈취되거나 메일 전달 경로가 공격받으면 예상하지 못한 피해로 이어질 수 있습니다.

특히 그누보드처럼 회원가입과 계정 복구에 이메일을 사용하는 CMS에서는 이메일을 단순한 알림 수단으로만 볼 수 없습니다.
사이트의 인증 체계와 연결된 중요한 보안 요소이기 때문입니다.

이번에는 이메일 보안에서 무엇을 확인해야 하는지 살펴보고,
제가 직접 운영하는 Glitter.kr 메일 호스트의 구성과 실제 보안 검증 결과도 하나의 사례로 소개해 보려고 합니다.
 

이메일은 생각보다 많은 권한과 연결되어 있습니다

사이트 관리자 이메일이 탈취되었다고 가정해 보겠습니다.

공격자는 해당 이메일을 통해 CMS 관리자 계정의 비밀번호 재설정을 시도할 수 있습니다.
호스팅이나 도메인 등록업체의 복구 이메일까지 동일하다면 피해 범위는 더 넓어질 수 있습니다.

서버의 취약점을 직접 공격하지 않고도 정상적인 계정 복구 절차를 악용해 관리 권한을 확보할 가능성이 생기는 것입니다.

반대로 이메일 계정이 탈취되지 않았더라도 공격자가 운영자의 도메인을 사칭해 회원들에게 피싱 메일을 보내는 문제도 있습니다.

이 두 가지는 서로 다른 문제입니다.

• 이메일 계정 탈취는 인증정보와 계정 접근 권한을 보호해야 하는 문제입니다.

• 이메일 도메인 사칭은 발신자 인증과 도메인 정책을 통해 대응해야 하는 문제입니다.

• 메일 전송 경로의 공격은 DNS와 TLS를 통해 전달 대상과 암호화 연결을 검증해야 하는 문제입니다.

따라서 이메일 보안을 단순히 SMTP 서버에 TLS 인증서를 설치하는 것으로 끝내서는 안 됩니다.
 

SPF, DKIM, DMARC만으로 충분할까요?

이메일 보안에서 가장 많이 접하는 기술은 SPF, DKIM, DMARC입니다.

SPF는 메일의 SMTP Envelope From 도메인 등을 기준으로 해당 도메인이 허용한 발신 서버인지 확인하는 기술입니다.

DKIM은 메일에 전자서명을 추가하여 수신 측에서 서명 도메인과 서명 대상 메시지의 무결성을 검증할 수 있도록 합니다.

DMARC는 SPF와 DKIM의 인증 결과를 사용자에게 표시되는 From 도메인과 연계하여 검사하고,
인증에 실패한 메일에 대한 처리 정책을 제시합니다.
DMARC는 p=none, p=quarantine, p=reject와 같은 정책을 사용할 수 있으며, 설정된 정책에 따라 인증 실패 메일에 대한 처리 요청 수준이 달라집니다.
따라서 DMARC 레코드가 존재한다는 사실만으로 도메인 사칭 메일에 대한 강제 차단 정책이 적용되고 있다고 판단할 수는 없습니다.
실제 적용 수준을 평가하려면 정책 값과 SPF·DKIM의 도메인 정렬 결과, 수신 측의 처리 결과를 함께 확인해야 합니다.
세 기술은 이메일 도메인 사칭을 줄이는 데 중요한 역할을 합니다.

하지만 이들만으로 메일 전송 경로 전체의 안전성이 보장되는 것은 아닙니다.

예를 들어 송신 서버가 메일을 전달할 때
DNS에서 조회한 MX 서버가 올바른 대상인지,
SMTP 연결에서 TLS가 안전하게 적용되는지,
암호화 연결이 공격자에 의해 약화되지는 않았는지 등은 별도로 살펴봐야 합니다.

여기서 DNSSEC, DANE, MTA-STS 같은 기술이 등장합니다.
 

DNSSEC와 DANE은 무엇을 보호할까요?

DNSSEC는 DNS 응답의 출처와 무결성을 검증할 수 있도록 DNS 데이터에 전자서명을 적용하는 기술입니다.

DNSSEC 검증을 수행하는 확인자는 루트에서 상위 도메인과 해당 도메인으로 이어지는 신뢰 체인을 통해
DNS 데이터가 올바르게 서명되었는지 확인할 수 있습니다.

DANE은 이러한 DNSSEC 기반 위에서 TLSA 레코드를 이용해 TLS 인증서나 공개키에 대한 검증 정보를 제공합니다.

SMTP에서 DANE을 지원하는 송신서버는 DNSSEC로 검증된 MX 정보와 TLSA 레코드를 활용하여 서버의 TLS 연결 검증을 할 수 있습니다.

일반적인 SMTP의 기회적 TLS(Opportunistic TLS)는 암호화를 시도하지만,
별도의 강제 정책이 없다면 TLS 연결이 실패했을 때 평문 전송으로 전환될 수 있습니다.

반면 DNSSEC로 인증된 유효한 DANE TLSA 정책이 있는 경우, 이를 지원하는 송신 서버는 해당 정책에 맞는 TLS 연결을 요구할 수 있습니다.

따라서 공격자가 TLS 연결을 약화시키거나 잘못된 인증서를 제시하는 위험을 줄이는 데 도움이 됩니다.

다만 DANE은 송신 측 서버도 이를 지원하고 실제로 검증해야 효과가 있습니다.
DNSSEC와 TLSA 레코드를 게시했다고 해서 모든 상대 메일 서버가 자동으로 DANE을 사용하는 것은 아닙니다.

MTA-STS는 다른 방식으로 SMTP TLS 정책을 전달합니다.
송신 측이 이를 지원하면 HTTPS로 게시된 정책에 따라 지정된 MX 서버와 TLS 인증서를 확인할 수 있습니다.

TLS-RPT는 TLS 전달 과정에서 발생한 문제를 보고받는 데 활용할 수 있습니다.
MTA-STS는 게시된 정책의 모드에 따라 실제 적용 수준이 달라집니다.
`enforce`는 정책에 맞지 않는 SMTP 연결을 통한 전달을 제한하고, `testing`은 정책 위반을 보고하면서도 전달을 허용할 수 있으며, `none`은 활성 강제 정책을 적용하지 않는 모드입니다.
MTA-STS와 TLS-RPT의 공개 설정은 다음과 같이 확인할 수 있습니다.

dig @1.1.1.1 _mta-sts.glitter.kr TXT +short
dig @1.1.1.1 _smtp._tls.glitter.kr TXT +short
curl -fsS https://mta-sts.glitter.kr/.well-known/mta-sts.txt

MTA-STS 정책 파일에서는 version, mode, mx, max_age 값을 확인할 수 있습니다.
TLS-RPT 레코드에서는 보고서 수신 주소 등의 설정을 확인할 수 있습니다.
다만 공개된 정책을 조회하는 것과 외부 송신 서버가 실제로 해당 정책을 적용하는 것은 별개의 문제입니다.
또한 TLS-RPT 레코드가 존재한다고 해서 보고서가 정상적으로 수신되고 분석되고 있다는 사실까지 입증되는 것은 아닙니다.

이들 기술은 목적과 적용 범위가 다르며, 서로 보완적으로 사용할 수 있습니다.
 

글로벌 메일 서비스에서도 DANE을 사용하고 있습니다

DANE은 개인 메일 서버 운영자만 사용하는 특수한 기술은 아닙니다.

대표적으로 Microsoft는 Exchange Online에서 발신 SMTP DANE 검증을 지원하고 있으며,
수신 측에서도 DNSSEC와 DANE을 사용할 수 있도록 관련 기능을 제공하고 있습니다.

다만 Microsoft 365를 사용하는 모든 고객 도메인이 자동으로 수신 DANE을 적용하는 것은 아닙니다.
고객 도메인의 MX 구성과 서비스 설정에 따라 달라집니다.

Proton Mail과 mailbox.org처럼 보안에 중점을 둔 이메일 서비스에서도 DANE을 활용하고 있습니다.

이러한 사례는 DNSSEC와 DANE이 실제 글로벌 메일 서비스에서 활용되는 표준 기술이라는 점을 보여줍니다.

물론 Google이나 Yahoo를 포함한 모든 대형 메일 서비스가 동일한 방식으로 DANE을 지원한다고 볼 수는 없습니다.

메일 서비스마다 DNSSEC, DANE, MTA-STS 지원 범위가 다르고, 송신과 수신 방향의 지원 여부도 구분해야 합니다.
 

운영중인 Glitter.kr 메일 호스트의 사례

저희는 Glitter.kr에서 웹서비스뿐 아니라 권한 DNS와 메일 인프라도 직접 운영하고 있습니다.

외부 CDN이나 공용 보안 프록시에 웹 트래픽을 위임하지 않고,
DNS와 TLS, 메일 서비스의 주요 정책과 운영 상태를 직접 관리하는 구조입니다.

메일 계층은 Postfix와 Dovecot을 기반으로 구성했습니다.

Postfix는 SMTP 전송을, Dovecot은 IMAP과 POP 서비스를 담당합니다.

여기에 SPF, DKIM, DMARC, DNSSEC, DANE, MTA-STS, TLS-RPT를 조합하여 메일 발신 인증과 전송 경로의 검증 체계를 구성하고 있습니다.
다만 이번 글에서 명령어와 결과를 제시하는 실측 검증은 수신 SMTP의 DNSSEC 및 DANE 구성을 중심으로 진행했습니다.
SPF, DKIM, DMARC와 MTA-STS, TLS-RPT는 운영 구성에 포함되어 있지만,
각 기술의 세부 정책과 실제 적용 결과까지 이번 검증에서 모두 입증한 것은 아닙니다.

공개한 인프라 문서와 실제 운영 환경의 주요 구성은 다음과 같습니다.

영역	운영 구성
운영체제	Linux 기반
권한 DNS	BIND 기반 자체 운영
숨은 마스터 DNS	ns1.glitter.kr
공개 권한 DNS	ns2~ns4.glitter.kr
DNS 신뢰 체계	DNSSEC, KSK/ZSK 분리
메일 서버	Postfix, Dovecot
발신 인증	SPF, DKIM, DMARC
SMTP TLS 인증	DANE, TLSA
전송 정책 및 보고	MTA-STS, TLS-RPT
인증서 관리	Let's Encrypt, 인증서 갱신 자동화
운영 자동화	DNSSEC 서명, 키 관리, 인증서 및 TLSA 관리

Glitter.kr의 메일 호스트는 IPv4 기반으로 운영하고 있습니다.

외부에 공개되는 권한 DNS 서버는 ns2, ns3, ns4이며, ns1은 숨은 마스터로 사용합니다.

이처럼 숨은 마스터와 공개 권한 서버를 분리하면
DNS 영역 데이터를 관리하는 서버와 외부 질의에 응답하는 서버의 역할을 구분할 수 있습니다.

다만 이러한 분리 자체가 모든 공격을 방지하는 것은 아니며, 영역 전송의 접근 통제와 각 서버의 보안 관리가 함께 이루어져야 합니다.
 

실제로 DNSSEC와 DANE이 정상 작동하는지 확인하실 수 있습니다

DNSSEC와 DANE은 설정 파일에 적용하는 것만으로 정상 작동을 보장할 수 없습니다.
실제 외부 DNS 응답이 DNSSEC로 인증되는지, DNS에 게시된 TLSA 레코드가 SMTP 서버의 인증서와 일치하는지 확인해야 합니다.

그래서 이번 글을 준비하면서 Glitter.kr의 실제 메일 서버를 대상으로 DNSSEC와 DANE 검증을 진행했습니다.
이번 검증의 핵심은 DNSSEC 검증 리졸버가 인증한 TLSA 레코드와 실제 SMTP 서버의 인증서 공개키가 일치하는지 확인하는 것입니다.
이를 통해 DANE을 지원하는 외부 송신 서버가 Glitter.kr의 수신 SMTP 서버를 인증할 수 있는 구성이 갖추어져 있는지 점검했습니다.
다음 명령어는 dig와 openssl이 설치된 외부 Linux 서버나 VPS의 셸에서 실행할 수 있습니다.
Glitter.kr 서버의 관리자 권한이나 내부 네트워크 접근 권한은 필요하지 않습니다.

1. MX 레코드와 DNSSEC 검증

실행 명령어

dig @1.1.1.1 glitter.kr MX +dnssec +noall +comments +answer

Glitter.kr의 수신 메일 서버는 mail.glitter.kr입니다.

검증 당시 MX 레코드는 다음과 같았습니다.

glitter.kr. IN MX 0 mail.glitter.kr.

Cloudflare의 DNSSEC 검증 리졸버인 1.1.1.1을 이용해 조회한 결과, DNSSEC 인증을 나타내는 ad 플래그가 반환됐습니다.

확인된 응답 플래그: qr rd ra ad

ad는 Authenticated Data를 의미하며, DNSSEC 검증 리졸버가 응답 데이터를 인증했다는 뜻입니다.
다만 `ad` 플래그는 질의자가 신뢰하는 검증 리졸버가 DNSSEC 인증에 성공했다고 보고한 결과입니다.
이번 확인은 1.1.1.1의 검증 결과를 신뢰하는 방식이며, 외부 검증자가 DNSSEC 신뢰 체인을 직접 계산한 것은 아닙니다.
MX 레코드에는 RRSIG MX 전자서명도 포함되어 있었습니다.

2. MX 호스트의 IPv4 주소와 DNSSEC 검증

실행 명령어

dig @1.1.1.1 mail.glitter.kr A +dnssec +noall +comments +answer

검증 당시 반환된 IPv4 주소는 다음과 같았습니다.

mail.glitter.kr. IN A 115.23.70.228

이 A 레코드에서도 ad 플래그와 RRSIG A 전자서명이 확인되어 DNSSEC 검증에 성공했습니다.

3. SMTP TLSA 레코드와 DNSSEC 검증

실행 명령어

dig @1.1.1.1 _25._tcp.mail.glitter.kr TLSA +dnssec +noall +comments +answer

SMTP 포트 25에 대응하는 TLSA 레코드는 다음과 같았습니다.

TLSA 레코드: _25._tcp.mail.glitter.kr.

TLSA 형식: 3 1 1

공개키 SHA-256 해시: 71C7D49B4462D7F51B182CF725B857CECE562F2D58E797A35375F2CE4AEB2CFD

TLSA 응답에서도 ad 플래그와 RRSIG TLSA 전자서명이 확인됐습니다.

여기서 TLSA 레코드의 3 1 1은 다음 의미입니다.

• 3: DANE-EE, DNSSEC로 인증된 TLSA 레코드를 신뢰 근거로 사용하여 서버의 종단 인증서를 검증하는 방식

• 1: 인증서의 공개키 정보(SPKI) 사용

• 1: SHA-256 해시 사용

SMTP DANE-EE에서는 DNSSEC로 인증된 TLSA 레코드가 인증의 신뢰 근거가 되므로,
일반적인 공개 CA 인증서 체인이나 인증서 호스트명 검증에 의존하지 않고 서버의 인증서를 검증할 수 있습니다.
즉, DNSSEC로 인증된 TLSA 레코드에 SMTP 서버 인증서의 공개키 해시를 게시하고, 이를 통해 실제 TLS 연결을 검증하는 방식입니다.

하지만 DNS에 TLSA 레코드가 존재하는 것만으로는 충분하지 않습니다.

실제 SMTP 서버가 제공하는 인증서의 공개키가 TLSA에 게시된 값과 일치해야 합니다.

4. 실제 SMTP 인증서의 공개키 해시 확인

OpenSSL로 mail.glitter.kr:25에 STARTTLS 연결을 수행하고, 서버 인증서의 공개키를 추출해 SHA-256 해시를 계산했습니다.

openssl s_client -starttls smtp -connect mail.glitter.kr:25 -servername mail.glitter.kr </dev/null 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256

결과는 다음과 같았습니다.

SHA2-256(stdin)= 71c7d49b4462d7f51b182cf725b857cece562f2d58e797a35375f2ce4aeb2cfd

앞서 DNSSEC로 인증된 TLSA 레코드의 해시와 완전히 일치했습니다.

이는 실제 SMTP 서버가 제공하는 인증서의 공개키가 DNS에 게시된 DANE 검증 정보와 일치한다는 의미입니다.

5. OpenSSL을 이용한 DANE-EE 검증

여기서 한 단계 더 나아가 OpenSSL의 DANE 검증 기능으로 실제 SMTP TLS 연결을 확인했습니다.

openssl s_client -starttls smtp -connect mail.glitter.kr:25 -servername mail.glitter.kr -dane_tlsa_domain mail.glitter.kr -dane_tlsa_rrdata "3 1 1 71c7d49b4462d7f51b182cf725b857cece562f2d58e797a35375f2ce4aeb2cfd" </dev/null 2>&1 | grep -Ei 'DANE|Verification|Verify return code|error'

검증 당시 결과는 다음과 같았습니다.

Verification: OK
DANE TLSA 3 1 1 ... matched the EE certificate at depth 0
Verify return code: 0 (ok)

OpenSSL이 실제 SMTP 서버의 인증서를 TLSA 레코드와 비교하여 DANE-EE 방식의 인증에 성공한 것입니다.

다만 이 명령어는 앞서 DNSSEC로 확인한 TLSA 값을 OpenSSL에 직접 전달하는 방식입니다.

OpenSSL 자체가 DNSSEC 신뢰 체인을 검증한 것은 아닙니다.
이번 검증은 DNSSEC 검증 리졸버에서 TLSA 레코드의 인증 결과를 확인한 후,
해당 값을 OpenSSL에 직접 전달하여 실제 SMTP 인증서와 일치하는지 검사한 것입니다.
따라서 DNSSEC 인증과 DANE-EE 인증서 검증을 별도로 수행하고, 두 결과를 함께 확인한 것으로 이해해야 합니다.
또한 인증서의 공개키가 변경되면 명령어에 지정한 TLSA 해시도 현재 DNS에 게시된 값으로 변경해야 합니다.

6. 공개 권한 DNS 서버 간 TLSA 일치 여부 확인

마지막으로 공개 권한 DNS 서버인 ns2.glitter.kr, ns3.glitter.kr, ns4.glitter.kr에 각각 직접 질의했습니다.

for ns in ns2.glitter.kr ns3.glitter.kr ns4.glitter.kr; do echo "=== $ns ==="; dig @"$ns" _25._tcp.mail.glitter.kr TLSA +dnssec +noall +answer +time=3 +tries=1 | grep -E 'TLSA|RRSIG'; done

세 서버 모두 동일한 TLSA 레코드를 반환했으며, RRSIG TLSA 서명도 동일하게 배포되어 있었습니다.

이는 공개 권한 DNS 서버 간에 해당 TLSA 데이터와 서명이 일관되게 제공되고 있음을 보여줍니다.

다만 권한 DNS 서버의 응답을 직접 비교하는 것은 DNSSEC 신뢰 체인 검증과는 별개의 확인 과정입니다.

검증 결과 요약

검증 항목	결과
MX 레코드 조회	정상
MX DNSSEC 검증	성공
MX 호스트 A 레코드 DNSSEC 검증	성공
TLSA 레코드 DNSSEC 검증	성공
SMTP STARTTLS 연결	성공
인증서 SPKI SHA-256과 TLSA 비교	일치
OpenSSL DANE-EE 인증	성공
공개 권한 DNS 3대의 TLSA	일치
공개 권한 DNS 3대의 RRSIG	일치

이번 검증을 통해 Glitter.kr의 수신 SMTP 서버가 DNSSEC로 인증된 TLSA 레코드를 제공하고 있으며,
실제 SMTP 인증서의 공개키도 해당 DANE 정책과 일치한다는 사실을 확인했습니다.
다만 이는 수신 SMTP 서버의 DNSSEC 및 DANE 구성에 대한 검증 결과입니다.
메일 계정의 인증 보안, 메일함 접근 통제, 발신 릴레이의 구간별 TLS 정책, SPF·DKIM·DMARC의 실제 적용 결과까지 검증했다는 의미 아님.
특히
DNSSEC 검증 리졸버를 통한 DNS 응답 인증,
SMTP STARTTLS 연결, 인증서 공개키 해시 비교,
OpenSSL DANE-EE 인증,
공개 권한 DNS 서버 간 데이터 일치 여부를 각각 확인했다는 점에서 의미가 있습니다.

다만 이번 검증은 특정 DNS 검증 리졸버와 SMTP 연결 경로에서 수행한 결과입니다.
모든 외부 송신 서버가 DANE을 사용한다거나, 전 세계 모든 네트워크 경로에서 동일한 결과가 보장된다는 의미는 아닙니다.

또한 인증서 갱신, TLSA 레코드 변경, DNSSEC 서명 갱신 및 DNS 배포 상태에 따라 이후 결과는 달라질 수 있습니다.

외부 VPS나 클라우드 환경에서는 SMTP 포트 25의 아웃바운드 연결이 제한되는 경우도 있습니다.
이때 STARTTLS 연결 실패가 반드시 수신 메일 서버의 DANE 설정 오류를 의미하는 것은 아닙니다.

중요한 것은 보안 기능이 설정되어 있다는 사실만 확인하는 것이 아니라,
외부 환경에서도 실제로 검증되는지 지속적으로 점검하는 것입니다.
 

인증서 자동 갱신도 주의해야 합니다

DANE을 운영하면서 특히 중요하게 생각하는 부분은 인증서 갱신과 TLSA 레코드의 관계입니다.

일반적인 HTTPS 서비스에서는 인증서를 갱신하고 웹서버에 적용하면 작업이 끝나는 경우가 많습니다.

그러나 DANE을 사용하는 SMTP 서버에서는 인증서의 공개키와 TLSA 레코드가 일치하는지도 확인해야 합니다.

Glitter.kr에서 사용하는 3 1 1 방식은 인증서 전체가 아니라 공개키 정보의 SHA-256 해시를 사용합니다.

따라서 인증서를 갱신하더라도 기존 공개키를 유지한다면 TLSA 값을 변경할 필요가 없을 수 있습니다.

반대로 새로운 공개키를 사용하면 TLSA 레코드도 갱신해야 합니다.

문제는 DNS 캐시입니다.

TLSA 레코드를 변경하더라도 외부 DNS 리졸버에는 이전 값이 TTL 동안 남아 있을 수 있습니다.

새로운 인증서를 먼저 적용하고 이전 TLSA 레코드가 캐시에 남아 있다면 DANE 검증에 실패하여 메일 전달이 지연될 수 있습니다.

따라서 공개키를 교체할 때는 새 TLSA 값을 미리 게시하고,
기존 값과 새 값을 함께 유지하는 전환 기간을 마련하는 등 DNS 캐시와 인증서 교체 순서를 고려해야 합니다.
안전한 공개키 교체를 위해서는 다음과 같은 절차를 고려할 수 있습니다.
1. 새로운 인증서의 공개키를 기준으로 TLSA 값을 생성합니다.
2. 기존 TLSA 레코드를 유지한 상태에서 새로운 TLSA 레코드를 추가로 게시합니다.
3. DNSSEC 서명과 공개 권한 DNS 서버의 배포 상태를 확인합니다.
4. 기존 DNS 캐시의 TTL을 고려하여 충분한 전환 시간을 확보합니다.
5. 새로운 인증서를 SMTP 서버에 적용하고 외부에서 DANE 검증을 수행합니다.
6. 이전 TLSA 레코드의 캐시 만료와 전환 상태를 확인한 후 기존 값을 제거합니다.
이 절차는 공개키를 변경하는 경우의 일반적인 전환 방법이며, 실제 적용 시에는 DNS 캐시와 인증서 배포 상태를 함께 확인해야 합니다.
DNSSEC 서명 역시 유효기간이 있으므로 자동 재서명이 정상적으로 이루어지는지 확인해야 합니다.

제가 인증서 갱신과 TLSA 레코드 관리, DNSSEC 서명과 배포를 연계해 운영하려는 이유도 여기에 있습니다.

보안 기능은 적용하는 것만큼이나 갱신과 변경 과정에서도 정상적으로 유지되도록 관리하는 것이 중요합니다.
 

메일 전송 경로도 직접 관리하고 있습니다

Glitter.kr의 발신은 공개된 인프라 설계상 한국에서 싱가포르를 거쳐 독일 또는 미국의 릴레이로 이어지는 다단계 전송 경로를 사용합니다.

이러한 구성을 사용하는 이유 중 하나는 메일 전달성을 개선하기 위해서입니다.
다만 다단계 릴레이를 사용한다는 사실만으로 전달성이 개선되었다고 단정할 수는 없습니다.
실제 효과는 릴레이 서버의 IP 평판, 발신 인증, 수신 측 정책, 전달 성공률과 지연 시간 등을 함께 확인해야 판단할 수 있습니다.
다만 릴레이를 여러 단계 거친다는 사실 자체가 보안을 강화하는 것은 아닙니다.
각 구간에서 어떤 TLS 정책을 적용하고 상대 서버를 어떻게 검증하는지가 중요합니다.

또한 릴레이를 사용한다는 것은 해당 전송 구간과 운영 주체에 대한 신뢰도 함께 고려해야 한다는 의미입니다.

특히 DANE은 실제로 SMTP 연결을 수행하는 서버에서 검증해야 합니다.

Glitter.kr의 Postfix에 DANE을 설정하더라도 이후 외부 릴레이가 최종 수신 서버로 메일을 전달한다면,
그 마지막 구간의 DANE 검증 여부는 해당 릴레이의 설정과 기능에 달려 있습니다.

따라서 수신 서버에 DANE을 제공하는 것과 발신 경로 전체에서 DANE을 사용하는 것은 구분해야 합니다.
이번 글에서 제시한 수신 SMTP의 DANE 검증 결과만으로는
한국, 싱가포르, 독일 또는 미국으로 이어지는 발신 경로의 각 구간에서 TLS 인증과 DANE 검증이 정상적으로 수행되는지 확인할 수 없습니다.

제가 지향하는 것은 단순히 모든 서버를 직접 보유하는 것이 아니라,
메일이 어떤 경로로 이동하고 어떤 정책으로 보호되는지 파악하고 검증할 수 있는 운영 구조입니다.

물론 SMTP 구간의 TLS는 메일 내용 자체의 종단 간 암호화와는 다릅니다.
메일 서버나 릴레이에서 메시지를 처리할 수 있으며,
메시지 자체의 기밀성을 별도로 보장하려면 S/MIME이나 OpenPGP 같은 기술을 검토해야 합니다.
 

외부 서비스를 사용하지 않는 것이 더 안전할까요?

그렇다고 생각하지는 않습니다.

직접 운영하면 DNS 설정, 인증서, 로그, 서비스 정책을 스스로 통제하고 점검할 수 있다는 장점이 있습니다.

반면 보안 패치, 장애 대응, 키 관리, 백업, 침해 탐지까지 운영자가 책임져야 합니다.

전문적인 보안 인력과 인프라를 갖춘 외부 서비스가 소규모 자체 운영 환경보다 더 안전한 경우도 충분히 있습니다.

제가 자체 운영을 선택한 이유는 외부 서비스가 본질적으로 위험해서가 아닙니다.

신뢰를 어디에 두고 있으며, 그 신뢰가 실제로 어떻게 검증되는지 직접 이해하고 관리하기 위해서입니다.

이는 제가 Glitter.kr 인프라를 운영하면서 유지하고 있는 기본적인 방향이기도 합니다.
 

그렇다면 일반 사이트 운영자는 무엇부터 확인해야 할까요?

모든 사이트 운영자가 자체 DNS와 메일 서버를 구축할 필요는 없습니다.

오히려 메일 서버를 직접 운영할 경험과 관리 여력이 부족하다면 안정적인 전문 서비스를 사용하는 것이 더 적절할 수 있습니다.

중요한 것은 자신이 사용하는 환경에서 어떤 보안 기능이 제공되고 실제로 적용되어 있는지 확인하는 것입니다.

우선 관리자 이메일 계정에 다중요소 인증(MFA)을 적용했는지 살펴보는 것이 좋습니다.
가능하다면 피싱에 강한 패스키나 보안키 기반 인증을 사용하는 편이 유리합니다.

사이트 관리자 이메일과 호스팅·도메인 관리 계정의 복구 수단이 어떻게 연결되어 있는지도 확인해야 합니다.

그리고 사용하는 도메인에 SPF, DKIM, DMARC가 적절하게 설정되어 있는지 확인할 필요가 있습니다.

메일 서비스를 직접 운영한다면
여기서 한 걸음 더 나아가 DNSSEC, DANE, MTA-STS, TLS-RPT의 적용 가능성과 운영 상태를 검토할 수 있습니다.

단, 보안 설정을 강화하는 과정에서 정상 메일이 차단되지 않도록 단계적으로 적용하고 결과를 확인해야 합니다.

특히 DMARC 정책을 강화하거나 DANE 관련 설정을 변경할 때는 실제 메일 전송 결과와 오류 로그를 함께 살펴보는 것이 중요합니다.
 

서버 패치와 이메일 보안은 별개의 문제가 아닙니다

최근 PHP 취약점과 관련해 우리가 확인한 것은 공격자가 취약점을 찾아내고 활용하는 속도가 빨라지고 있다는 사실입니다.

하지만 사이트를 공격하는 경로가 반드시 PHP나 Nginx의 취약점일 필요는 없습니다.

관리자에게 발송된 피싱 메일 한 통이 공격의 시작이 될 수도 있습니다.
탈취된 이메일 계정을 통해 비밀번호 재설정이 이루어질 수도 있고, 도메인을 사칭한 메일이 회원들에게 전달될 수도 있습니다.

서버의 보안 패치가 중요한 것처럼 이메일 계정과 발신 도메인, 메일 전달 경로의 보안도 중요합니다.

제가 직접 운영하는 Glitter.kr의 메일 인프라는 이러한 문제를 어떻게 다룰 수 있는지 보여주는 하나의 사례입니다.

이번에 실제 MX, DNSSEC, TLSA, SMTP 인증서를 검증하면서 다시 확인한 것은
보안 기능이 설정되어 있다는 사실과 실제로 정상 작동한다는 사실은 다르다는 점입니다.
이번에 제시한 검증 결과는 수신 SMTP의 DNSSEC 및 DANE 구성이 특정 외부 검증 환경에서 정상적으로 동작했음을 보여줍니다.
이는 전체 메일 인프라의 보안 수준을 포괄적으로 인증하는 결과와는 구별해야 합니다.
이 구성이 모든 사이트에 적합한 정답이라고 생각하지는 않습니다.

다만 메일 보안을 SPF나 DKIM 설정 정도로만 생각하기보다는,
DNS에서 시작해 메일 서버와 TLS 연결, 사용자 계정까지 이어지는 전체 신뢰 관계로 바라볼 필요가 있다고 생각합니다.

보안은 한 번 설정하고 끝나는 작업이 아닙니다.

PHP와 운영체제를 업데이트하는 것처럼 이메일 보안 정책도 지속적으로 확인하고 관리해야 합니다.

그누보드 사이트를 운영하시는 분들도 이번 기회에 관리자 이메일과 도메인 메일 보안 설정을 한 번쯤 점검해 보셨으면 합니다.

메일 서버를 운영하시거나 외부 메일 서비스를 사용하면서 겪으신 보안 설정 문제, 전달 실패 사례, 운영 경험 등의 공유는 필요하다 싶습니다.
 

---

참고 자료

Autonomous Security Infrastructure — 공식 백서 및 관련 자료
RFC 7208 — Sender Policy Framework (SPF)

RFC 6376 — DomainKeys Identified Mail (DKIM)

RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)

RFC 7672 — SMTP Security via Opportunistic DANE TLS

RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)

RFC 8460 — SMTP TLS Reporting (TLS-RPT)

Microsoft Learn — How SMTP DNS-based Authentication of Named Entities (DANE) secures email communications

Proton Mail — Security

mailbox.org — Email security