이메일 인증에서 SPF의 한계 이해하기

아호나 루드라

1 년 전

읽기 시간: 5 분

발신자 정책 프레임워크 또는 SPF 만으로는 기업 이메일을 다음과 같은 공격으로부터 보호할 수 없습니다. 피싱 및 스팸 공격으로부터 기업 이메일을 보호하는 데는 충분하지 않습니다. SPF의 최대 DNS 조회 수 제한과 발신자 주소 및 도메인의 정렬 불일치로 인해 구현 오류가 발생하여 이메일 전달성 문제가 발생합니다. 이 블로그에서는 이러한 문제와 DMARC가 이러한 SPF 제한을 극복하는 데 어떻게 도움이 되는지에 대해 설명합니다.

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

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

1. SPF 10 조회 한도

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

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

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

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

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

두 번째 SPF 제한 사항은 SPF 레코드가 보낸 사람 주소가 아닌 특정 반환 경로 도메인에 적용된다는 점입니다. 수신자는 일반적으로 반환 경로 주소에는 큰 관심을 기울이지 않고 이메일을 열 때 보낸 사람 주소에만 집중합니다. 해커는 이 허점을 이용하여 발신자 주소를 위조하여 피싱 공격을 시도합니다.

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 레코드 한도 내에 머무르기 위해 이 방법을 제안합니다. 그러나 평탄화하면 레코드에 오류가 발생하기 쉽고 정기적인 업데이트가 필요하므로 권장하지 않습니다.

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

DMARC는 사람이 읽을 수 있는 발신자 필드와 SPF로 인증된 서버 간의 일치 또는 정렬을 요구하여 사람이 읽을 수 있는 발신자 주소의 SPF 제한을 해결합니다.

따라서 이메일이 SPF 검사를 통과했지만 도메인이 발신자 주소와 동일하지 않은 경우 DMARC가 해당 인증을 무시합니다. 즉, 이메일이 인증 테스트에 실패한다는 의미입니다.

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

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

이메일이 수신되면 수신자의 메일 서버는 발신자 도메인의 DNS에서 발신자의 SPF 레코드를 쿼리하여 발신자가 해당 도메인에서 이메일을 보낼 수 있는 권한이 있는지 확인합니다. 그러나 SPF 레코드에 중첩된 포함 항목이 많으면 DNS 조회 제한인 10개를 빠르게 초과하여 SPF 확인 실패 및 오탐지 스팸 탐지로 이어질 수 있습니다.

이 제한을 극복하기 위해 SPF 레코드 평탄화가 사용됩니다. SPF 레코드 플래트닝은 SPF 레코드에 중첩된 모든 include 문을 해당 IP 주소 또는 CIDR 범위로 대체하는 기술입니다. 이렇게 하면 포함된 각 도메인을 더 이상 개별적으로 쿼리하지 않으므로 SPF 레코드를 확인하는 데 필요한 DNS 쿼리 횟수가 줄어듭니다.

SPF 레코드를 플랫화하면 SPF 레코드를 확인하는 데 필요한 DNS 쿼리 수가 크게 줄어들어 원본 레코드에 10회 이상의 DNS 조회가 있는 경우에도 이메일 메시지가 SPF 확인을 통과할 수 있습니다. 또한 이 기술은 DNS 쿼리 시간 초과 또는 일시적인 DNS 서버 문제로 인한 SPF 레코드 유효성 검사 실패의 위험도 줄여줍니다.

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

SPF는 다음과 같은 공격을 방지하기 위해 조회 횟수를 10회 이하로 제한했습니다. DoS 및 DDoS 공격. 안타깝게도 이러한 조회는 특히 대기업에서 매우 빠르게 증가할 수 있습니다. 이전 기업들은 자체 메일 서버를 운영했지만 지금은 타사 발신자를 사용합니다. 이 경우 각각 최대 3~4대의 서버를 사용할 수 있고 매우 빠르게 한계에 도달하기 때문에 문제가 발생합니다.