발신자 정책 프레임워크 또는 SPF 만으로는 기업 이메일을 피싱과 스팸으로부터 보호할 수 없습니다. 피싱 및 스팸 공격으로부터 기업 이메일을 보호하는 데는 충분하지 않습니다. SPF는 보내는 IP 주소가 도메인의 DNS 레코드에서 권한이 있는지 확인하여 스푸핑된 이메일로부터 이메일 수신자를 보호하는 이메일 인증 프로토콜입니다. 그러나 SPF의 최대 DNS 조회 수 제한과 발신 주소와 도메인의 정렬 불일치로 인해 구현 오류가 발생하여 이메일 전달률에 문제가 발생할 수 있습니다. DMARC는 SPF(및 DKIM)를 기반으로 구축되어 향상된 보안 및 보고 기능을 제공합니다. 이 블로그에서는 이러한 SPF 문제와 DMARC가 이러한 SPF 한계를 극복하는 데 어떻게 도움이 되는지에 대해 설명합니다.

주요 내용

SPF에는 조회 횟수 제한이 10회이므로 이를 초과하면 유효성 검사 실패(Permror) 및 배달 문제가 발생할 수 있습니다.
SPF는 보이는 발신자 주소가 아닌 반환 경로 도메인을 확인하므로 공격자가 발신자 신원을 스푸핑할 수 있습니다.
이메일이 전달될 때 전달 서버의 IP가 원래 발신자의 기록에 나열되지 않는 경우가 많기 때문에 SPF 인증이 실패할 수 있습니다.
DMARC는 발신자 주소와 인증된 도메인 간의 정렬을 강제하여 SPF 제한을 극복하고 이메일 채널에 대한 가시성을 위한 보고 기능을 제공합니다.
사용하지 않는 메커니즘을 제거하거나 SPF 플래트닝을 사용하여 SPF 레코드를 최적화하면 조회 제한을 유지하는 데 도움이 될 수 있습니다.

SPF 기록 제한은 어떻게 되나요?

구현 및 유지 관리가 다소 까다로운 3가지 주요 SPF 제한이 있습니다.

1. SPF 10 조회 한도

사용자가 DNS 서버를 쿼리할 때 대역폭, 시간, CPU, 메모리 등의 유효성 검사기 리소스가 사용됩니다. 유효성 검사기에 부하가 걸리지 않도록 10회의 추가 조회라는 SPF 제한이 있습니다. 그러나 SPF 정책 레코드 자체에 대한 DNS 쿼리는 이 제한에 포함되지 않습니다.

에 따라 RFC7208 섹션 4.6.4에 따라 수신자의 메일 서버는 10회 조회 제한에 도달하면 더 이상 처리하지 않아야 합니다. 이러한 경우 이메일은 Permerror 오류와 함께 SPF 유효성 검사를 거부합니다. SPF Permerror는 SPF 구현 프로세스에서 일반적으로 나타나는 메시지 중 하나입니다. 이메일 미전송의 원인이 되며 하나의 도메인에 여러 개의 SPF 레코드가 존재하거나 구문 오류가 발생하거나 SPF 레코드 한도를 초과하여 발생하는 경우 발생합니다. 이 한도를 초과하면 SPF 구현이 유효하지 않은 것으로 간주되고 이메일이 SPF에 실패하여 이메일 전송률이 저하될 수 있습니다.

무료로 제공되는 SPF 레코드 검사기 도구를 사용하여 이 오류를 제거하고 이메일 대화를 안전하게 보호할 수 있습니다.

또한 RFC에 따르면 호스트 이름에 대한 DNS 쿼리는 MX 레코드 의 DNS 쿼리는 10개 이상 생성되지 않아야 합니다. A 레코드 또는 AAAA 레코드를 생성해서는 안 됩니다. DNS PTR 쿼리에서 10개 이상의 결과를 생성하는 경우 처음 10개 결과만 표시되고 사용됩니다.

2. 사람이 읽을 수 있는 주소

