Defaults.Exposed › 보고서

SPF ~all vs -all: 소프트페일이냐 하드페일이냐 — 139만 개 레코드의 선택 (2026)

게시일 2026-07-03

2026-06-29 기준 수치 · 방법론 v7. 261만 개의 등급 산정 도메인에 걸친 집계 인구조사 데이터입니다. 모든 수치는 집계값이며 — 개별 기업의 레코드를 공개하는 일은 결코 없습니다. 등급 산정 방식 보기.

모든 SPF 레코드는 “all” 메커니즘으로 끝납니다 — 이는 목록에 없는 어디에서든 온 메일에 대한 판정이며 — 인터넷은 압도적으로 부드러운 쪽을 선택했습니다: SPF를 게시하는 139만 개 도메인 중 55.8%가 ~all(소프트페일)로 끝나고, -all(하드페일)로 끝나는 것은 39.3%입니다. “위조를 거부하라”와 “아마 위조겠지만 — 그래도 전달하라” 사이를 가르는 것은 단 한 글자입니다. 어느 쪽이 당신에게 옳은지는 대부분의 소유자가 결코 구성하지 않는 두 번째 설정에 달려 있습니다.

~all과 -all은 실제로 수신자에게 무엇을 알리는가?

• -all(하드페일): “그 밖의 어디에서 온 메일도 거부하라.” 단호한 거절.
• ~all(소프트페일): “다른 곳에서 온 메일은 아마 정당하지 않을 것이다 — 받아들이되, 아마 표시하라.” 어깨를 으쓱하는 태도.
• ?all(중립): “의견 없음.” 게시자의 3.0%가 선택했으며, 이름뿐인 보호입니다.
• +all: “누구든 나로서 보낼 수 있다.” 36,014개 도메인이 게시했으며, 레코드가 아예 없는 것보다 나쁩니다 — 이 환영 매트 문제는 별도의 보고서로 다룹니다.

그렇다면 ~all이 틀린 것인가? 오직 홀로 있을 때만 — 그리고 거의 항상 홀로 있다

소프트페일에는 옹호할 만한 현대적 근거가 있습니다: Google의 발신자 지침과, 그와 더불어 대부분의 전달성(deliverability) 관행은 **강제하는 DMARC 정책(p=reject)과 짝지어진 ~all**로 수렴합니다. 이 짝은 모든 DMARC 평가 수신자에서 — 이제는 모든 주요 메일박스 제공자를 포함합니다 — -all만큼 잘 보호하면서도, -all의 전형적 희생양인 정당한 전달 메일을 하드 바운스로 튕겨내지 않습니다. 이 구성에서는 어깨를 으쓱하는 태도에 이빨이 생깁니다: DMARC가 SPF가 내놓기를 거부한 판정을 공급하는 것입니다.

그러나 그 짝짓기야말로 핵심 전부이며, 인구조사가 설정 안내서로는 알 수 없는 것을 여기에 더합니다: 인터넷상의 77,484,057개 소프트페일 레코드 중, 그 뒤에 강제하는 DMARC 정책을 갖춘 것은 오직 7.1만 개 — 약 11개 중 1개 — 뿐입니다. 나머지 70.4만 개 도메인에서 ~all은 정확히 그 소리 그대로입니다. 그들의 레코드는 위조를 식별하고는 그대로 통과시켜 줍니다.

2024년 의무화가 이 문제를 고치지 않았나?

아닙니다 — 그리고 그 구분은 대부분의 보도가 시사하는 것보다 더 중요합니다. Google과 Yahoo는 2024년 2월 대량 발신자에게 인증을 요구하기 시작했고, Microsoft가 2025년 5월 그 뒤를 따랐습니다: 통과하고 정렬된 SPF 또는 DKIM에 더해, **최소 p=none**의 DMARC 레코드입니다. 이 의무화들은 *강제(enforcement)*까지 요구하는 데는 미치지 못합니다 — ~all, p=none 레코드, 정렬된 DKIM을 갖춘 도메인은 완전히 준수하면서도, 여전히 완전히 스푸핑 가능한 상태로 남습니다. 의무화는 보호가 아니라 서류 작업을 표준화했습니다. 그 강제되지 않은 중간 지대 — 준수하고, 게시되었으며, 위조 가능한 — 이야말로 바로 이 인구조사가 측정하는 격차이며, 이메일 보안에서 가장 큰 집단입니다.

