점점 스팸 메일이 다양한 방식으로 사용자를 속이기 위해 다양한 기술과 전략을 이용하여 진화하고 있습니다. 이에 따른 구글이 스팸 메일을 효과적으로 막기 위해 「SPF, DKIM, DMARC, PTR, SMTP(TLS)」등의 메일 정책을 2024년 2월부터 일부 사용하지 않을 경우 대부분 차단하는 강제 정책을 펼칠 것으로 보입니다. 특히 대량 메일 솔루션을 이용하여 Gmail 쪽으로 하루에 5000개 이상의 메일을 전송하기 위해서는 이제 선택이 아닌 필수가 되었습니다.
◇ 구글 G메일 공식 가이드 : https://support.google.com/a/answer/81126?hl=ko#zippy=
① SPF 정책
이전 GMAIL 리턴 메시지 참고 : https://foxydog.tistory.com/110
메일서버등록제「SPF:Sender Policy Framework」는 간단하게 얘기하면 사용자 도메인 네임서버「DNS」 관리에 최종 발송 서버 IP를 사전 공개 등록함으로써 수신자로 하여금 이메일에 표시된 발송자 정보가 실제 메일서버의 정보와 일치하는지를 확인할 수 있도록 하는 인증 기술입니다.
리턴 메시지 패턴「1-1」
550-5.7.26 This mail has been blocked because the sender is unauthenticated. 550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM. 550-5.7.26 550-5.7.26 Authentication results: 550-5.7.26 DKIM = did not pass 550-5.7.26 SPF [발송도메인] with ip: [발송서버 IP] = did not pass 550-5.7.26 550-5.7.26 For instructions on setting up authentication, go to 550 5.7.26 https://support.google.com/mail/answer/81126#authentication
DNS에 TXT 「SPF」 레코드를 등록하지 않고 메일을 발송하면 가장 흔하게 발생하는 패턴이며, 최근에는 대부분의 포털 메일 사이트는 해당 정책을 최소한으로 기본 적용하고 있습니다.
SPF는 레코드 「TXT」 타입으로 등록하며 「v=spf1 ip4:xxx.xxx.xxx.xxx ~all」 또는 발송 서버가 여러 대가 있다면 인클루드 「v=spf1 include:foxyspf.testmail.com ~all」의 형태로 들어갑니다. 단독형 메일 서버일 경우는 단일 IP로, 호스팅 또는 클라우드 서비스 이용 시에는 안내에 따라 등록하시면 됩니다.
정상 수신이 되고 수신받은 원문 메일 보기를 확인 시 헤더에 SPF 「PASS」가 확인되면 본인의 발송 서버의 IP가 DNS TXT「SPF」 값과 일치한다는 것을 검증받았다는 뜻입니다.
리턴 메시지 패턴「1-2」
host gmail-smtp-in.l.google.com[수신IP] said: 550-5.7.1 [발송 IP] The IP you're using to send mail is not authorized to 550-5.7.1 send email directly to our servers. Please use the SMTP relay at your 550-5.7.1 service provider instead. For more information, go to 550 5.7.1 https://support.google.com/mail/?p=NotAuthorizedError
필자는 테스트 서버가 「SPF/DKIM/DMARC」 모두 정상 적용이 되어 있었음에도 해당 리턴 메시지를 받았는데 리턴 내용 중 "이메일을 당사 서버로 직접 보낼 수 있는 권한이 없습니다."라는 것을 보고 SPF의 「~」 「-」 정책을 의심했었습니다. 그리고 예상대로 처음에 「-」로 설정을 했다가 「~」로 DNS에서 수정을 했더니 정상 발송이 되었습니다.
| "v=spf1 ip4:192.168.0.10 ~all" | 메일발송IP를 위조하여 보내온 메일은 수신자의 메일서버의 정책에 따라 판단하라 (선택적 - SoftFail) |
| "v=spf1 ip4:192.168.0.10 -all" | 메일발송IP를 위조하여 보내온 메일은 수신자의 메일서버에서 DROP시켜라 (무조건 - Fail) |
※ 이전에는 선택적으로(~all) 주로 사용했지만, 이제 보안에서 무조건(-all)으로 사용하라는 정책이 내려오고 있습니다. 참고하시기 바랍니다.
라고 알고 있었습니다만, 추측으로 제가 클라우드 테스트서버라 사설 IP로 세팅이 되어 있으며, NAT를 통해 공인 IP로 나가다 보니 이 과정에서 네트워크 주소 IP가 바뀌는 것을 인지하는 것으로 보입니다. 공인 IP로 바로 나간다면 「-all」 세팅, 혹시나 저처럼 네트워크 주소 IP가 바뀌는 환경이라면 「~all」으로 변경하여 발송 시도를 합니다.
② DKIM, DMARC 정책
DKIM Postfix 참고 : https://foxydog.tistory.com/112
DKIM「DomainKeys Identified Mail」은 피싱 및 스팸메일(이메일 스푸핑)에서 위조된 발신자 주소를 검사하기 위해 [무결성 검증] 개발된 이메일 인증 방법 중 하나입니다. DKIM을 사용하면 수신자가 특정 도메인에서 온 이메일이 해당 도메인 소유자가 실제로 발송 승인을 했는지 확인할 수 있습니다. DKIM 설치를 진행하다 보면 헤더에 직접 디지털 서명(공개키)을 추가하는 것을 말합니다. 수신자는 네임서버(DNS)에 게시된 보낸 사람의 공개 키를 조회하여 일치하는지를 확인합니다.
DMARC Postfix 참고 : https://foxydog.tistory.com/113
DMARC「Domain-based Message Authentication, Reporting and Conformance」은 이메일 도메인 소유자가 이메일 스푸핑으로 알려진 무단 사용에서 도메인을 보호할 수 있도록 하는 이메일 인증 프로토콜입니다. DMARC의 목적은 비즈니스 이메일 공격, 피싱 이메일 사이버 위협 행위에 도메인이 이용되지 않도록 보호하는 역할을 합니다.
해당 정책을 같이 설명하는 이유는 DKIM이나 DMARC만 단일로 사용하는 경우는 없으며, 대부분 「SPF」를 기본 베이스로 정책을 확장하여 같이 사용합니다. 예시로 다음과 같습니다.
| SPF만 사용 「최소」 | SPF+DKIM 사용 「권장」 |
| SPF+DMARC 사용 | SPF+DKIM+DMARC 사용 「베스트」 |
| DKIM만 사용 「X」 | DMARC만 사용 「X」 |
적용 후 GMail에서 수신된 원본 헤더를 확인해보면 DKIM+DMARC가 PASS가 떨어진다면 정상적으로 정책이 적용되어 있다는 의미입니다.
③ PTR 정책
「PTR (Pointer)」 records, 도메인 질의 시 IP로 변환해 주는 게 아닌 반대로 IP질의 시 도메인 정보를 확인하는 정책으로 주로 메일인증기술에 많이 쓰입니다. 예를 들어 수신 측(스팸차단) 메일서버에서 발송서버의 IP를 조
회하여 도메인이 등록된 PTR레코드 값과 일치하면 정상메일로 판단하여 수신하겠다는 역방향 질의 방식입니다. 다른 말로 리버스 도메인「Reverse Domain」이라고도 합니다.
◇ 일반 질의 「mail.foxytest.com ▶ 192.168.1.100」
◇ PTR 질의 「192.168.1.100 ▶ mail.foxytest.com」
리턴 메시지 패턴「1-1」
550-5.7.25 [발송 IP] The IP address sending this message does not have a 550-5.7.25 PTR record setup, or the corresponding forward DNS entry does not 550-5.7.25 point to the sending IP. As a policy, Gmail does not accept messages 550-5.7.25 from IPs with missing PTR records. For more information, go to 550 5.7.25
PTR등록은 네임서버를 제공하는 업체가 아닌 그 해당 IP를 관리하는 ISP인터넷공급「KT, LG U+, SKT」등의 업체에 등록을 해야 합니다. 아래는 KT에서 제공하는 리버스 도메인 등록 서비스 예시 페이지입니다.
그 외 ISP업체는 사업 관리자나 별도의 양식을 통해 메일 접수로만 처리해 주는 곳도 있으니 참고하시기 바랍니다.
④ 이메일 전송 TLS 연결 사용 정책
◇ 구글 이메일 암호화 보고서 참고 : https://transparencyreport.google.com/safer-email/overview
아직도 다수의 이메일 제공업체에서 SMTP 메일 전송 시 메시지를 암호화를 하지 않고 있어, 이러한 업체를 통해 이메일을 보내거나 수신하는 경우 메시지가 우편엽서처럼 스누퍼에게 노출이 될 수 있습니다. 「TLS(전송 계층 보안)」라고 하는 보안 프로토콜을 사용하여 전송 시 이메일을 암호화하면 전송되는 이메일을 다른 사람이 쉽게 읽을 수 없습니다. TLS 버전은 「최소 1.2 이상」 권장되고 있습니다.
◇ G메일 수신에서 TLS 통신 확인
Received: 부분에서 「Version=TLS1_2, TLS1_3」 이상 표시가 되고 있으면 안전하게 암호화하여 전송을 수신받았다는 뜻입니다.
◇ 발송서버에서 TLS 통신 적용 확인「Postfix」 예시
TLS 통신을 하고 있는 수신 측으로 발송 시 메일로그에서 「STARTTLS」 메시지를 확인
[root@]# tail -f maillog
Apr 06 14:34:39 mail postfix/submission/smtpd[139252]: disconnect from localhost[::1] ehlo=2 starttls=1 auth=1 mail=1 rcpt=2 data=1 quit=1 commands=9
[root@]# telnet localhost 25 or 587
발송 포트 테스트로 「250-STARTTLS」 응답 확인
그 외에도 여러 가지가 있지만 메일 서버에 가장 영향력 있는 「SPF, DKIM, DMARC, PTR, SMTP(TLS)」 정책에 대하여 간단하게 알아보았습니다. 테스트 과정 중에 확인된 부분은 아직까지는 무조건 하나라도 적용이 안되어 있으면 발송이 안 되는 게 아닌 상황에 따라 유동적으로 대처를 하는 것으로 보입니다.
예로 「PTR」이 등록되어 메일 서버 도메인 신원이 확실하게 인증이 된다면 TXT는 「SPF」만 등록되어 있어도 수신 허용을 하고 있습니다. 반대로 TXT 「SPF+DKIM+DMARC」가 올바르게 다 등록되고 발송 IP가 동일하게 처리가 되고 있다면 「PTR」 등록이 되어 있지 않아도 수신을 허용하는 것으로 보입니다. GMAIL 쪽으로 하루에 5000개 이상의 대량메일을 발송하기 위한 요청이며, 이하로만 발송한다면 둘 중에 하나의 패턴만으로 이용해도 문제는 없다고 판단됩니다.
TLS(전송 계층 보안)은 아직까지 전국적으로 선택적 통신으로 이루어지고 있지만, 조금이라도 안전하게 메일을 사용하기 위해서는 권장하고 있습니다. 언젠가 스팸 메일이 근절되기를 바라며...
'◈『Mail』 > 리턴메일 분석' 카테고리의 다른 글
| 리턴 메일(메시지) : Not complied TLS minimum version (0) | 2024.07.28 |
|---|---|
| 리턴 메일(메시지) : MTA's poor reputation [feat. Spamhaus] (0) | 2024.07.01 |
| 리턴 메시지 : Recipient address rejected: Greylisted (그레이리스트) (0) | 2023.10.26 |
| 리턴 메시지 : 451 4.7.500 Server busy. Please try again later from ip (S77719) (0) | 2023.10.20 |
| 리턴 메시지 : DNS resolving error (0) | 2023.02.13 |