중요 알림: Google과 Yahoo는 2024년 4월부터 DMARC를 요구할 예정입니다.

SPF 조회

DNS에 SPF 레코드를 게시할 때 몇 가지 문제가 발생할 수 있습니다. SPF 레코드 무효화를 방지하는 방법은 다음과 같습니다.

SPF 기록에 대한 일반적인 실수

SPF 레코드를 올바르게 설정하는 것은 다소 까다로울 수 있지만, 레코드가 무효화되면 이메일 전송률이 떨어질 수 있으므로 반드시 설정해야 합니다.

잘못된 매크로
SPF 매크로는 도메인에 대한 동적 SPF 정책을 생성할 수 있는 기능으로, 조건부 조회와 같은 고급 SPF 처리 루틴을 가능하게 합니다. 잘못된 매크로는 SPF 레코드 자체를 유효하지 않게 만들 수 있습니다.
누락된 레코드 종료
모든 SPF 레코드에는 기본 '폴백' 메커니즘이 있어야 합니다. 이는 종종 '모든' 메커니즘 또는 '리디렉션' 수정자의 형태를 취합니다. 레코드에 이러한 메커니즘 중 하나가 있는지 확인해야 하며, 그렇지 않으면 전체가 무효화될 위험이 있습니다.
DNS 유형 'SPF' 사용
DNS 유형 'SPF'는 2006년에 도입되었지만 오늘날의 기준으로는 완전히 사용되지 않습니다. 모든 SPF 레코드는 DNS TXT 리소스 레코드로 게시해야 합니다.
대문자 사용
엄격한 요건은 아니지만, SPF 레코드를 모두 소문자로 게시하는 것이 이메일 보안의 모범 사례입니다.

DNS의 여러 SPF 레코드
DNS에는 각 SPF 버전에 대해 하나의 SPF 레코드만 가질 수 있습니다. 여러 SPF 레코드(v=spf1)를 게시하면 레코드가 무효화됩니다. 항상 현재 SPF 레코드를 업데이트하고 기존 레코드와 함께 새 레코드를 추가하지 마세요.
PTR 메커니즘 사용
PTR 메커니즘은 속도가 느리고 신뢰성이 부족하여 더 이상 사용되지 않으며, 거의 아무도 사용하지 않습니다. 실제로 많은 발신자가 이 방법을 사용할 경우 SPF 기록을 무시할 수도 있습니다.
SPF 기록에서 알 수 없는 부분
메커니즘, 수정자 또는 한정자가 아닌 콘텐츠나 구성 요소를 사용하는 경우 수신 이메일 서버에서 인식하지 못합니다. 이와 같은 콘텐츠는 즉시 제거해야 합니다.
모두 메커니즘 사용
'+' 한정자와 함께 '모든' 메커니즘을 사용하면 기본적으로 모든 사람이 회원님을 대신하여 이메일을 보낼 수 있도록 허용하는 것입니다. 레코드가 먼저 전송 소스를 다른 메커니즘과 일치시키려고 시도하기 때문입니다. 이것이 실패하면 기본 동작은 이 소스를 계속 허용하는 것입니다. 이러한 종류의 설정이 권장되지 않는 이유를 알 수 있습니다.

조직의 도메인 이름을 입력하고 'SPF 조회'를 클릭하면 도메인에 SPF 레코드가 있는지 여부를 확인할 수 있습니다. 물론 이 레코드는 도구에서 찾을 수 있도록 DNS에 게시되어 있어야 합니다.

제공된 양식에 세부 정보를 입력하고(개인 정보를 요구하지 않음) 'SPF 레코드 생성' 버튼을 클릭하면 완료됩니다! DNS에 즉시 게시할 수 있는 최적화된 나만의 SPF 레코드가 생성됩니다.