구글은 2026년 초에 _spf.google.com 레퍼런스 체인에서 _netblocks3.google.com을 공식 공지 없이 조용히 제거했습니다. 대부분의 Google Workspace 사용자는 아무 변화도 없습니다. 하지만 구글의 내부 SPF 구조를 수동으로 하드코딩한 도메인 소유자나 IT 팀이라면, 설정 오류가 배송 문제를 일으키기 전에 지금 바로 레코드를 감사해야 합니다.
구글이 실제로 변경한 것
_spf.google.com 레퍼런스 내부를 보면, 이메일 송신용 구글의 IP 범위를 담은 내부 서브 레코드들을 가리킵니다. 이전에는 이 체인에 3개의 서브 레코드가 포함되어 있었습니다. 구글은 이제 그 체인에서 _netblocks3.google.com을 조용히 제거했으며, 이는 단순히 이 서브 레코드가 더 이상 활성 송신 주소를 보유하지 않는다는 뜻입니다. 쉽게 말해, 구글이 SPF 구조를 정리한 것입니다.
구글이 이에 대해 큰 공지를 하지 않은 이유는 대부분의 도메인에서 아무 문제가 발생하지 않기 때문입니다. 문제는 구글의 내부 구조를 수동으로 복사한 경우에만 드러나며, 이는 SPF 레코드를 유효하지 않게 하거나 불필요한 레퍼런스를 가리키게 할 수 있습니다. 이메일 배송이 즉시 중단되지는 않을 수 있지만, SPF 설정을 유지하기가 더 어려워집니다.
실제로 위험한 대상
대부분의 Google Workspace 사용자는 이 변경에 대해 걱정할 필요가 없습니다. 그들은 표준 include:_spf.google.com 항목을 사용하며, 구글이 뒤에서 모든 것을 관리합니다. 이 형식의 레코드는 계속 정확히 예상대로 작동합니다.
구글의 권장 include를 사용하는 경우 문제가 없습니다. 하지만 구글의 내부 구조를 수동으로 복사한 도메인 소유자는 문제를 마주칠 수 있습니다. 이는 보통 기술 팀이 DNS 조회 한도인 10개에 도달하고, SPF 평탄화 도구를 사용하는 대신 개별 netblock 레퍼런스를 하드코딩하여 해결하려고 할 때 발생합니다.
이 조회 한도는 경미한 문제가 아닙니다. RFC 7208에 따르면, SPF 평가는 체크당 10개의 DNS 메커니즘 조회와 2개의 void 조회로 제한됩니다. 둘 중 하나라도 초과하면 PermError가 발생하여 도메인의 모든 메시지에 대한 인증이 실패합니다. 그리고 이 실패는 무음입니다. 이메일이 반송되지 않고 스팸으로 이동하거나 발신자가 확인할 수 있는 명확한 오류 없이 거부됩니다.
DNS 조회 예산 문제
이 업데이트는 또한 여러 송신 도구를 사용하는 기업들이 직면한 더 광범위한 문제를 강조합니다. 구글의 include:_spf.google.com만 해도 사용 가능한 10개 조회 중 4개를 사용하여 다른 모든 송신자용으로 6개만 남깁니다. SendGrid도 사용하는데 이것이 5개 조회를 소비하면, 합계는 9개가 되고, 한 명의 송신자를 추가하면 한계에 도달합니다.
구글, 마이크로소프트, SendGrid, Mailchimp를 모두 포함하는 도메인은 12개 조회에 도달합니다. RFC 7208은 평가를 10개로 제한합니다. 수신 메일 서버는 PermError를 반환하고 도메인의 모든 메시지는 실제로 어느 송신자에서 왔는지와 관계없이 SPF 인증에 실패합니다.
마케팅 플랫폼을 통해 캠페인을 실행하면서 동시에 제3자 서비스에서 트랜잭션 이메일을 보내는 성장 팀의 경우, 이는 실질적이고 흔한 함정입니다.
SPF 레코드에서 확인할 사항
_netblocks.google.com, _netblocks2.google.com, 또는 _netblocks3.google.com과 같은 개별 netblock 항목이 레코드에 있다면 제거하세요. 이 모든 항목을 _spf.google.com을 가리키는 단일 include로 교체하면, 설정이 깔끔해지고 구글이 자동으로 업데이트됩니다.
Google Workspace만 사용하여 이메일을 보내는 경우, 올바른 레코드는 다음과 같습니다. v=spf1 include:_spf.google.com ~all
SPF 설정을 몇 개월마다 확인하여 오래된 항목, 중복된 레퍼런스, 또는 깨진 include를 찾는 것은 정렬 문제와 배송 문제를 예방하는 데 도움이 됩니다.
이것이 이메일 마케팅 ROI에 중요한 이유
SPF는 단순한 기술 유지 관리 작업이 아닙니다. 발신자 평판의 기초에 있습니다. 올바르게 구성된 Google Workspace SPF 레코드가 없으면, 도메인을 확인할 수 없는 수신 서버에서 이메일이 스팸으로 표시될 수 있습니다. 도메인 또는 IP 주소가 블록리스트에 올라갈 수 있으며, 배송 복구는 처음부터 인증을 올바르게 설정하는 것보다 훨씬 어렵습니다. 그리고 도메인 평판은 스팸 불만이 쌓이면서 손상이 복합적으로 증가합니다.
2023년 10월에 발표되고 2024년 2월부터 시행된 구글의 대량 발신자 요구사항은, Gmail 주소로 하루에 5,000건 이상의 메시지를 보내는 모든 도메인이 SPF와 DKIM으로 인증하고, 최소한 p=none의 DMARC 레코드를 발행하고, 스팸 불만 비율을 0.3% 이하로 유지하고, 마케팅 메일에 원클릭 구독 해제 헤더를 포함해야 한다고 규정합니다. 이 규칙은 From 헤더의 모든 도메인에 적용되며, 구글은 이제 규정을 준수하지 않는 대량 발신자의 메시지를 거부하거나 스팸으로 보냅니다.
이를 잘못하면 배송 가능 범위가 직접 감소하므로, 열림률, 클릭률, 그리고 보내는 모든 캠페인의 ROI가 낮아집니다.
지금 취해야 할 3가지 단계
SPF만으로는 부족합니다. DKIM 및 DMARC와 함께 사용하면 수신 서버가 메시지를 올바르게 확인하고 도메인을 사용한 피싱 시도를 차단할 수 있습니다. SPF 조회 확인기, DMARC 분석기, 또는 이메일 보안 대시보드와 같은 도구는 변경 사항을 모니터링하고 설정 문제를 조기에 감지하는 데 도움이 됩니다.
이 업데이트에 대응하려면:
- MXToolbox 또는 구글 관리자 도구함과 같은 도구를 사용하여 현재 SPF 레코드를 조회하세요.
- 레코드에
include:_spf.google.com만 포함되어 있다면, 변경할 필요가 없습니다. 구글이 업데이트를 관리합니다. - 개별
_netblocks항목이 있다면, 이를 통합하고 총 조회 수가 10 이하로 유지되는지 확인하세요.
구글의 조용한 SPF 체인 정리는 이메일 인증 인프라가 예고 없이 변할 수 있다는 상기시켜줍니다. 수동으로 구성된 레코드에 의존하는 도메인은 계속해서 이 문제에 직면하게 될 것입니다. 공식 include 레퍼런스를 사용하고 설정을 정기적으로 검토하는 것이 보호받는 직관적인 방법입니다.
