1. 실행 환경

• 하드웨어: 라즈베리파이 3
• OS: 라즈비안 8 제시

2. SPF 는 무엇인가요?

SPF는 Sender Policy Framework의 약자로, 메일서버 정보를 사전에 DNS에 공개 등록함으로써 수신자로 하여금 이메일에 표시된 발송자 정보가 실제 메일서버의 정보와 일치하는지를 확인할 수 있도록 하는 인증기술 입니다. SPF 기술이 보편적으로 도입되기 전에는, 예를 들어 도메인의 소유자가 아닌 제 3자가 자신의 정보를 숨기기 위해, "[email protected]"을 "보낸 사람"으로 하여 스팸 메일을 발송하는 등의 일이 많았습니다. 이를 Email Spoofing (메일 스푸핑) 이라고 합니다. SPF는 도메인 소유자가 설정한 정보를 토대로, 설정된 SMTP 서버에서 발송된 메일에만 SPF=PASS를 기록하게 하여 스푸핑된 메일이 아니라는 헤더를 만듭니다.

3. SPF 적용하는 방법

SPF의 적용은 매우 간단합니다. 발송하는 메일의 도메인에, SPF의 문법을 포함한 TXT 레코드를 입력하여 주시면 됩니다. SPF 문법은 SMTP 서버 보유량, 도메인 관계 등에 따라 여러가지를 설정할 수 있지만, 우선 실제 예제를 보며 SMTP 서버를 인증하는 방법을 알아보겠습니다. 예제는 gmail.com의 레코드를 보며 설명 하겠습니다. SPF 레코드를 처음 보는 사람은 조금 복잡하게 느껴지실 수 있지만, 이는 실제 업무 환경에서의 적응에도 매우 좋은 사례라 판단되므로 일부러 gmail.com을 선택하였습니다. 먼저, dns 레코드 조회를 위해 DiG 를 사용합니다.

dig -v 

위의 명령어로 DiG 버전이 나오지 않는다면, DiG를 설치해 줍니다.

sudo apt install dig -y 

설치가 되면, gmail.com의 SPF 레코드를 조회해 보도록 하겠습니다.

dig gmail.com TXT 

아래와 같은 결과가 나옵니다. gmail.com. 299 IN TXT "v=spf1 redirect=_spf.google.com" 이를 해석해보자면,

• Host: gmail.com: @gmail.com으로 발송된 이메일에 대해
• v=spf1: SPF버전 1을 사용하며
• redirect=_spf.google.com: _spf 레코드를 _spf.google.com으로 redirect 하여 찾는다.

라는 의미입니다. gmail.com 자체의 SPF 레코드는, 특정 서버를 기술하지 않고 SPF Redirect를 사용하고 있습니다. 왜 그럴까요? 도메인의 TXT 레코드는 255자의 레코드 값 길이 제한이 있습니다. 만약, 적은 수의 SMTP 서버를 가지고 있다면 255자 안에서 설정을 끝낼 수 있지만, SMTP 서버로 사용중인 IP 주소만 수백, 수천개가 있다면, 255자 이내에 모든 서버를 적용할 수 없습니다. 그렇게 때문에, SPF 레코드를 2, 3단계 체인처럼 만들어 실제 적용되는 SMTP 서버의 주소를 찾아야 합니다. 조금 더 진행해 보겠습니다. 위에서 gmail.com 으로 발송되는 이메일에 대한 SPF 레코드는 _spf.google.com에서 찾도록 설정 되어 있으므로, 다음은 이를 조회해 보도록 하겠습니다.

dig _spf.google.com TXT 

이번에는 아래와 같은 결과가 나왔습니다. _spf.google.com. 277 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all" 이를 해석해보자면,

• Host: _spf.google.com: 앞서 @gmail.com 에서 Redirect 되어 spf 값을 여기서 찾습니다.
• v=spf1: SPF버전 1을 사용하며
• include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com: _netblocks.google.com, _netblocks2.google.com, _netblocks3.google.com 도메인의 SPF 레코드를 포함하고
• ~all: 앞의 레코드에 포함되지 않은 곳에서 발송된 메일에 대해서는 Softfail을 적용한다.