두 번째 SPF 제한 사항은 수신자가 이메일 클라이언트에서 볼 수 있는 발신자 주소(헤더 발신자 또는 보낸 사람 주소)가 아닌 특정 반환 경로 도메인(봉투 발신자 또는 MFrom이라고도 함)에만 SPF 레코드가 적용된다는 것입니다. 수신자는 일반적으로 숨겨진 반환 경로 주소에는 크게 신경 쓰지 않고 이메일을 열 때 보이는 발신자 주소에만 집중합니다. 해커는 이 허점을 악용하여 반환 경로 주소에 가짜 도메인을 사용하고(SPF를 통과하는) 발신 주소를 합법적이거나 정상적으로 보이는 주소로 위조하여 피싱 공격을 시도합니다. 대부분의 사람들이 리턴 경로 주소를 인식하지 못하고 확인하지 않기 때문에 공격자는 이 수법을 통해 SPF 보호를 쉽게 우회할 수 있습니다.

3. 이메일 전달 문제

SPF에는 이메일 전달성을 저해할 수 있는 또 다른 중요한 실패 지점이 있습니다. 도메인에 SPF를 구현한 상태에서 누군가 이메일을 전달하면 SPF 정책으로 인해 전달된 이메일이 거부될 수 있습니다. 전달 과정에서 메시지를 보내는 서버(및 해당 IP 주소)는 변경되지만 원래 보낸 사람의 보낸 사람 주소는 동일하게 유지되는 경우가 많기 때문입니다. 수신 서버는 원래 발신자 주소를 보지만 *전달* 서버의 IP 주소를 원래 발신자의 SPF 레코드와 비교하여 확인합니다. 전달 서버의 IP 주소는 일반적으로 원래 발신자의 SPF 레코드에 포함되지 않으므로 확인에 실패하여 전달된 이메일이 거부되거나 스팸으로 표시될 수 있습니다.

PowerDMARC로 보안을 간소화하세요!

15일 평가판 시작 데모 예약하기

SPF 레코드 크기가 이메일 전송에 미치는 영향

수신자가 SPF 레코드 제한을 초과하면 SPF 확인에 실패하고 허용 오류가 발생합니다. DMARC 모니터링을 사용할 때 이 오류를 관찰할 수 있습니다. 수신자는 Permerror가 발생한 이메일을 처리하는 방법을 선택할 수 있습니다. 수신자는 해당 항목을 거부하도록 선택할 수 있으며, 이는 이메일이 반송됨을 의미합니다. 일부 수신자는 '중립' SPF 결과를 표시하도록 구성합니다(마치 SPF를 사용하지 않은 것처럼). 또한 '실패' 또는 '소프트 실패'를 선택할 수 있는데, 이는 SPF 인증 검사에 실패한 이메일이 거부되지 않고 스팸 폴더로 이동하는 것을 의미합니다.

이러한 결과는 DMARC, DKIM 및 스팸 등급 결과도 고려하여 결정됩니다. SPF 한도 초과 를 초과하면 이메일이 의도한 수신자의 기본 받은 편지함에 도착할 확률이 감소하여 이메일 전달률에 영향을 미칩니다.

유효성 검사기는 SPF 정책을 왼쪽에서 오른쪽으로 평가하고 발신자 IP 주소에서 일치하는 항목이 발견되면 프로세스가 중지됩니다. 이제 발신자에 따라 SPF 정책에서 완전히 평가하기 위해 10회 이상의 조회가 필요한 경우에도 유효성 검사기가 조회 제한에 도달하지 못할 수 있습니다. 이로 인해 SPF 레코드 제한과 관련된 이메일 전달성 문제를 식별하는 데 어려움이 발생합니다.

필수 조회 횟수를 줄이려면 어떻게 해야 하나요?

일부 도메인 소유자는 이메일 교환 습관이 2006년(RFC4408이 구현된 시점)과 크게 달라졌기 때문에 10회 조회라는 SPF 제한을 지키기가 어렵습니다. 이제 기업들은 하나의 도메인으로 여러 클라우드 기반 프로그램과 서비스를 사용합니다. 따라서 다음은 이러한 일반적인 SPF 제한을 극복할 수 있는 몇 가지 방법입니다.

