SPF 사용 도메인의 소유자는 인증 결과를 모니터링하기 위해 Gmail을 사용하는 경우가 많습니다. SPF 레코드에 오류가 없고 올바른 구성으로 설정되었는지 확인하기 위해 인증 결과를 모니터링합니다. Gmail은 이메일 전송 도메인에 대해 게시된 SPF 레코드를 찾을 수 없는 경우 SPF 추정 상태를 반환하는 경우가 많습니다.
이 가이드에서는 Gmail이 언제, 왜 '베스트 추측' 결과라고 알려주는지에 대해 설명합니다.
주요 내용
- Gmail의 '최선의 추측' 상태는 이메일 전송 도메인에 대해 게시된 명확한 SPF 레코드가 없음을 나타냅니다.
- 이메일 인증과 전달률 향상을 위해서는 적절한 SPF 레코드 설정이 필수적입니다.
- 기존 SPF 레코드를 정기적으로 확인하여 모든 합법적인 메일 서버를 포함하는지 확인하는 것이 중요합니다.
- 메일 서버를 효과적으로 인증하려면 특정 구문을 사용하여 SPF 레코드의 형식을 올바르게 지정해야 합니다.
- 이메일 보안을 강화하고 스푸핑 공격을 방지하려면 DKIM 및 DMARC로 SPF를 보완해야 합니다.
Gmail은 언제 SPF '최적' 상태를 반환하나요?
발신자의 도메인에 DNS 설정에 명확한 SPF 레코드가 게시되어 있지 않은 경우 Gmail은 SPF "추정" 상태를 반환할 수 있습니다. 이러한 경우 Gmail은 과거 이메일 데이터 및 발신자 행동을 기반으로 SPF 정책에 대해 교육적인 추측을 시도합니다. 이 '추정' 상태는 잘 정의된 SPF 레코드만큼 신뢰할 수 있는 것은 아니지만, Gmail에서 일정 수준의 이메일 인증을 제공할 수 있습니다.
PowerDMARC로 보안을 간소화하세요!
Gmail '베스트 추측' 결과 예시
수신됨-SPF: 통과(google.com: [email protected] 도메인에 대한 베스트 추측 레코드가 12.43.77.991을 허용된 발신자로 지정함)
이 예는 Gmail이 도메인.com에 대해 DNS에 게시된 공식 SPF 레코드를 찾을 수 없음을 나타냅니다.
Gmail이 가짜!
Gmail이 '최선의 추측'이라고 말하는 것은 해당 도메인에 대한 관찰을 기반으로 도메인에 대한 비공식 SPF 레코드를 만들었다는 의미입니다. 실제로 이러한 SPF 레코드는 DNS에 게시되지 않으며, Gmail에서는 단순히 추측 추측할 뿐입니다. 확실하지 않으므로 도메인 소유자의 재량에 맡겨야 합니다.
Google이 도메인의 SPF 레코드를 합성할 때 어떤 요소를 고려하는지는 확실하지 않지만 Gmail의 문제 해결 가이드에 따르면 그 이유는 다음과 같을 수 있습니다:
- 누락된 SPF 레코드 또는 설정
- 유효하지 않거나 잘못된 SPF 구성
- DNS 관련 문제 또는 중단
사용자 측에서 해결할 수 있나요?
도메인 소유자로서 SPF "최선 추측" 상태를 해결하고 이메일 전달 가능성을 개선하려면 도메인의 DNS 설정에서 유효한 SPF 레코드를 설정해야 합니다. 다음은 이를 수행하는 방법에 대한 몇 가지 제안 사항입니다:
SPF 기록 이해
SPF(Sender Policy Framework) 레코드는 도메인을 대신하여 이메일을 보낼 권한이 있는 메일 서버를 지정하는 DNS TXT 레코드입니다. 스패머가 도메인을 사용하여 이메일을 위조하는 것을 방지합니다. SPF 레코드는 메일 서버의 IP 주소 또는 도메인 이름을 포함하는 특정 형식으로 정의됩니다.
기존 SPF 기록 확인
변경하기 전에 도메인에 대한 기존 SPF 레코드가 이미 있는지 확인하세요. 온라인 SPF 레코드 검사기 또는 DNS 조회 도구를 사용하여 이 작업을 수행할 수 있습니다. 기존 SPF 레코드를 찾으면 해당 레코드를 평가하여 도메인에서 이메일을 보내는 데 사용되는 모든 합법적인 메일 서버가 포함되어 있는지 확인합니다.
새 SPF 레코드 생성
SPF 레코드가 없거나 기존 레코드가 불완전하거나 잘못된 경우 새 레코드를 만들어야 합니다. 관련 정보가 포함된 DNS TXT 레 코드로 SPF 레코드를 만들 수 있습니다.
메일 서버 결정
도메인을 대신하여 이메일을 보낼 수 있는 권한이 있는 메일 서버를 식별합니다. 여기에는 일반적으로 자체 메일 서버와 도메인에서 이메일을 보내는 데 사용하는 타사 이메일 서비스 공급업체가 포함됩니다.
SPF 레코드 포맷
SPF 레코드는 특정 구문으로 작성됩니다. "v=spf1" 태그와 도메인에 대해 이메일을 보낼 수 있는 서버를 정의하는 메커니즘으로 구성됩니다. 몇 가지 일반적인 메커니즘에는 "a"(도메인의 A 레코드용), "mx"(도메인의 MX 레코드용), "include"(다른 도메인의 SPF 레코드 포함용), "ip4" 또는 "ip6"(특정 IP 주소용) 등이 있습니다.
예를 들어 도메인의 MX 서버와 하나의 특정 IP 주소로 이메일을 보낼 수 있도록 허용하는 간단한 SPF 레코드는 다음과 같습니다:
v=spf1 mx ip4:192.0.2.10 -all
"베스트 추측" 사용 금지
Gmail 및 기타 이메일 제공업체가 SPF 정책에 대해 '최선의 추측'을 하지 못하도록 하려면 SPF 레코드가 완전하고 정확한지 확인하세요. 소프트 실패 "~"가 있는 "모두" 메커니즘을 사용하거나 메커니즘이 없는 경우 허용적인 SPF 정책으로 이어질 수 있으므로 사용하지 마세요. 대신 SPF 레코드 끝에 하드 실패 "-all"을 사용하여 다른 모든 서버를 허용되지 않은 것으로 간주하도록 지정하세요.
SPF 레코드 게시
SPF 레코드를 생성한 후에는 도메인의 DNS 설정에서 DNS TXT 레코드로 추가합니다. 이 작업은 일반적으로 도메인 등록기관의 제어판 또는 DNS 관리 인터페이스를 통해 수행할 수 있습니다. DNS 변경 사항이 인터넷을 통해 전파되려면 시간이 다소 걸릴 수 있습니다.
SPF 기록 테스트
SPF 레코드를 게시한 후에는 무료로 제공되는 SPF 레코드 검사기 를 사용하여 올바른지 확인하세요. 이 단계는 SPF 레코드가 제대로 설정되었는지 확인하는 데 도움이 되며 이메일 스푸핑을 방지하는 데 효과적입니다.
마지막으로 Google은 도메인 호스팅 제공업체에 연락하여 SPF 최적 추측 상태를 유발할 수 있는 DNS 문제를 해결할 것을 권장합니다.
SPF는 자급자족이 아닙니다.
SPF에는 몇 가지 단점이 있습니다(예 조회 제한, 이메일 전달 시 SPF 손상, SPF 레코드 정보 유지 및 업데이트 문제 등)이 있는데, 이러한 단점은 다음과 같이 SPF 구현을 보완함으로써 극복할 수 있습니다. DKIM 및 DMARC. 이러한 이메일 보안 프로토콜은 권한이 없는 발신자가 내 도메인에서 메시지를 보내는 위험을 줄여 잠재적인 피싱 및 스푸핑 공격을 방지합니다.
PowerDMARC는 다양한 비즈니스 요구사항과 운영 매개변수에 맞는 다양한 DMARC 서비스를 제공합니다. DMARC와 관련된 문의 사항이 있으시면 언제든지 문의해 주세요!
- 이메일 솔팅 공격: 숨겨진 텍스트가 보안을 우회하는 방법 - 2025년 2월 26일
- SPF 평탄화: 평탄화란 무엇이며 왜 필요한가요? - 2025년 2월 26일
- DMARC와 DKIM: 주요 차이점 및 함께 작동하는 방법 - 2025년 2월 16일