발신자 정책 프레임워크(SPF)는 스팸을 줄이고 발신 출처를 인증하기 위해 조직에서 수년간 이메일 시스템에서 사용해 온 이메일 인증 프로토콜 중 하나입니다. 그러나 SPF 실패로 이어지는 다양한 오류가 발생하는 경우가 많습니다. 이 글에서는 SPF가 실패하는 원인과 이를 해결하는 방법에 대해 설명합니다.
다음은 SPF 실패로 이어지는 몇 가지 일반적인 이유입니다:
- SPF 레코드 구문 오류
- SPF 레코드 구성 오류
- SPF에 대한 DNS 조회 제한 초과
- 이메일 전달
- 불완전한 전송 소스 권한 부여
주요 내용
- SPF 오류는 잘못된 구문, DNS 조회 한도 초과, 동일한 도메인에 대한 여러 SPF 레코드 등의 문제로 인해 발생할 수 있습니다.
- SPF 메커니즘은 합격, 불합격, 소프트패일, 중립, 일시적 오류 등 다양한 결과를 반환할 수 있으며, 각각 다른 수준의 인증 성공을 나타냅니다.
- SPF 구현의 무효화를 방지하려면 "포함" 메커니즘을 사용하여 여러 SPF 레코드를 하나의 레코드로 결합하는 것이 필수적입니다.
- DMARC 보고서를 정기적으로 모니터링하면 SPF 장애의 원인을 파악하고 적시에 문제를 해결하는 데 도움이 됩니다.
- SPF 모범 사례를 구현하는 것은 이메일 전달성을 보호하고 인증 실패 가능성을 줄이는 데 매우 중요합니다.
SPF 실패는 왜 발생하나요?
SPF 실패는 다음과 같은 이유로 발생할 수 있습니다:
- 수신 MTA가 DNS에 게시된 SPF 레코드를 찾지 못했습니다.
- 동일한 도메인에 대해 둘 이상의 SPF 레코드를 구성했습니다.
- 이메일 서비스 제공업체에서 SPF 레코드에 포함하지 않은 새 IP 주소를 수정하거나 추가했습니다.
- SPF에 대한 DNS 조회 제한 10개를 초과했습니다.
- 허용된 최대 무효 조회 횟수 제한인 2회를 초과하고 있습니다.
- 평평한 SPF 레코드 길이가 255자 제한을 초과합니다.
이메일에서 SPF가 실패하면 다음 단계는 그 원인을 파악하여 문제를 해결하는 것입니다. 이는 DMARC 보고서를 정기적으로 모니터링하면 가능합니다. PowerDMARC를 사용하면 SPF 인증 실패에 대한 보고서를 쉽게 읽을 수 있습니다. DMARC 분석기.
PowerDMARC로 SPF 장애를 막으세요!
SPF 실패의 유형
다음은 다음과 같은 유형입니다. SPF 실패 한정자의 유형이며, 각 한정자는 SPF 메커니즘 앞에 접두사로 추가됩니다:
"+" "합격"
"-" "실패"
"~" "소프트실패"
"?" "중립"
이것이 어떻게 중요할까요? W이메일이 거부되는 상황에서는, 수신자가 얼마나 엄격하게 처리할지 선택할 수 있습니다. SPF를 받은 메시지를 '통과'하도록 한정자를 지정할 수 있습니다. 메시지를 "통과"하도록 지정하거나 배달을 "실패"하거나 "중립"(아무것도 하지 않음) 입장을 취할 수 있습니다.
1. SPF 없음 결과 반환됨
첫 번째 시나리오에서는 수신 이메일 서버가 DNS 조회를 수행하여 DNS에서 도메인 이름을 찾을 수 없는 경우 없음 결과가 반환됩니다. 발신자의 DNS에서 SPF 레코드가 발견되지 않는 경우에도 없음이 반환되며, 이는 발신자가 이 도메인에 대해 SPF 인증을 구성하지 않았음을 의미합니다. 이 경우 이메일에 대한 SPF 인증이 실패하며 "-all"로 표시됩니다.
지금 바로 오류 없는 SPF 레코드를 생성하세요. 무료 SPF 레코드 생성기 도구를 사용하여 오류를 방지하세요.
2. SPF 중립 결과 반환
도메인에 대한 SPF를 구성하는 동안 SPF 레코드에 "?all" 메커니즘을 추가한 경우 아웃바운드 이메일에 대한 SPF 인증 검사 결과와 상관없이 수신 MTA가 중립 결과를 반환합니다. 이는 SPF를 중립 모드로 설정하면 사용자를 대신하여 이메일을 보낼 수 있는 권한이 있는 IP 주소를 지정하지 않고 권한이 없는 IP 주소도 이메일을 보낼 수 있도록 허용하기 때문에 발생합니다.
3. SPF 소프트패일 결과 반환
SPF 중립과 마찬가지로 SPF 소프트패일은 ~모든 메커니즘에 의해 식별되며, 이는 수신 MTA가 메일을 수락하여 수신자의 받은 편지함으로 전달하지만 DNS에서 찾은 SPF 레코드에 IP 주소가 나열되어 있지 않은 경우 스팸으로 표시되어 이메일에 대한 SPF 인증이 실패하는 원인이 될 수 있음을 의미합니다. 아래는 SPF 소프트 실패의 예입니다:
v=spf1 include:spf.google.com ~all
4. SPF 하드패일 결과 반환
SPF 하드 페일은 수신 MTA가 SPF 레코드에 나열되지 않은 발신 소스에서 발신한 이메일을 삭제하는 것을 말합니다. 도메인 사칭 및 이메일 스푸핑으로부터 보호하려면 SPF 레코드에 SPF 하드 페일을 구성하는 것이 좋습니다.
예: v=spf1 include:spf.google.com -all
구체적인 차이점 알아보기 SPF 소프트 페일과 하드 페일
5. SPF 템퍼러(SPF 일시적 오류)
SPF 인증이 실패하는 일반적인 이유 중 하나는 SPF 템퍼러(일시적 오류)입니다. 이는 다음과 같은 DNS 오류로 인해 발생합니다. DNS 시간 초과. 따라서 이름에서 알 수 있듯이 4xx 상태 코드를 반환하는 임시 오류로, 일시적인 SPF 실패를 일으킬 수 있습니다. 나중에 다시 시도하면 SPF 통과 결과가 표시됩니다.
6. 6. SPF 영구 오류(SPF 영구 오류)
도메인이 직면하는 또 다른 일반적인 오류는 SPF 허용 오류입니다. 이는 영구적인 오류로 실패하는 경우입니다. 이는 수신 MTA에 의해 SPF 레코드가 무효화될 때 발생합니다. DNS 조회를 수행하는 동안 MTA에 의해 SPF가 중단되어 무효화되는 데는 여러 가지 이유가 있습니다:
- SPF 조회 한도 10회 초과
- 잘못된 SPF 레코드 구문
- 동일한 도메인에 대해 둘 이상의 SPF 레코드가 있습니다.
- SPF 레코드 길이 제한인 255자 초과
- ESP가 변경한 내용으로 SPF 레코드가 최신 상태가 아닌 경우
참고: MTA가 SPF 확인 를 수행할 때는 DNS를 쿼리하거나 DNS 조회를 수행하여 이메일 출처의 신뢰성을 확인합니다. 이상적으로는 SPF에서 최대 10개의 DNS 조회가 허용되며, 이를 초과하면 SPF가 중단되고 허용 오류 결과가 반환됩니다. 이는 SPF 실패로 이어지는 매우 일반적인 문제입니다.
이메일의 SPF 실패를 해결하는 방법
원활한 이메일 전달을 위해서는 이메일에 SPF가 실패하지 않도록 하는 것이 중요합니다. SPF 실패를 해결하려면 다음 모범 사례를 따르세요:
1. SPF 한도 이내로 유지
RFC에서 지정한 한도를 초과하는 DNS 조회로 인해 인증이 실패하는 경우, 실패를 방지하기 위해 한도 내에서 유지하세요. PowerDMARC는 매크로를 통해 고객이 SPF 레코드를 최적화하여 이러한 엄격한 제한을 유지하도록 도와줍니다. 매크로는 종종 다음과 같은 것보다 몇 배 더 효과적입니다. SPF 평탄화. 그러나 SPF 평탄화를 사용하기로 선택한 경우, SPF 평탄화 도구 를 사용하면 프로세스를 간소화할 수 있지만 이메일 서비스 제공업체가 인프라를 수정할 때마다 여전히 수동 업데이트가 필요합니다. SPF DNS 레코드에 매크로를 사용하면 항상 DNS 무효화 및 조회 제한을 초과하지 않도록 할 수 있습니다.
2. 구문 및 구성 오류 방지
SPF 레코드를 수동으로 구현하면 구문 오류가 발생하여 실패하는 경우가 많습니다. SPF에 올바른 구문을 사용하고 있는지 확인하려면 자동화된 SPF 레코드 생성기 도구를 사용하여 레코드를 생성하세요.
DNS에서 SPF를 구성할 때는 항상 리소스 유형 "TXT"를 사용하세요. "CNAME" 또는 "SPF"와 같은 잘못된 리소스 유형을 구성하면 구성 오류 및 SPF 실패로 이어질 수 있습니다.
3. 모든 전송 소스 승인
타사 공급업체를 포함한 모든 발신 소스를 SPF 레코드에서 적절하게 승인하고 있는지 확인하세요. 공급업체는 종종 전송 IP 목록을 변경하거나 추가합니다. 이러한 변경 사항을 파악하고 자체 SPF 레코드에 구현해야 합니다. 승인된 발신 소스를 누락하면 종종 부당한 SPF 실패로 이어집니다.
4. 여러 SPF 레코드 결합
동일한 도메인에 대해 두 개 이상의 SPF 레코드가 있으면 SPF 구현이 무효화되어 SPF 실패로 이어질 수 있습니다. 이러한 경우 "포함" 메커니즘을 사용하여 여러 레코드를 단일 레코드로 결합하는 것이 좋습니다.
SPF 모범 사례
도메인 소유자가 위에서 언급한 SPF 모범 사례를 준수하면 부당한 SPF 실패 가능성을 크게 줄일 수 있습니다. 다음은 기업이 이메일 보안을 더욱 강화하기 위해 일반적으로 실행할 수 있는 몇 가지 추가 모범 사례입니다:
- DKIM을 사용하여 전달된 이메일에 대한 SPF 실패 방지
- DMARC와 DKIM을 사용하여 SPF가 실패하고 DKIM이 통과하더라도 DMARC는 통과합니다.
- DMARC 보고를 활성화하여 SPF 실패 및 원인 모니터링
이메일 인증 실패는 도메인의 평판과 신뢰도에 결코 좋은 소식이 아닙니다. 배달 가능성에 영향을 미치지 않도록 하려면 지금 바로 조치를 취하여 SPF 실패를 방지해야 합니다. 도메인에 SPF가 올바르게 구성되어 있는지 테스트하고 싶으신가요? 무료 SPF 검사기 도구를 지금 바로 사용해보세요!
- DMARC 레코드를 생성하고 게시하는 방법 - 2025년 3월 3일
- 2025년에 "SPF 기록을 찾을 수 없음"을 수정하는 방법 - 2025년 1월 21일
- DMARC 보고서 읽는 방법 - 2025년 1월 19일