SPF -all과 ~all의 차이점
by
읽기 시간: 4 분
SPF all 메커니즘은 도메인의 DNS에 TXT 레코드로 존재하는 SPF 메커니즘으로, SPF 레코드의 오른쪽 끝에 "-" 또는 "~"가 앞에 위치합니다. SPF -all 메커니즘과 ~all 메커니즘의 차이점을 살펴보고 언제 구성해야 하는지 결정해 보겠습니다.
주요 내용
- SPF -all 및 ~all 메커니즘은 모두 SPF 인증에 대해 "통과하지 않음"을 나타내지만 일부 이메일 서비스에서는 다르게 처리될 수 있습니다.
- 기존에는 SPF 소프트폴(~모두)을 사용하면 인증에 실패하더라도 이메일을 전송할 수 있었지만 하드폴(-모두)을 사용하면 인증을 통과하지 못한 이메일이 거부되었습니다.
- 최신 이메일 서비스는 -모두 및 ~모두를 심각한 배달 실패 없이 처리하는 경우가 많지만, -모두를 사용하면 가끔 거부될 수 있습니다.
- 위험을 최소화하려면 처음에는 Softfail(~모두) 메커니즘을 사용하면서 DMARC를 구성하고 결과를 모니터링하는 것이 좋습니다.
- 적절한 SPF 구성과 함께 DMARC를 구현하면 인증되지 않은 이메일을 처리하는 방법을 정의하여 이메일 보안을 강화할 수 있습니다.
SPF -모두 대 ~모두
SPF -all 및 SPF ~all 메커니즘은 모두 SPF 인증에 대해 "통과하지 않음"을 의미합니다. 최근에는 대부분의 이메일 서비스 제공업체에서 -all 메커니즘과 ~all 메커니즘 간에 차이가 없으며 동일한 결과가 반환됩니다. 하지만 몇 년 전만 해도 그렇지 않았습니다.
DMARC 이전에는 SPF 모두(소프트패일 대 실패) 메커니즘이 어떻게 작동했나요?
DMARC는 SPF가 표준 이메일 인증 프로토콜로 시장에 출시된 지 오래 전에 만들어졌습니다. 당시 SPF의 소프트실패 메커니즘은 다음과 같은 방식으로 작동했습니다:
SPF 기록이 있다고 가정해 보겠습니다:
v=spf1 include:spf.domain.com ~all (여기서 ~all은 SPF 소프트패스를 의미함)
수신자의 이메일 서버는 발신자의 DNS에서 발신자의 SPF 레코드를 쿼리하기 위해 DNS 조회를 수행했을 것입니다. 이메일의 반환 경로 도메인이 발신자 레코드에 나열되어 있지 않은 경우 수신 서버는 SPF "통과하지 않음" 결과를 반환했을 것입니다. 이메일을 전달했을 것입니다. 이메일을 수신자의 받은 편지함으로 전달했을 것입니다.
이제 SPF 기록이 다음과 같다고 가정해 보겠습니다:
v=spf1 include:spf.domain.com -all (여기서 -all은 SPF 실패를 의미함)
수신자의 이메일 서버는 발신자의 DNS에서 발신자의 SPF 레코드를 쿼리하기 위해 DNS 조회를 수행했을 것입니다. 이메일의 반환 경로 도메인이 발신자 레코드에 나열되지 않은 경우 수신 서버는 SPF "통과하지 않음" 결과를 반환하지만, 이 경우 이메일은 다음과 같이 됩니다. 된 거부되어 전달되지 않음 수신자의 받은 편지함으로 전달되지 않습니다.
발신자 정책 프레임워크의 역사에 대해 자세히 알아보세요.
PowerDMARC로 SPF를 간소화하세요!
이메일 서비스 제공업체는 현재 SPF -all 대 ~all 메커니즘을 어떻게 처리하나요?
현재 대부분의 사서함 제공업체에서는 합법적인 이메일에 대해 배달 실패를 걱정할 필요 없이 SPF -all 또는 ~all을 자유롭게 사용할 수 있습니다, 모두 속성을 사용하는 경우 서버가 이메일을 거부하는 상황이 발생할 수 있습니다..
좀 더 안전한 편에 서기 위해 SPF 레코드를 생성하는 동안 SPF 하드 페일 올 메커니즘을 사용하지 않을 수 있습니다. 이렇게 하면 됩니다:
- PowerDMARC SPF 레코드 생성기 을 열어 무료로 레코드 생성을 시작하세요.
- IP 주소와 도메인을 포함하거나 이메일 발신자가 이메일을 확인하는 동안 이메일 서버가 얼마나 엄격해야 하는지 지정한 마지막 섹션까지 아래로 스크롤합니다.
- "SPF 레코드 생성" 버튼을 누르기 전에 "소프트-실패" 옵션을 선택하세요.
무엇을 추천하나요? SPF -all 또는 SPF ~all
SPF - 모든 메커니즘과 관련된 이메일 전달성 문제는 매우 드물게 발생할 수 있습니다. 이 문제는 자주 발생하는 반복적인 문제는 아닙니다. 이 문제가 발생하지 않도록 다음 단계를 수행하면 됩니다:
- 구성 DMARC 을 구성하고 DMARC 보고를 활성화하세요.
- DMARC 정책을 모니터링하도록 설정하고 SPF 인증 결과를 면밀히 검사하여 이메일 전송률의 불일치를 발견하세요.
- 모든 것이 정상이라면 SPF 레코드에서 -all 메커니즘을 사용할 수 있습니다. 하드 실패 속성은 이메일의 진위 여부를 확인하여 도메인의 평판을 높일 수 있으므로 이 속성을 사용하는 것이 좋습니다.
현재 SPF -all 사용 여부가 확실하지 않은 경우 다음 단계를 따르세요:
- 모두 메커니즘을 사용하여 SPF 레코드 설정하기
- 이메일에 DMARC를 구성하고 DMARC 보고를 사용 설정하세요.
- DMARC 정책을 거부하도록 설정
기타 SPF 오류 문제 해결
온라인 도구를 사용하는 동안 종종 "SPF 레코드를 찾을 수 없습니다." 프롬프트가 표시되는 경우가 있는데, 이는 서버가 도메인의 SPF 레코드를 조회할 때 반환되는 널 결과로 인해 발생하는 일반적인 오류 상태입니다. 이 문제에 대해 자세히 설명하고 사용자가 이 문제를 해결할 수 있도록 도와주는 도움말 문서를 작성했습니다. 자세한 내용을 보려면 링크된 텍스트를 클릭하세요!
도메인에 대해 SPF와 함께 DMARC를 설정한 경우 이메일 서버는 도메인의 DMARC 정책을 확인하여 인증에 실패한 이메일을 어떻게 처리할지 설정합니다. 이 DMARC 정책에 따라 이메일이 전달, 격리 또는 거부되는지 여부가 결정됩니다.
DMARC 거부는 스푸핑, 피싱, 랜섬웨어와 같은 다양한 사칭 공격으로부터 도메인을 보호하는 데 도움이 됩니다.
도메인 및 이메일 보안 전문가 PowerDMARC
Yunes는 이메일 인증 및 보안에 대한 전문 지식을 갖춘 PowerDMARC의 운영 팀장입니다. Yunes는 CompTIA A+ 등의 자격증을 보유한 Microsoft 인증 Azure 관리자 어소시에이트입니다.
Yunes Tarada의 최신 글 (전체 보기)
- 이메일 솔팅 공격: 숨겨진 텍스트가 보안을 우회하는 방법 - 2025년 2월 26일
- SPF 평탄화: 평탄화란 무엇이며 왜 필요한가요? - 2025년 2월 26일
- DMARC와 DKIM: 주요 차이점 및 함께 작동하는 방법 - 2025년 2월 16일
