"SPF 소프트패일 도메인이 IP를 허용된 발신자로 지정하지 않습니다"를 해결하는 방법은 무엇인가요?
by
읽기 시간: 5 분
회사에서 자체 도메인과 도메인 처리 메일을 사용하는 경우 이메일 문제가 발생할 가능성이 높으며, 'SPF 소프트패일 도메인이 IP를 허용된 발신자로 지정하지 않음' 오류가 발생할 수 있습니다. 기업이 대신 이메일을 발송하는 데 사용되는 IP 주소를 SPF 레코드에서 허용된 발신자로 올바르게 지정하는 것이 중요합니다.
SPF란 무엇인가요?
SPF(Sender Policy Framework)는 사칭으로부터 조직을 보호하는 이메일 인증 표준입니다. 공격자는 회사의 도메인과 브랜드 이름을 사용하여 고객에게 가짜 메시지를 보낼 수 있습니다. 이러한 피싱 이메일은 고객을 설득할 수 있을 만큼 진짜인 것처럼 보여 회사 명의의 인터넷 사기에 속아 넘어가게 만듭니다. 이는 기업의 브랜드 신뢰도를 떨어뜨리고 대외 이미지를 손상시킬 수 있습니다. SPF는 신뢰할 수 있는 도메인의 세이프 리스트라고 생각하면 되며, 이를 통해 신뢰할 수 있는 커뮤니케이션이 시작될 수 있습니다.
내 도메인이 허용된 발신자인지 확인하는 방법은 무엇인가요?
"SPF 소프트실패 도메인이 IP를 허용된 발신자로 지정하지 않음" 오류의 첫 번째 단계는 발신자 권한을 확인하는 것입니다. 확인하려면 다음과 같이 하세요:
1단계: 회사 도메인의 이메일 계정(예: [email protected])에 로그인합니다.
2단계: 액세스 권한이 있는 다른 이메일 계정으로 이메일을 보내세요. Gmail, Yahoo, Hotmail 등의 외부 도메인이 될 수 있습니다.
3단계: 첫 번째 메일을 보낸 이메일 계정에 로그인한 다음 이 이메일의 헤더를 확인합니다. '원본 표시'로 표시되어 있을 것입니다.
그러면 다음과 비슷한 메시지가 표시됩니다. SPF 소프트패일 메시지를 확인합니다.
-원본 메시지 -
X-Received: ...
토, 13 March, 2022 11:01:19 IST
반환 경로: [email protected]
수신: mymy2.spfrecords.com(mymy2.spfrecords.com [60.130.71.223]))
by mx.google.com, ESMTPS ID 사용
*ID*
수신된 SPF: softfail(google.com: [email protected] 전환 도메인이 60.130.71.223을 허용된 발신자로 지정하지 않음) client-ip=60.130.71.223;
인증 결과: mx.google.com;
Spf = 소프트실패(google.com: 전환하는 [email protected] 도메인이 60.130.71.223을 허용된 발신자로 지정하지 않음) client-ip=60.130.71.223;
*헤더 메시지 끝
참고: 헤더에서 "Received-SPF: pass"를 확인했다면 메일을 보내는 데 사용하는 도메인이 인증되었으며 이미 SPF 레코드에 추가되어 있으므로 걱정할 필요가 없습니다. 그러나 위에 표시된 것처럼 소프트 페일 문제가 있습니다. 이제 이 문제를 해결하는 방법을 살펴보겠습니다.
"SPF 소프트패일 도메인이 IP를 허용된 발신자로 지정하지 않음"은 무엇을 의미하나요?
이메일 발신자의 호스트 IP는 다음과 같습니다:
30.10.323.005
보내는 도메인의 이 IP 주소가 도메인의 SPF 레코드에 포함되어 있지 않으면 이메일 수신 서버가 지정된 IP를 허용된 발신자로 식별하지 못합니다. 서버는 자동으로 해당 메시지를 허용되지 않은 출처에서 보낸 것으로 해석합니다. 이것이 메시지에 대한 SPF가 실패한 이유일 수 있습니다. 이메일 인증 시스템이 출처 확인을 위해 DKIM이 아닌 SPF에만 의존하는 경우 DMARC 실패 확률이 높습니다.
이러한 상황에서 프로토콜 정책이 거부하도록 설정되어 있으면 메시지가 전달되지 않습니다! 따라서 도메인 소유자는 신속하고 실행 가능한 조치를 취하여 "SPF 소프트 실패 도메인이 IP를 허용된 발신자로 지정하지 않음" 문제를 해결해야 합니다.
SPF에 허용된 발신자로 IP를 포함하려면 어떻게 해야 하나요?
이에 대한 해결책은 다음 단계로 나눌 수 있습니다:
1. 도메인에 대한 전송 소스 목록을 만듭니다. 도메인을 기반으로 하는 이메일 주소 목록과 타사 전송 소스를 이메일 거래에 사용할 수 있습니다.
2. 이제 이러한 전송 소스의 호스트 IP를 식별합니다.
이메일 전송 소스에 연결된 IP 주소를 찾는 방법은 무엇인가요?
아주 간단합니다! 이메일을 열어 전체 이메일 헤더를 확인하면 전송 소스의 IP 주소를 찾을 수 있습니다. 이렇게 하려면 이메일 오른쪽 상단에 있는 점 3개를 클릭하여 드롭다운 메뉴를 확인한 후 "원본 표시".
원본 메시지에서 아래로 스크롤하여 받은 줄까지 스크롤하면 아래와 같이 원래 보낸 사람의 호스트 IP 주소를 확인할 수 있습니다:
3. 3. SPF 레코드 생성기 를 사용하여 도메인에 대한 무료 SPF 레코드를 생성합니다.
- 레코드 생성기에서 회사를 대신하여 이메일 및 커뮤니케이션을 보낼 수 있도록 인증하려는 모든 IP 주소를 추가합니다.
- 타사 서버 또는 외부 배달 서비스를 도메인에 대한 승인된 전송 소스로 추가합니다. 이렇게 하면 타사 서버를 통해 전송되는 모든 메일도 SPF 인증을 통과합니다.
4. SPF 레코드 생성기를 사용하여 신뢰할 수 있는 모든 도메인과 IP 주소가 추가된 도메인에 대한 SPF 레코드를 생성했으면 이제 남은 작업은 DNS에 게시하여 SPF를 구현하기만 하면 됩니다. 이를 수행하는 방법은 다음과 같습니다:
- DNS 관리 콘솔에 로그인합니다.
- 다음으로 선택한 도메인(SPF 레코드를 추가/수정하려는 도메인)으로 이동합니다.
- 리소스 유형을 'TXT'로 지정합니다.
- 호스트 이름을 "_spf"로 지정합니다.
- 생성된 SPF 레코드 값 붙여넣기
- 변경 사항을 저장하여 도메인에 대한 SPF를 구성합니다.
참고: 위의 이름 또는 헤더는 회사에서 사용 중인 DNS 관리 콘솔에 따라 다를 수 있습니다..
이렇게 하면 도메인 소유자는 회사를 대신하여 통신을 보내는 데 사용할 수 있는 모든 신뢰할 수 있는 IP 주소와 도메인이 서버에 추가되도록 할 수 있으며, SPF 소프트실패 도메인이 허용된 발신자로 IP를 지정하지 않는 유사한 오류가 발생하지 않습니다.
SPF 표준을 효과적으로 사용하는 방법은 무엇인가요?
기업의 SPF 기술을 공고히 하는 유일한 방법은 다음과 통합하는 것입니다. DMARC. 이를 통해 얻을 수 있는 이점은 다음과 같습니다,
1. DMC = SPF + DKIM
다음과 같은 이메일 인증 프로토콜 DMARC 와 같은 이메일 인증 프로토콜은 DNS에 TXT 레코드를 추가하여 구성합니다. 도메인의 이메일에 대한 정책을 구성하는 것 외에도 DMARC를 활용하여 도메인, 공급업체 및 이메일 소스에 대한 다양한 정보를 전송하는 보고 메커니즘을 활성화할 수도 있습니다.
DMARC는 SPF(발신자 정책 프레임워크)와 DKIM(DomainKeys 식별 메일) 기술을 함께 사용하여 도메인을 스푸핑으로부터 더욱 강력하게 보호할 수 있도록 도와줍니다.
참고: 이는 권장 사항이지만 필수는 아닙니다. DMARC는 SPF 또는 DKIM 식별자 정렬과 함께 작동할 수 있습니다.
2. PowerDMARC를 사용한 보고 및 피드백
SPF나 DKIM 모두 인증에 실패한 이메일에 대한 피드백을 도메인 소유자에게 제공하지 않습니다. DMARC는 자세한 보고서를 사용자에게 직접 보내며, PowerDMARC 플랫폼은 이를 읽기 쉬운 차트와 표로 변환합니다.
3. 인증되지 않은 이메일에 대한 조치 제어
도메인 소유자는 유효성 검사에 실패한 이메일을 받은 편지함으로 보낼지, 스팸으로 보낼지, 거부할지 결정할 수 있습니다. PowerDMARC를 사용하면 버튼 하나만 클릭하면 DMARC 정책을 설정할 수 있을 정도로 간단합니다.
인증되지 않은 발신자는 고객의 보안과 회사의 이미지 및 브랜드 가치에 위험한 위협이 될 수 있습니다. 회사에 DMARC를 통합하여 피싱과 사기로부터 고객을 보호하고 인증된 발신자가 보낸 메일만 고객에게 전달되도록 허용하세요.
도메인 및 이메일 보안 전문가 PowerDMARC
Yunes는 이메일 인증 및 보안에 대한 전문 지식을 갖춘 PowerDMARC의 운영 팀장입니다. Yunes는 CompTIA A+ 등의 자격증을 보유한 Microsoft 인증 Azure 관리자 어소시에이트입니다.
Yunes Tarada의 최신 글 (전체 보기)
- 야후 재팬, 2025년 사용자를 위한 DMARC 도입 시행 - 2025년 1월 17일
- 악성코드 확산을 위해 SPF의 잘못된 구성을 악용하는 MikroTik 봇넷 - 1월 17, 2025
- DMARC 인증되지 않은 메일이 금지됨 [해결됨] - 2025년 1월 14일