사용하지 않는 서비스 제거

SF 기록을 평가하고 사용하지 않거나 불필요한 서비스가 있는지 확인하세요. '포함' 또는 더 이상 사용하지 않는 서비스 도메인을 표시하는 기타 메커니즘이 있는지 확인하세요.

기본 SPF 값 제거

기본 SPF 정책은 일반적으로 'v=spf1 a mx'. 대부분의 A 및 AAAA 레코드는 이메일을 보내지 않을 수 있는 웹 서버에 사용되므로 'a' 및 'mx' 메커니즘은 필요하지 않습니다.

사용하지 마십시오. ptr 메커니즘

이 ptr 메커니즘은 보안이 취약하고 신뢰할 수 없기 때문에 사용하지 않는 것이 좋습니다. 이 메커니즘은 더 많은 조회를 요구하여 SPF 제한 문제를 일으킵니다. 따라서 가능한 한 피해야 합니다.

사용하지 마십시오. mx 메커니즘

의 mx 메커니즘은 이메일을 수신하는 데 사용되며 반드시 이메일을 보내는 데는 사용되지 않습니다. 따라서 조회에 설정된 SPF 레코드 한도 내에서 이 메커니즘을 사용하지 않을 수 있습니다. 클라우드 기반 이메일 서비스 사용자라면 'include' 메커니즘을 사용하세요.

IPv6 또는 IPv4 사용

IPv4 및 IPv6는 추가 조회가 필요하지 않으므로 10회 이하의 조회라는 SPF 제한을 초과하지 않도록 도와줍니다. 하지만 이 두 메커니즘은 업데이트하지 않으면 오류가 발생하기 쉬우므로 정기적으로 업데이트하고 유지 관리해야 합니다.

SPF 기록 평탄화 고려

일부 리소스에서는 SPF 정책이 더 평평할수록(또는 더 짧을수록) 도메인 평판이 더 좋다고 주장합니다. 이들은 조회 시 설정된 SPF 레코드 한도 내에 머무르기 위해 이 방법을 제안합니다. 평탄화에는 '포함'과 같은 메커니즘을 실제 확인되는 IP 주소로 대체하여 유효성 검사 중에 필요한 DNS 조회 횟수를 직접 줄이는 것이 포함됩니다. 그러나 평탄화는 신중한 관리가 필요하며, 포함된 서비스 뒤에 있는 IP 주소가 변경되면 평탄화된 레코드가 오래되어 정상적인 이메일이 SPF 검사에 실패하는 것을 방지하기 위해 수동으로 업데이트해야 합니다. 자동 SPF 플래트닝 도구는 이 프로세스를 관리하는 데 도움이 될 수 있습니다.

SPF 한계를 극복하기 위한 DMARC의 역할

DMARC는 사람이 읽을 수 있는 발신자 필드 도메인과 SPF로 인증된 도메인(반환 경로 도메인) 간의 일치 또는 정렬을 요구하여 사람이 읽을 수 있는 발신자 주소의 SPF 제한을 해결합니다.

따라서 이메일이 SPF 검사를 통과했지만(즉, 발신 IP가 반환 경로 도메인에 대해 승인되었음을 의미) 반환 경로 도메인이 발신 주소 도메인과 동일하지 않은 경우 SPF에 대한 DMARC 정렬 에 실패합니다. 이메일이 전체적으로 DMARC를 통과하려면 SPF *와* 정렬 또는 DKIM *와* 정렬을 통과해야 합니다. 이렇게 하면 발신자 주소가 스푸핑되는 일반적인 피싱 수법을 방지하면서 반환 경로가 SPF를 통과하는 것을 방지할 수 있습니다. DMARC는 또한 보고 기능을 도입하여 도메인 소유자에게 인증 결과(SPF, DKIM, DMARC, 정렬) 및 발신 출처에 대한 정보를 포함하여 자신의 도메인에서 보낸 것으로 주장하는 이메일에 대한 피드백을 제공합니다. 이러한 가시성은 잘못된 구성, 전달 문제 및 악의적인 스푸핑 시도를 식별하는 데 도움이 됩니다.