include는 @gmail.com을 사용하여 보내는 SMTP 서버가 사용하는 실제 도메인 명을 포함한다는 의미입니다. include는, 자신의 SMTP 서버가 아닌, 외부 SMTP 서버를 이용하는 경우, 발신인을 자신의 도메인으로 하여도 위에서 설명한 "메일 스푸핑 처리하지 않겠다는 의미"입니다. 기업 환경에서, 대량 메일 발송을 위한 전문 업체, 혹은 서버 호스팅 업체의 SMTP 시스템을 사용하는 경우 등등에 많이 사용됩니다. ~all은 ~와 all을 나누어서 봅니다. all은 특정 도메인 혹은 IP 주소를 서술한 후, 주로 가장 마지막에 적게되는데, 이는 서술된(SPF를 통과하는) 도메인 및 IP주소를 제외한 "나머지 모든 곳에서 발송된 @gmail.com을 발신자로 하는 이메일" 이라는 의미입니다. ~은, "all"에 대해 Softfail을 선언한다는 의미입니다. 아래에 설명되어 있지만, include 및 all은 메커니즘의 한 종류이며, ~은 수식자의 한 종류입니다. Softfail은, "메일 수신자 측 SMTP 서버에 해당 메일에 대한 처리를 맡기겠다" 라는 의미입니다. 다시 진행해 보자면, include로 등록된 3개의 도메인 중, _netblocks.google.com의 SPF 레코드를 보겠습니다.

dig _netblocks.google.com TXT 

이번에는 아래와 같은 결과가 나왔습니다. _netblocks.google.com. 3599 IN TXT "v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all" 드디어 실제 IP 주소들이 나왔습니다. SPF 레코드의 제일 앞의 IP 블럭 1개만 해석해 보자면,

• host: _netblocks.google.com 앞에서 @gmail.com 에서 Redirect 된 _spf.google.com 에 SPF 인증 된 도메인
• v=spf1: 역시 SPF버전 1을 사용하며
• ip4:64.18.0.0/20: IPv4 64.18.0.1 - 64.18.15.254 의 범위에 해당하는 SMTP 서버로 부터의 이메일은 허용
• ~all: 앞의 레코드에 포함되지 않은 곳에서 발송된 메일에 대해서는 Softfail을 적용한다.

첫 번째 _netblocks.google.com은 "서술된 IP 주소들을 SMTP 서버로 포함하여 사용중이겠구나" 하고 추측할 수 있습니다. 참고로, 두 번째 블럭도 검색해 보니, 여기에는 IPv6 주소들만 포함되어 있었습니다.

dig _netblocks2.google.com TXT 

세 번째 블럭은, 172.217.0.0/19 만 포함하고 있네요.

dig _netblocks3.google.com TXT 

gmail은 이처럼 SMTP 서버가 많기 때문에, 복잡한 체인 형태를 가지고 있습니다. + 보너스 + 자신의 도메인으로 메일을 발송하는 서버가 없는 경우, 메일 스푸핑 방지를 위해 어떻게 하면 좋을까요? example.com의 TXT 레코드를 봅시다.

dig example.com TXT 

example.com에 대한 TXT 레코드에 "v=spf1 -all" 가 있습니다. 허용하는 주소가 아무것도 없고, -all (-는 Hardfail 이라는 의미)로, 전 세계 어디에서 보낸 메일이든, @example.com을 발신인으로 사용 시 SPF=FAIL 헤더를 추가하게 됩니다. 물론 수신하는 측에서 SPF 필터를 사용하지 않는 다면 의미가 없겠지만요..  

자신도 모르는 사이에 누군가가 자신의 도메인 명으로 메일 스푸핑을 하여, 다른 SMTP 서버에서 영구블럭 당하기 전에 SPF 레코드를 추가해 보시는건 어떨까요? :)