구축한 메일 서비스에서 메일을 성공적으로 발송하기 위한 방법 6선
직접 메일 서비스를 구축하여 메일을 발송하는 사람, 여기 붙어라.
때는 바야흐로 2020년, 직접 구축한 메일 서비스에서 발송한 메일들이 일부 메일 수신 서버에서 성공적으로 수신되지 않는 경우가 발생하였다.
정확히는 국내 대형 포털 사이트 (Naver, Daum 등) 의 메일 수신 서버에서 메일을 수신 거부하는 경우가 발생하였다.
Naver, Daum 은 메일을 수신할 때 Spamhaus 에서 스팸으로 등록되지 않은 발송지에 대해서 수신 처리를 하도록 되어있다. 스팸 지수를 높이는 다양한 사유들이 있지만 그 중에서 기본적으로 지켜져야 하는, 메일 수신 성공률을 높이는 몇 가지 설정들에 대해서 알아보려고 한다.
* Spamhaus: 메일 스팸 활동 추적을 위한 국제 조직. 주요 포털 사이트 등에서 Spamhaus 의 Block List 를 참조하여 메일 수신 차단 처리를 수행한다.요약/결론
아래 설정들은 메일 수신 서버에서 메일의 유효성을 검증할 수 있도록 하여, 수신을 허용하거나 스팸으로 분류되지 않도록 한다. 아래 설정들이 잘 되어있지 않다면 메일은 수신 서버에서 차단될 수 있다.
- SPF
- Reverse DNS
- DKIM
- DMARC
- White Domain 등록
- MX 레코드 등록
* 설명 내 IP, 도메인 예시는 실제로 Elastic Cloud 팀으로부터 받은 메일 정보를 활용하였습니다.
SPF
SPF (Sender Policy Framework) 는 메일 서버 등록제로, 발송자가 메일 서버 정보 (발신지 IP) 를 사전에 DNS 에 공개하고, 수신측에서는 전달 받은 메일 정보와 공개된 메일 서버 정보의 일치 여부를 확인할 수 있도록 한다.
해커가 나의 메일 도메인 (예: @example.com) 을 발송자로 지정하여 메일을 발송한다면 어떨까? SPF 가 지정되어있지 않다면 나의 메일 발송 서버 (예: IP>1.1.1.1) 와는 다른 메일 서버 (예: IP>2.2.2.2) 로부터 메일이 와도 비정상적인 메일인지 모를 것이다.
SPF 는 다음과 같이 조회할 수 있다.
(DNS 레코드 타입 중 TXT 형태로 등록된다.)
## nslookup
nslookup -type=txt mktg.elastic.co## dig
dig mktg.elastic.co TXT## Result (by nslookup)
Server: 10.0.0.2
Address: 10.0.0.2#53Non-authoritative answer:
mktg.elastic.co text = "v=spf1 include:mktomail.com ~all"Authoritative answers can be found from:
SPF 레코드는 DNS 관리자가 직접 등록하면 되는데 아래와 같은 형식을 따른다.
example.com TXT "v=spf1 ip4:1.1.1.1 include:mail.example.com ~all"- 도메인 등록 타입은 TXT 이다.
- 도메인 값은 “v=spf1 ip4:<메일 발송 서버 IP> include:<메일 발송 서버 도메인> ~all” 등의 형태를 따른다.
- v=spf1: spf 버전
- ip4: ipv4 에 해당하는 메일 발송 서버 IP 지정
- include: 메일 발송 서버 도메인 지정
> 단, KISA White Domain 등록 시 <ip4:ip> 형태만을 규정하고 있다.
> 국내 환경이라면 ipv4 등록을 권장한다.
- ~all: 메일 처리 방법 지정 (Enforcement Rule)
- ~all: SPF 인증이 비정상적일 경우 해당 메일은 수신 메일 서버 정책에 따라 처리
- -all: SPF 인증이 비정상적일 경우 수신 메일 서버에서 DROP 처리
결론적으로 메일 수신 서버에서는, 발송자의 메일 도메인 (예: @example.com) 을 이용하여 조회한 발송 서버 IP (SPF 레코드 조회) 와 실제 발송 서버 IP (메일 헤더 내 포함) 를 비교하여 정상적인 메일인지 검증한다.
Ref
https://spam.kisa.or.kr/white/sub1_2.do
https://docs.microsoft.com/ko-kr/microsoft-365/security/office-365-security/how-office-365-uses-spf-to-prevent-spoofing?view=o365-worldwide
Reverse DNS
Reverse DNS 는 말 그대로 IP 를 사용하여 연결된 도메인을 확인하는 기술 (IP, 도메인 간 1:1 매핑) 이다. 보통 도메인을 조회하여 IP 를 얻는데 Reverse DNS 는 반대이다.
메일 수신 서버에서 메일을 수신하면 원본 데이터에는 발송 서버에 대한 여러가지 정보들이 있는데, 메일 발송 서버 대표 도메인, 발송지 IP 등 도 포함된다.
메일 수신 서버에서 발송지 IP 로 Reverse DNS 를 조회하였을 때, 메일 발송 서버의 대표 도메인이 나오는지 확인하는 것이다.
(보통 해외 메일 수신 서버에서 많이 활용된다고 하나 Naver 등 국내 포털 업체에서도 활용하는 것으로 보인다.)
IP 로 Reverse DNS 조회 방법은 다음과 같다. (nslookup, dig)
## nslookup
nslookup -type=ptr 185.28.196.143## dig
dig -x 185.28.196.143## Result (by nslookup)
Server: 10.0.0.2
Address: 10.0.0.2#53Non-authoritative answer:
143.196.28.185.in-addr.arpa name = mktg.elastic.co.Authoritative answers can be found from:
IP “185.28.196.143” 로 Reverse DNS 조회 시 메일 발송 서버 대표 도메인인 “mktg.elastic.co” 가 조회되었다. 전달받은 메일 발송 서버 대표 도메인과 Reverse DNS 로 조회되는 도메인이 일치한다면 정상적인 발송지로 인식될 수 있다.
Reverse DNS 등록 요청 방법
Reverse DNS 는 DNS 관리자가 레코드를 등록하는 것 만으로 사용할 수 있는 것은 아니고, IP 를 발급하는 업체 (ISP) 에 등록 문의를 해야 한다. 보통은 자체 레코드 등록 + ISP 기관에서의 등록이 필요하다.
일반 등록 요청 방법 (비 AWS)
- 메일 발송 서버 대표 도메인에 대한 A Type 레코드 등록
- mktg.elastic.co A 185.28.196.143 - Reverse DNS 를 위한 Hosted Zone (DNS Zone File) 생성
- 메일 발송 서버 IP 가 “185.28.196.143” 인 경우
- “143.196.28.185.in-addr.arpa” Hosted Zone 생성 - PTR 레코드 등록
- 143.196.28.185.in-addr.arpa PTR mktg.elastic.co - 해당 Hosted Zone 의 NS 값을 ISP 업체에게 전달
- ISP 업체에서 “143.196.28.185.in-addr.arpa” 조회시 우리가 만든 Hosted Zone 을 활용할 수 있도록 설정
AWS 활용 시 등록 요청 방법
- 메일 발송 서버 대표 도메인에 대한 A Type 레코드 등록
- mktg.elastic.co A 185.28.196.143 - 요청서 작성
- https://console.aws.amazon.com/support/contacts?#/rdns-limits - 요청서를 작성하면 AWS 측에서 자체적으로 PTR 레코드를 등록해준다.
Ref
https://aws.amazon.com/premiumsupport/knowledge-center/route-53-reverse-dns/?nc1=h_ls
DKIM
DKIM (Domain Keys Identified Mail) 은 메일 수신 서버에서 수신된 메일이 위변조되지 않았는지 디지털 서명 (Digital Signature) 을 이용하여 유효성을 검증하는 기술이다.
* Digital Signature: 발송자가 private-key 로 암호화한 메시지를 수신자가 public-key 로 해독하는 과정메일 수신 서버에서 메일 수신 시 보통 SPF, DKIM, DMARC 의 유효성 여부를 검사하는데, 수신측에서 각 항목들에 대해 조건이 만족되지 않으면 메일을 차단할 수 있다.
아래는 Gmail 을 통해 Elastic Cloud 팀으로부터 받은 메일의 원본 메일 내용이다. 기본 메일 정보들과 SPF, DKIM, DMARC 인증 여부를 확인할 수 있다.
DKIM 을 메일 서비스에서 활용하기 위해 아래와 같은 절차가 필요하다.
- 메일 서비스 내 DKIM 설정 (예시👇)
> 보통 메일 서비스 내에 DKIM 활용할 수 있도록 설정 항목 제공
- DKIM Domain: example.com
- DKIM Selector: selector1
- private-key 경로 지정
- … - DNS 관리자가 DKIM 레코드 등록
> 메일 수신 서버에서 해당 DNS 레코드 내 public-key 를 조회하여 유효성 검증
- “<selector>._domainkey.<domain>” 형태의 TXT 레코드 등록
- 예시: selector1._domainkey.example.com TXT “v=DKIM1\;k=rsa\;p=MIGfMA0GCS…dfasdfdsafl”
> v: DKIM 레코드 버전
> k: DKIM 유효성 검사시 활용하는 알고리즘
> p: public-key (Base64 인코딩)
DKIM 이 적용된 상태에서 메일을 발송하면, 메일 수신 서버측에서는 메일 헤더 내 “DKIM-Signature” 헤더를 참조하여 DKIM 유효성 검증을 수행한다.
“DKIM-Signature” 내에는 DKIM 레코드 값, 서명 알고리즘, private-key 로 암호화된 내용 등이 포함된다.
- a: 서명 알고리즘
- s: selector 값 (구분자)
- d: DKIM 레코드 (TXT). 해당 레코드를 조회하여 public-key 를 얻는다.
- h: 서명할 항목 (예: From:To:Subject:MIME-Version:Content-Type)
- b: 서명된 항목 (Base64 인코딩)
Ref
DMARC
DMARC (Domain-based Message Authentication, Reporting and Conformance) 는 SPF, DKIM 과 함께 동작하여 메일 발신자를 인증한다.
관련 내용/등록 방법은 추후에 소개한다.
White Domain 등록
White Domain 등록제는 한국인터넷진흥원 (KISA) 에서 제공하는 일종의 메일 전송 보장 제도이다.
KISA 에서는 국내외로부터 메일 스팸 정보를 실시간으로 취합/분석하여 1시간 단위로 차단 IP 목록 (KISA-RBL) 을 제공한다.
각 주요 포털 사이트의 메일 수신 서버에서는 일일이 위험한 IP 목록을 관리하기는 어려우므로, KISA 에서 제공하는 KISA-RBL (Real-time Blocking List) 을 참조하여 위험 IP 로 등록된 발신지를 차단하는 방식이다.
개인 혹은 사업자가 정상적으로 발송되길 원하는 메일 도메인에 대해서 White Domain 등록을 한다면 KISA-RBL 에서 제외되어 안전한 메일 발송을 보장한다. (국내 주요 포털 사이트 Naver, Daum, … 은 대부분 KISA-RBL 을 활용한다.)
White Domain 등록은 KISA 홈페이지에서 수행할 수 있다.
(아래 내용은 해당 도메인에 대해 SPF 레코드가 이미 등록되어있는 경우에 한한다.)
- KISA White Domain 등록 신청 페이지 접속
- 도메인 란에 메일 발송시 사용할 도메인을 입력한다.
- 예: 발송자가 “id@example.com” 인 경우 “example.com”
2. SPF 도메인이 사전에 잘 등록되어있다면 아래 화면에서 업체 및 담당자 정보 등을 넣고 신청한다. 사업자 등록증 또한 필요하다.
3. 등록 신청이 완료되면 약 1-2주간 스팸 이력을 확인하여 문제가 없다면 최종 등록 된다.
4. White Domain 등록 여부는 KISA White Domain 등록 확인/수정 페이지에서 확인할 수 있다.
- 현재 해당 도메인의 도메인 신뢰도 또한 확인할 수 있다.
Ref
MX 레코드 등록 (발송자 메일 도메인 관점)
MX 레코드는 다른 설정들과는 다르게 본래 용도는 메일 수신지 (회신지) 를 지정하기 위함이다.
받는이 (수신자) “<id>@example.com” 으로 메일을 발송한다고 했을 때, 메일이 전달되어야 할 목적지는 어디인가? 바로 example.com 의 MX 레코드 값이 바로 그 목적지이다.
## example.com 에 대한 MX 레코드 현황
example.com MX 10 server1.mail.com
example.com MX 20 server2.mail.comserver1.mail.com A 1.1.1.1
server2.mail.com A 1.1.1.2
MX 레코드는 도메인 1개에 우선순위 (숫자가 낮을 수록 우선순위가 높다.) 를 지정하여 여러 목적지를 지정할 수 있다. 단, 설정되는 목적지는 도메인 (Not an IP) 이어야 하며 설정되는 각 도메인은 A Type 의 IP 를 가리키고 있어야 한다. 그렇지 않고 도메인을 값으로 가지는 CNAME 일 경우 일부 MTA (Mail Transfer Agent) 에서 수신 경로를 찾지 못 할 수 도 있다.
그런데, 이것이 메일 수신 성공/실패와 무슨 관계이냐?!
일부 (사설) 메일 수신 서버에서 발송자 (예: id@sender.com) 의 메일 도메인 (sender.com) 에 대해 MX 레코드를 확인하지 못할 경우 수신 불가 처리할 수 있다.
실제로도 별도로 구축한 메일 서비스에서 MX 레코드가 등록되지 않은 발송자 메일로 발송하였을 때 사설 메일 수신 서버에서 수신 불가 처리를 한 경우가 있다. MX 레코드를 등록하였더니 정상적으로 수신 가능 하였다.
