최근 구글에서 메일 정책이 변경이 되었는지 기업 메일을 사용하는 업체들 측에서 Gmail(구글 메일)로 메일을 발송하면 실패하는 경우가 많이 발생하여 확인해보니 SPF값 관련 내용이 많았습니다. Naver(네이버)의 경우도 SPF값을 등록하지 않는 도메인 메일에 대해서는 차단하는 경우가 많아 문의가 많아졌습니다. 꼭 대형 포털사이트가 아니더라도 수신 측 서버가 SPF정책을 사용하면 아래와 같은 비슷한 리턴 메시지를 받을 수 있습니다.
□ 리턴 메시지
구글 참고 사이트 : https://support.google.com/mail/answer/81126#authentication
| 메시지 내용 | 뜻(번역) |
| 550-5.7.26 This message does not have authentication information or fails to 550-5.7.26 pass authentication checks (SPF or DKIM). To best protect our users 550-5.7.26 from spam, the message has been blocked. (Gmail) | 550-5.7.26 이 메시지에는 인증 정보가 없거나 550-5.7.26 인증 검사(SPF 또는 DKIM)를 통과하지 못했습니다. 스팸으로부터 사용자 550-5.7.26을 가장 잘 보호하기 위해 메시지가 차단되었습니다. |
| 550-5.7.26 This message fails to pass SPF checks for an SPF record with a hard 550-5.7.26 fail policy (-all). To best protect our users from spam and 550-5.7.26 phishing, the message has been blocked. (Gmail) | 550-5.7.26 이 메시지는 하드 550-5.7.26 실패 정책(-all)이 있는 SPF 레코드에 대한 SPF 검사를 통과하지 못합니다. 스팸 및 550-5.7.26 피싱으로부터 사용자를 가장 잘 보호하기 위해 메시지가 차단되었습니다. |
| 550 5.7.1 Sender rejected because SPF check failed (Naver) |
SPF 확인에 실패하여 발신자가 거부됨 |
| 553 refused, SPF check softfail (타업체 예시) |
SPF 확인에 실패하여 발신자가 거부됨 |
▶ 구글 및 네이버의 SPF정책에 의해 차단되어 오는 리턴 메시지입니다. 즉 발송자의 메일 주소 도메인 네임서버에 SPF값이 등록되어 있지 않거나, 잘못 등록되어 있다는 뜻이기도 합니다. 이것을 설명하기 위해서는 SPF(메일서버 등록제)의 기능을 먼저 이해를 할 필요가 있습니다.
◆ 메일서버등록제(SPF : Sender Policy Framework)란?
메일서버 정보를 사전에 DNS에 공개 등록함으로써 수신자로 하여금 이메일에 표시된 발송자 정보가 실제 메일서버의 정보와 일치하는지를 확인할 수 있도록 하는 인증기술, 대다수 스팸 발송자가 자신의 신원을 감추기 위하여 발송자 주소나 전송경로를 허위로 표기하거나 변경하는 경우가 많다는데 착안
→ SPF를 이용한 이메일 인증절차 (발신자, 수신자가 동시에 조건이 만족해야 합니다.)
| 발신자 | 자신의 메일서버 정보와 정책을 나타내는 SPF 레코드를 해당 DNS에 등록 |
| 수신자 | 이메일 수신시 발송자의 DNS에 등록된 SPF 레코드를 확인하여 해당 이메일에 표시된 발송 IP와 대조하고 그 결과값에 따라 수신 여부를 결정 (메일서버나 스팸차단 솔루션에 SPF 확인 기능이 설치되어 있어야 함) |
→ SPF 값 예시 : "v=spf1 ip4:192.168.0.1 ~all"
이용하고 있는 메일서버의 최종 발송 서버의 IP가 SPF값의 ip4:192.168.0.1와 일치해야 수신측에서 인증하고 수신을 받는다는 뜻입니다.
원문 메시지[예시]
◇ DNS관리에서 SPF(TXT) 설정 예시
◇ SPF(TXT) 값이 메일 발송 서버의 IP와 일치하지 않을 경 우 거부
◇ SPF(TXT) 값이 메일 발송 서버의 IP와 일치하지 않았지만 통과 후에 수신자가 메일을 받았을 시
◇ 해결 방법 → SPF값 등록 방법
당연히 SPF값을 제대로 등록을 하면 되겠지만 어떻게 등록을 해야 할지가 문제 일 겁니다.
메일 호스팅 업체를 이용하고 있다면 설정 방법을 따라가면 되시며 클라우드나 단독형 단일 서버로 사용하시면 최종 발송 서버의 IP를 SPF(TXT) 값에 등록하시면 됩니다.
※ 주의 - 혼동하기 쉬운 부분으로 SPF값은 일종의 메일 인증 기술 이름으로 실제 등록은 TXT레코드에 등록을 합니다
예시① 메일서버가 클라우드 서버(가상화) 또는 물리 서버로, 독립형 서버로 사용할 경 우
◇ 메일서버 IP가 [ 192.168.0.1 ]라고 가정
| 타입 | 호스트 | 값/위치 | TTL |
| TXT | @ (자기자신) | "v=spf1 ip4:192.168.0.1 -all" | 600 (기본값) |
예시② 메일 발송 서버가 2대 이상 일 경우
◇ 메일서버 1번 서버 IP가 [ 192.168.0.1 ]라고 가정
◇ 메일서버 2번 서버 IP가 [ 192.168.10.10 ]라고 가정
| 타입 | 호스트 | 값/위치 | TTL |
| TXT | @ (자기자신) | "v=spf1 ip4:192.168.0.1 -all" | 600 (기본값) |
| TXT | @ (자기자신) | "v=spf1 ip4:192.168.10.10 -all" | 600 (기본값) |
각각 등록해야 하는 게 아닐까 하지만 권고 사항은 TXT레코드 하나의 값에 전부 포함시켜야 합니다.
| 타입 | 호스트 | 값/위치 | TTL |
| TXT | @ (자기자신) | "v=spf1 ip4:192.168.0.1 ip4:192.168.10.10 -all" | 600 (기본값) |
예시③ 메일 발송 서버가 다 수일 경우 인클루드[include] 형태를 이용
◇ 메일서버 C클래스 대역대 IP가 [ 192.168.1.0/24 ]라고 가정
◇ 메일서버 C클래스 대역대 IP가 [ 192.168.10.0/24 ]라고 가정
| 타입 | 호스트 | 값/위치 | TTL |
| TXT | _spf.foxydog.co.kr | "v=spf1 ip4:192.168.1.0/24 ip4:192.168.10.0/24 -all" | 600 (기본값) |
별도의 인클루드 할 TXT값을 생성을 하고 아래와 같이 include를 이용하여 등록을 한다.
| 타입 | 호스트 | 값/위치 | TTL |
| TXT | @ (자기자신) | "v=spf1 include:_spf.foxydog.co.kr -all" | 600 (기본값) |
"v=spf1 ip4:192.168.1.1 ip4:192.168.1.2 ip4:192.168.1.3 ip4:192.168.1.4 ........ -all" IP하나하나 입력하면 값/위치가 너무 길어지므로 include를 이용하는 부분
예시④ IP와 Include혼합 형태
| 타입 | 호스트 | 값/위치 | TTL |
| TXT | @ (자기자신) | "v=spf1 include:_spf.foxydog.co.kr ip4:192.168.0.1 -all" | 600 (기본값) |
예시⑤ 만약 메일서버가 릴레이를 이용할 경우(스팸 서버를 사용)
◇ 메일서버 IP가 [ 192.168.0.1 ]라고 가정
◇ [ 192.168.0.1 ] 발송하면 스팸 서버로 전달(릴레이) [ 192.168.0.10 ]을 통해 최종 발송
즉, 어떤 서버로 릴레이를 하든 최종적으로 발송 시도가 되는 IP를 입력해야 한다는 뜻입니다.
| 타입 | 호스트 | 값/위치 | TTL |
| TXT | @ (자기자신) | "v=spf1 ip4:192.168.0.10 -all" | 600 (기본값) |
예시⑥ 레코드 A, MX값에 발송 서버가 포함되어 있을 경우
| 타입 | 호스트 | 값/위치 | TTL |
| TXT | @ (자기자신) | "v=spf1 a mx -all" | 600 (기본값) |
예시⑦ ~all와 -all의 차이
| "v=spf1 ip4:192.168.0.10 ~all" | 메일발송IP를 위조하여 보내온 메일은 수신자의 메일서버의 정책에 따라 판단하라 (선택적 - SoftFail) |
| "v=spf1 ip4:192.168.0.10 -all" | 메일발송IP를 위조하여 보내온 메일은 수신자의 메일서버에서 DROP시켜라 (무조건 - Fail) |
※ 이전에는 선택적으로(~all) 주로 사용했지만, 이제 보안에서 무조건(-all)으로 사용하라는 정책이 내려오고 있습니다. 참고하시기 바랍니다.
◇ SPF등록 확인 방법
| 리눅스 & 유닉스 | # nslookup -q=txt 발송도메인 # dig -t txt 발송도메인 |
| 윈도우(CMD) | # nslookup -q=txt 발송도메인 |
아래는 윈도우(CMD) 명령어로 TXT 등록값 확인 테스트
마치며
SPF(TXT) 레코드 등록은 이제 필수가 되었습니다. 이것만 등록하더라도 발송 업체의 경우는 메일 실패 확률을 줄일 수 있으며, 수신받는 메일 업체의 경우는 비정상적인 스팸 메일을 약 1/3 정도는 줄일 수 있습니다. 물론 스패머들이 작정하고 SPF까지 등록을 한다면 MAIL FROM 헤더를 변조하여 보내도 통과되는 한계가 있습니다. 그래서 DKIM(DomainKeys Identified Mail)과 DMARC(Domain-based Message Authentication, Reporting and Conformance) 메일 인증 정책을 같이 사용합니다. 이 부분에 대해서는 기회가 되면 다루도록 하겠습니다.
'◈『Mail』 > 리턴메일 분석' 카테고리의 다른 글
| 리턴 메시지 : DNS resolving error (0) | 2023.02.13 |
|---|---|
| 리턴 메시지 : Client host [IP] blocked using spamlist.or.kr (0) | 2023.02.04 |
| 리턴 메시지 : Client host [IP] blocked using bl.spamcop.net (0) | 2021.06.11 |
| 리턴 메시지 : 554 5.7.1 DAS41 [IP] ADDRESS: Your mail is blocked automatically by anti-spam system. (E04) (0) | 2021.06.04 |
| 리턴 메시지 : message size exceeds limit (0) | 2021.06.01 |