SPF 문제는 얼마나 흔한가요?

SPF 10 조회 문제는 매우 일반적입니다. 여러 타사 전송 서비스를 사용하는 모든 도메인은 실제로 한도를 초과할 위험이 있으며 비즈니스 도메인의 상당 부분이 이미 이를 초과하고 있습니다. 이것이 널리 퍼져 있는 이유는 추가하는 각 공급업체가 여러 개의 중첩된 DNS 조회로 확장되므로 표면적으로는 짧아 보이는 레코드가 뒤에서는 조용히 10개 이상으로 확인되기 때문입니다.

일반 설정에서 이런 일이 발생하는 이유

한계에 도달하기 위해 특이한 구성이 필요하지 않습니다. 일반적인 회사는 사서함 공급자와 소수의 마케팅, 지원 및 판매 도구를 통해 전송하며 각 회사는 자체 포함 체인을 제공합니다.

• 핵심 메일용 Google Workspace 또는 Microsoft 365
• 뉴스레터 및 캠페인을 위한 마케팅 플랫폼입니다.
• 티켓 답장을 보내는 지원 데스크입니다.
• 판매 이메일을 위한 Salesforce 와 같은 CRM입니다.
• 영수증 및 경고를 위한 SendGrid 와 같은 트랜잭션 발신자.

5개의 벤더는 10회 이상의 조회를 기록하는 데 충분합니다. 왜냐하면 각 포함마다 그 안에 2~3개의 조회가 더 중첩되는 경우가 많기 때문입니다. 제공업체는 시간이 지남에 따라 자체 SPF 레코드에 호스트 이름을 추가하므로 레코드를 건드리지 않고도 개수가 늘어납니다.

조용히 실패하는 이유

이것이 위험한 부분이다. SPF 10회 조회를 초과하면 수신자는 오류로 처리되는 permerror 반환합니다. 하지만 아무것도 당신에게 되돌아오지 않습니다. 메일 팀에서는 오류, 거부 알림, 명백한 증상을 볼 수 없습니다. 그 동안 수신 서버는 합법적인 메일의 일부를 조용히 다운그레이드하거나 거부하므로 명확한 원인 없이 배달 가능성이 저하됩니다. 고객이 이메일을 받지 못했다고 말할 때만 문제가 나타나는 경우가 많습니다.

지금이 더 중요한 이유

2024년 Google 및 Yahoo 규칙부터 대량 발신자는 메일을 인증해야 하며 SPF 레코드에 실패하면 DMARC 정렬이 위험해집니다. SPF 실패하고 DKIM 정렬이 확실하지 않으면 DMARC 실패하고 메시지가 스팸으로 분류되거나 완전히 거부될 수 있습니다. 예전에는 허용 가능한 경고였지만 이제는 전달 가능성을 방해하는 요소가 되었습니다.

자신이 어디에 서 있는지 알아보기

EmailAuth 의 무료 도메인 스캔은 전체 포함 체인을 확장하고 실제 조회 수를 계산하므로 이미 한도를 초과했는지 확인할 수 있습니다. 그렇다면 SmartSPF 동적 평면화는 포함 내용을 하나의 최적화된 기록으로 축소하고 Microsoft 365 , Google Workspace , Salesforce 및 SendGrid 의 공급업체 IP 범위를 동기화하여 영구적으로 10개 미만으로 유지합니다.

자주 묻는 질문