Defaults.Exposed › 보고서
SPF +all: 인터넷 전체가 자신을 사칭해 메일을 보내도록 허용하는 도메인들 (2026)
게시일 2026-07-03
수치 기준일 2026-06-29 · 방법론 v7. 261백만 개의 등급 판정 도메인에 대한 종합 센서스입니다. 모든 수치는 집계값이며 — 개별 기업의 레코드는 결코 다루지 않습니다. 등급 판정 방식을 참고하세요.
36,014개의 도메인이 SPF 레코드를 +all로 끝맺고 있습니다 — 인터넷상의 모든 서버가 자신을 사칭해 이메일을 보낼 권한이 있다는, 공개되고 기계 판독이 가능한 선언입니다. 이는 가장 드문 SPF 설정 오류이자(발행자 중 0.03%) 가장 자멸적인 오류입니다. 레코드가 아예 없으면 수신자는 자체 휴리스틱에 의존하지만, +all은 위조범이 정당하다고 적극적으로 알려주기 때문입니다.
SPF 레코드에서 +all은 무슨 뜻인가요?
마지막 all 메커니즘에는 한정자(qualifier)가 붙습니다 — 여러분의 목록에 없는 발신자에 대한 판정입니다. -all은 그들을 거부하고, ~all은 그들을 의심하며 — +all은 그들을 승인합니다. 위조된 메시지를 +all 레코드와 대조해 검사하는 수신자는 깔끔한 SPF *통과(pass)*를 반환합니다. 한 문장으로 요약된 그 피해는 이렇습니다: 여러분의 보호 장치가 위조범을 보증합니다. 그리고 SPF 통과가 DMARC의 SPF 항목을 충족시킬 수 있기 때문에, 이 통과는 사칭을 막으려고 만들어진 바로 그 시스템을 뚫고 사칭이 지나가도록 도울 수 있습니다.
지도: 환영 매트는 어디에 몰려 있나
+all은 어디에나 있지만, 얇게 퍼져 있습니다 — 그러나 그 비율은 도메인 끝자리에 따라 뚜렷하게 다릅니다. 수치는 센서스에서 가져왔으며, 비율 = 해당 TLD의 SPF 발행자 10,000개당 +all 레코드 수입니다:
| TLD | +all 도메인 | 10,000개당 비율 |
|---|---|---|
| .be | 1,399 | 22.5 |
| .nl | 1,965 | 8.8 |
| .eu | 672 | 6.6 |
| .fr | 1,147 | 6.2 |
| .net | 1,640 | 3.6 |
| .org | 1,392 | 2.8 |
| .com | 16,636 | 2.4 |
| .de | 732 | 1.3 |
베네룩스-프랑스 클러스터가 두드러집니다: .be SPF 발행자는 .com 발행자보다 +all을 지닐 확률이 약 9배 더 높습니다(10,000개당 22.5 대 2.4). 이 정도로 집중된 패턴이 서로 무관한 수천 건의 실수를 의미하는 경우는 드뭅니다 — 가장 그럴듯한 설명은 공통의 출처입니다: 지역 호스팅 패널, 등록대행사 템플릿, 또는 +all을 실어 보낸 후 수년간 복사된 안내 문서 같은 것 말입니다. 같은 지문이 심각도 사다리에서 한 칸 아래에서도 나타납니다: .za의 SPF 레코드 중 22.6%가 중립 ?all로 끝나는데, 이는 같은 방향을 가리키는 국가적 이상치입니다.
어쩌다 +all에 이르게 되나요?
모두 악의 없는 세 가지 경로가 있습니다:
- 끝나지 않은 디버깅 세션.
+all은 모든 SPF 문제를 사라지게 합니다 — 메일이 흐르고, 오류가 멈춥니다. 누군가 출시를 막던 장애를 풀려고 이걸 설정했는데, 그 레코드가 사건보다 오래 살아남은 것입니다. - 문법 오독. 한정자 표를 한 번도 본 적이 없다면
+는 “내 목록을 허용하라”는 뜻처럼 보입니다. 의도는-all이었는데, 그 한 글자가 의미를 뒤집었습니다. - 물려받은 템플릿. 지도가 시사하듯, 일부 레코드는 패널이나 안내서에서 이미 망가진 채로 도착합니다.
한 글자짜리 해결책
+all을 -all로 바꾸세요 — 또는 뒤에 시행 중인 DMARC를 둔 ~all로 바꾸세요. 하나의 TXT 레코드에서 한 글자, 무료이며, DNS가 갱신되는 즉시 — 보통 한 시간 이내에 — 적용됩니다. 도메인에서 이보다 더 빠른 보안 개선책은 없습니다.
자주 묻는 질문
SPF 레코드에서 +all은 무슨 뜻인가요? 인터넷상의 모든 서버가 여러분의 도메인을 사칭해 이메일을 보내도록 권한을 부여하는 것으로, SPF의 목적과 정반대입니다. 2026-06-29 기준으로 36,014개의 도메인이 이를 발행하고 있습니다.
+all이 SPF 레코드가 아예 없는 것보다 더 나쁜가요?
중요한 한 가지 측면에서는 그렇습니다: 레코드가 없으면 수신자는 추측하게 되지만, +all은 위조를 깔끔한 SPF 통과로 바꿀 수 있으며 — 그 통과는 심지어 위조가 DMARC를 뚫고 지나가도록 도울 수도 있습니다. 일부 필터는 +all 자체를 스팸 신호로 취급하기도 하므로, 여러분의 정당한 메일에도 해를 끼칠 수 있습니다.
내 도메인에 +all이 있는지 어떻게 확인하나요?
TXT 레코드를 읽거나(dig TXT yourdomain.com) 무료 검사를 실행하세요 — 허용적인 한정자는 즉시 표시됩니다.
템플릿이 왜 애초에 +all을 기본값으로 두는 걸까요? 가장 그럴듯한 이유는 지원 티켓을 전혀 발생시키지 않기 때문입니다 — 사기성 배달을 포함해 모든 배달이 “작동”하니까요. 우리 데이터의 지역적 클러스터링은 수천 개의 개별 선택이라기보다 템플릿 기본값과 일치합니다. 다만 센서스는 레코드를 볼 뿐, 그 작성자를 보지는 못합니다.
여러분의 끝자리를 확인하세요
환영 매트를 깔아둔 소유자 대부분은 그것이 거기 있다는 것을 전혀 모릅니다. 자기 집 현관 매트를 읽는 데는 30초면 되고, 다시 쓰는 데는 한 글자면 됩니다.
내 도메인 확인하기 → · SPF 고치기 → · ~all 대 -all → · 설정 오류 명예의 전당 → · 집계 데이터만 사용합니다. 데이터는 EU에서 저장 및 처리됩니다.