SPF 레코드 평탄화가 10개의 DNS 조회 제한을 극복하는 데 도움이 되는 방법

SPF 레코드 평탄화 은 SPF(Sender Policy Framework) 레코드를 최적화하여 SPF에 대한 10개의 DNS 조회 제한을 극복하는 데 사용되는 기술입니다. 10개의 DNS 조회 제한은 많은 DNS 확인자가 적용하는 제한 사항으로, 도메인에 대한 SPF 레코드를 확인할 때 수행할 수 있는 DNS 쿼리 수를 제한합니다.

이메일이 수신되면 수신자의 메일 서버는 발신자 도메인의 DNS에서 발신자의 SPF 레코드를 쿼리하여 발신자가 해당 도메인에서 이메일을 보낼 권한이 있는지 확인합니다. SPF 레코드에는 DNS 조회가 필요한 "include", "a", "mx", "ptr"과 같은 메커니즘이 사용되는 경우가 많습니다. SPF 레코드에 이러한 메커니즘이 많이 포함되어 있는 경우, 특히 중첩 포함(포함된 도메인의 SPF 레코드에 포함도 포함된 경우)이 있는 경우 DNS 조회 제한 10개를 빠르게 초과하여 SPF 확인 실패(Permerror) 및 잠재적인 이메일 전송 문제로 이어질 수 있습니다.

이러한 한계를 극복하기 위해 SPF 레코드 플래트닝이 사용됩니다. SPF 레코드 평탄화는 SPF 레코드에서 조회를 유발하는 메커니즘(주로 'include'이지만 잠재적으로 'a' 및 'mx'도 포함)을 해당 IP 주소 또는 CIDR 범위로 대체하는 기술입니다. 이렇게 하면 추가 조회가 필요 없이 IP 주소가 직접 나열되므로 SPF 레코드를 확인하는 데 필요한 DNS 쿼리 횟수가 줄어듭니다.

SPF 레코드를 플랫화하면 SPF 레코드를 확인하는 데 필요한 DNS 쿼리 수가 크게 줄어들어 원래 레코드 구조에서는 10회 이상의 DNS 조회를 수행해야 하는 경우에도 이메일 메시지가 SPF 확인을 통과할 수 있습니다. 이 기술은 SPF 오류를 방지하고 DNS 쿼리 시간 초과 또는 일시적인 DNS 서버 문제로 인한 SPF 레코드 유효성 검사 실패의 위험을 줄이는 데 도움이 됩니다. 하지만 앞서 언급했듯이 플랫화 레코드는 기본 IP 주소가 변경될 때 정확성을 유지하기 위해 유지 관리가 필요합니다.

대기업에서 SPF를 구현할 때의 과제

SPF는 다음과 같은 공격을 방지하기 위해 조회 횟수를 10개 이하로 제한했습니다. DoS 및 DDoS 공격 을 방지하기 위해 10회 이하의 조회로 제한했습니다. 안타깝게도 이러한 조회는 특히 대기업에서 매우 빠르게 증가할 수 있습니다. 초기 기업들은 자체 메일 서버를 운영하는 경우가 많았지만 지금은 마케팅, 거래 이메일, CRM, 지원 시스템 등을 위해 수많은 타사 발신자에 크게 의존하고 있습니다. 각 타사 서비스는 종종 SPF 레코드에 '포함' 메커니즘을 요구하는데, 이는 하나의 조회로 간주되며 자체 SPF 레코드에 추가 조회가 포함될 수 있습니다. 이로 인해 여러 서비스를 추가하면 도메인이 빠르게 10회 조회 제한에 도달하거나 초과하여 위에서 설명한 허용 오류 문제가 발생할 수 있으므로 문제가 발생할 수 있습니다. 이렇게 수많은 소스를 관리하고 한도 내에서 모든 합법적인 메일이 승인되도록 하면서 한도를 유지하는 것은 매우 어려운 일입니다.