SPF ptr 메커니즘이란 무엇이며, 왜 아직도 950,631개의 레코드에 남아 있을까? (2026)

Q: ptr 대신 무엇을 사용해야 하나요?

여러분이 관리하는 서버에 대해서는 ip4:/ip6: 블록을, 또는 여러분의 제공업체가 문서화한 include:를 사용하세요. 둘 다 결정론적이고, 빠르며, 신뢰할 수 있습니다 — ptr가 아닌 모든 것을 갖추었습니다.

Q: ptr는 SPF 10회 조회 한도에 포함되나요?

네 — 모든 ptr는 수신자가 PermError로 포기하기 전에 수행할 열 번의 DNS 조회 중 최소 하나를 소모합니다. 이미 include: 메커니즘으로 쌓인 레코드에서는, 이 죽은 메커니즘이 바로 여러분을 한도 너머로 밀어붙이는 것일 수 있습니다.

게시일 2026-07-03

2026-06-29 기준 수치 · 방법론 v7. 261백만 개의 등급 평가된 도메인에 대한 집계 센서스입니다. 모든 수치는 집계값이며 — 개별 기업의 레코드가 아닙니다. 등급 평가 방법 보기.

ptr는 역방향 DNS 조회를 통해 발신자를 인증하는 SPF 메커니즘이며 — SPF 표준 자체가 2014년부터 “사용하지 말라”고 명시해 왔습니다. 12년이 지난 지금도 950,631개의 도메인이 여전히 이를 게시하고 있습니다. 이는 인터넷상의 139백만 개 SPF 레코드 중 대략 146개 중 1개가, 그중 일부 도메인이 등록되기도 전에 명세에서 폐기된 메커니즘을 여전히 지니고 있다는 뜻입니다.

ptr가 원래 하려던 일

ptr는 이렇게 말합니다: “역방향 DNS가 내 도메인으로 다시 확인되는 모든 서버로부터의 메일을 수락하라.” 겉보기에는 우아합니다 — 유지 관리할 IP 목록이 없으니까요. 하지만 실제로는 수신자가 연결하는 IP에 대해 역방향 조회를 수행한 다음, 되돌아오는 모든 호스트명을 정방향으로 재확인해야 합니다. RFC 7208(§5.5)은 이를 분명한 말로 폐기했습니다: 이 메커니즘은 “느리고, DNS 오류가 발생하는 경우 다른 메커니즘만큼 신뢰할 수 없으며, .arpa 네임 서버에 큰 자원 부담을 지운다” — 그리고 이를 **“사용해서는 안 된다(SHOULD NOT be used)“**고 지시합니다.

2026년에도 여전히 함정인 이유

12년 전에 폐기된 메커니즘이 여전히 중요한 세 가지 이유:

조회 예산을 소모합니다. 모든 ptr는 검사당 DNS 조회 10회라는 SPF의 엄격한 상한선에 포함됩니다 — 이 한도를 초과하면 레코드 전체가 PermError로 무효화됩니다. 신뢰할 만한 아무 일도 하지 않는 메커니즘이 여전히 여러분의 진짜 include: 메커니즘에 필요한 예산을 잡아먹는 것입니다.
예측 불가능하게 실패합니다. 역방향 DNS는 대부분의 네트워크에서 가장 관리가 소홀한 부분입니다. ptr 조회가 시간 초과되거나 정방향 재확인이 실패하면, 여러분의 정상적인 메일은 의존하고 있던 SPF 통과를 잃게 됩니다.
일부 수신자는 아예 건너뜁니다. 표준이 이를 폐기했기 때문에, 일부 구현체는 ptr를 그냥 무시합니다 — 그래서 이 메커니즘이 인증하려던 발신자들은 애초에 전혀 보호받지 못했던 것입니다.

어디에서 비롯되는가

오늘날 ptr를 의도적으로 선택하는 사람은 거의 없습니다. 이는 상속을 통해 도달합니다: 2009년에 작성된 설정 가이드, 오래된 서버 구성에서 복사한 템플릿, 세 번의 호스팅 이전을 거치며 그대로 옮겨진 “작동하는” 레코드. 이것이 우리 센서스가 폐기되었으나 여전히 존재하는 모든 메커니즘에서 목격하는 패턴입니다: 오래된 조언은 사라지지 않고, 복사-붙여넣기 됩니다. ptr를 지닌 도메인들은 부주의한 것이 아니라 — 12년 전에 폐기된 지침을 따르고 있을 뿐입니다.

수정 방법 — 무료, 5분

여러분의 SPF 레코드를 찾으세요(dig TXT yourdomain.com 또는 무료로 확인).
ptr가 포함되어 있다면, 어떤 서버들이 이에 의존하고 있었는지 파악하세요.
ptr를 정확한 형식으로 교체하세요: 여러분이 관리하는 서버에 대해서는 ip4:/ip6: 블록으로, 또는 여러분의 제공업체가 문서화한 include:로 교체하세요.
그 김에, 레코드가 실제 한정자(qualifier)로 끝나는지 확인하세요 — ~all 대 -all 참조.

자주 묻는 질문

SPF 레코드에서 ptr는 무슨 의미인가요? 역방향 DNS가 여러분의 도메인으로 확인되는 모든 서버를 인증합니다. RFC 7208 §5.5는 2014년에 이를 느리고 신뢰할 수 없다는 이유로 폐기했으며 사용해서는 안 된다고 명시했습니다 — 그럼에도 2026-06-29 기준 950,631개의 도메인이 여전히 이를 게시하고 있습니다.

SPF ptr 메커니즘이 유효한 경우가 있나요? 여전히 파싱되고, 일부 수신자는 여전히 이를 평가합니다 — 하지만 표준은 모든 경우에 이를 권장하지 않으며, 일부 수신자는 이를 무시하고, 열 번의 DNS 조회 중 하나를 소모합니다. ptr가 정답인 현대적 구성은 존재하지 않습니다.

ptr 대신 무엇을 사용해야 하나요? 여러분이 관리하는 서버에 대해서는 ip4:/ip6: 블록을, 또는 여러분의 제공업체가 문서화한 include:를 사용하세요. 둘 다 결정론적이고, 빠르며, 신뢰할 수 있습니다 — ptr가 아닌 모든 것을 갖추었습니다.

ptr는 SPF 10회 조회 한도에 포함되나요? 네 — 모든 ptr는 수신자가 PermError로 포기하기 전에 수행할 열 번의 DNS 조회 중 최소 하나를 소모합니다. 이미 include: 메커니즘으로 쌓인 레코드에서는, 이 죽은 메커니즘이 바로 여러분을 한도 너머로 밀어붙이는 것일 수 있습니다.

유령을 찾아 레코드를 확인하세요

12년 전에 폐기된 메커니즘이 여전히 여러분의 DNS에 자리 잡고 있는 것은 바로 아무도 찾아보지 않는 종류의 것입니다. 찾아보는 데는 30초면 됩니다.

내 도메인 확인하기 → · SPF 수정하기 → · SPF 레코드 두 개 = 없음 → · SPF 성숙도 모델 → · 집계 데이터만 사용. 데이터는 EU에서 저장 및 처리됩니다.