그렇다면 당신의 레코드는 무엇으로 끝나야 하는가?

1. 메일을 보내고 전달이 중요한 경우(뉴스레터, 메일링 리스트, 별칭): 그 뒤에 DMARC p=reject를 둔 ~all — 위에서 권장한 짝짓기입니다.
2. 엄격하게 통제된 설정에서 메일을 보내는 경우: -all이 작동하며 레코드 자체에 정책을 명시합니다. 먼저 발신자를 매핑하세요 — 매핑되지 않은 레코드에 엄격한 종결부를 두면 실제 메일이 깨지거나, 더 나쁜 일이 벌어집니다.
3. 도메인이 결코 메일을 보내지 않는 경우: 지금 당장 -all에 p=reject. 보호할 정당한 것이 존재하지 않으니, 깨질 것도 없습니다.

어느 종결부를 선택하든, 인구조사의 한 줄짜리 교훈은 유효합니다: 한정자(qualifier)는 그것을 강제하는 것만큼만 중요하다. 그 사다리에서 당신이 어디에 서 있는지는 측정 가능합니다.

자주 묻는 질문

SPF ~all과 -all 중 어느 것이 더 나은가요? 보편적으로는 어느 쪽도 아닙니다. 강제하는 DMARC 정책과 함께하는 ~all은 Google의 지침이 권장하는 패턴입니다 — 전달 메일을 깨뜨리지 않으면서 DMARC 평가 수신자에서 동등한 보호를 제공합니다. -all은 엄격하게 통제된 발신자에게 적합합니다. ~all 홀로 — 소프트페일 도메인 11개 중 1개를 제외한 전부의 상태 — 는 약한 선택지입니다.

SPF 소프트페일은 무엇을 의미하나요? ~all은 목록에 없는 서버에서 온 메일이 아마 정당하지 않을 것이나 그래도 받아들여야 하며, 대개 의심을 품고 받아들여야 한다고 수신자에게 알립니다. DMARC 정책이 그 실패에 대해 조치를 취할 때에만 실질적 보호가 됩니다; DMARC 없는 SPF를 참고하세요.

하드페일 -all이 내 전달 이메일을 깨뜨릴까요? 그럴 수 있습니다: 전달은 당신의 메일을 전달자의 서버에서 다시 보내는데, 그 서버는 당신의 SPF에 목록되어 있지 않으므로, 하드페일은 DKIM이나 DMARC가 판단에 들어가기도 전에 거부를 부릅니다. 그 위험이 바로 ~all + p=reject 짝짓기가 존재하는 이유입니다.

이제 Google과 Microsoft가 -all을 요구하나요? 아닙니다. 대량 발신자 의무화는 정렬되고 통과하는 인증과 최소 p=none의 DMARC 레코드를 요구합니다 — 강제도, 특정 한정자도 아닙니다. Google의 미준수 대량 메일 거부는 시행 중입니다; Microsoft는 실패를 정크 처리해 오며 전면 거부 쪽으로 나아가고 있습니다. 준수는 보호가 아닙니다.

당신의 레코드가 무엇으로 끝나는지 — 그리고 그 뒤에 무엇이 서 있는지 확인하세요

두 번의 조회로 두 가지 모두를, 무료로, 30초 만에 알 수 있습니다. 만약 당신이 강제되지 않은 어깨 으쓱 70.4만 개 중 하나라면, 그 해법은 구매가 아니라 DNS 레코드입니다.

내 도메인 확인하기 → · SPF 고치기 → · DMARC 고치기 → · SPF 성숙도 모델 → · +all 지도 → · 집계 데이터만 사용. 데이터는 EU에서 저장 및 처리됩니다.