SPF란 무엇이며, SPF 레코드는 어떻게 고치나요? (2026)

Q: SPF 레코드는 어떻게 생겼나요?

v=spf1 include:_spf.google.com -all과 같은 단일 DNS TXT 레코드입니다. include: 항목은 승인된 발신자이고, 끝의 -all은 그 외 모든 것을 거부합니다.

Q: ~all과 -all 중 어느 것이 더 나은가요?

-all(하드페일)이 더 강력합니다. 수신자에게 목록에 없는 발신자를 거부하라고 지시합니다. ~all(소프트페일)은 보통 메일을 그대로 전달합니다. 2026-06-29 기준, SPF 레코드의 39.3%가 -all을 사용하고 55.8%가 ~all을 사용합니다.

게시일 2026-07-01

2026-06-29 기준 수치 · 방법론 v7. 등급이 매겨진 261백만 개 도메인 전반의 종합 인구조사 데이터입니다. SPF(Sender Policy Framework)는 어떤 서버가 당신의 도메인으로 메일을 보낼 수 있는지를 나열하는 DNS 레코드입니다. 등급 산정 방식을 참고하세요.

SPF는 “이 서버들은 나를 대신해 이메일을 보낼 수 있으니, 그 외의 것은 모두 의심스러운 것으로 취급하라”고 말하는 DNS의 한 줄입니다. 261백만 개 도메인 중 **53.21%**가 SPF 레코드를 게시합니다. 건전해 보이지만, 레코드 자체만으로는 당신을 보호하지 못합니다. *종결 한정자(terminal qualifier)*가 목록에 없는 발신자를 거부할지 그냥 통과시킬지를 결정하며, 상당수의 레코드는 너무 느슨하게 설정되어 있어 아무런 변화도 주지 못합니다. SPF가 실제로 하는 일, 우리가 가장 자주 보는 실수, 그리고 당신의 SPF를 고치는 방법을 소개합니다.

SPF 레코드란 무엇인가요?

메일 서버가 당신의 도메인에서 온 것이라고 주장하는 메시지를 받으면, 당신의 SPF 레코드를 조회하여 발신 서버가 승인된 목록에 있는지 확인합니다. 레코드는 목록에 없는 모든 것에 대한 지시로 끝납니다.

-all(하드페일(hardfail)) — 목록에 없는 발신자를 거부합니다. 진지하게 임하겠다는 뜻의 설정입니다.
~all(소프트페일(softfail)) — 수신하되 의심스러운 것으로 표시합니다. 대부분의 메일은 여전히 전달됩니다.
?all(중립(neutral)) — 아무것도 하지 않습니다. 의견이 없는 것과 같습니다.
+all — 누구로부터든 무엇이든 수신합니다. 이는 적극적으로 위험하며 절대 게시해서는 안 됩니다.

SPF를 게시한 139백만 개 도메인 중, 엄격한 -all을 사용하는 곳은 **39.3%**에 불과하고, 더 느슨한 ~all을 사용하는 곳은 **55.8%**입니다. 그리고 **36,014**개 도메인은 +all을 게시하는데, 이는 누구든 자기 도메인으로 발신할 수 있다고 전 세계에 알리는 공개 초대장입니다.

SPF를 조용히 망가뜨리는 실수들

DNS 조회가 너무 많음. SPF는 조회 횟수가 10회로 제한되어 있으며(RFC 7208), 이를 초과하면 전체 레코드가 “permerror”로 실패하여 무시됩니다. **7,958**개 도메인(SPF 보유 도메인의 0.01%)이 이 한도를 초과하는데, 대개 서드파티 발신자를 위한 include: 구문을 너무 많이 연결한 탓입니다.
+all 게시. 드물지만 치명적입니다. SPF를 완전히 무력화하고 위조자를 승인하는 셈입니다.
SPF가 사칭을 막아준다는 착각. 그 자체만으로는 막지 못합니다. SPF는 기술적인 발신 경로를 확인할 뿐, 사람이 보는 “From” 주소를 확인하지 않습니다. 전체 도메인 중 **32.4%**가 SPF는 게시하지만 DMARC가 없어, 눈에 보이는 발신자는 여전히 위조될 수 있습니다. SPF는 배관이고, DMARC 시행이 자물쇠입니다. DMARC 없는 SPF를 참고하세요.

SPF 레코드는 어떻게 고치나요?

SPF 레코드를 하나만 게시하세요 — v=spf1로 시작하는 단일 TXT 레코드입니다. 절대 두 개를 게시하지 마세요. 자동으로 실패 처리됩니다.
모든 정당한 발신자를 나열하세요 — 메일함 제공업체, 마케팅 플랫폼, CRM, 헬프데스크 등을 이들이 문서화한 include: 값을 사용해 나열하세요.
목록이 완전하다고 확신하면 -all로 끝내세요. 안전 여유가 필요하면 ~all로 시작한 뒤 점차 조여 나가세요. SPF 고치기를 참고하세요.
조회 횟수를 10회 미만으로 유지하세요 — 한도에 근접했다면 include를 평탄화하거나 통합하세요.
그다음 DMARC를 추가하세요 — SPF와 DKIM은 DMARC에 입력되며, DMARC야말로 누군가가 당신의 도메인으로 이메일을 보내는 것을 실제로 막아주는 통제 수단입니다.

자주 묻는 질문

SPF 레코드는 어떻게 생겼나요? v=spf1 include:_spf.google.com -all과 같은 단일 DNS TXT 레코드입니다. include: 항목은 승인된 발신자이고, 끝의 -all은 그 외 모든 것을 거부합니다.

~all과 -all 중 어느 것이 더 나은가요? -all(하드페일)이 더 강력합니다. 수신자에게 목록에 없는 발신자를 거부하라고 지시합니다. ~all(소프트페일)은 보통 메일을 그대로 전달합니다. 2026-06-29 기준, SPF 레코드의 39.3%가 -all을 사용하고 55.8%가 ~all을 사용합니다.

SPF가 사람들이 내 도메인을 스푸핑하는 것을 막아주나요? 그 자체만으로는 아닙니다. SPF는 눈에 보이는 “From” 주소를 관장하지 않습니다. DMARC를 시행하도록 설정해야 합니다. 도메인의 32.4%가 SPF는 있지만 DMARC가 없어 여전히 스푸핑에 취약합니다.

내 SPF 레코드는 제대로 보이는데 왜 “실패”하나요? 대개 10회 조회 한도를 초과하여 permerror를 반환하기 때문입니다. SPF 보유 도메인의 0.01%가 이 문제에 부딪힙니다. include: 조회 횟수를 줄이세요.

SPF를 고치는 데 비용이 많이 드나요? 아니요, 무료 DNS 변경입니다. 노력이 드는 부분은 발신자 목록을 완전하고 정확하게 만드는 것이지, 돈이 아닙니다.

당신의 도메인 SPF를 무료로 확인하세요

당신의 SPF 레코드와 그 종결 한정자, 그리고 완전한지 여부를 확인하세요 — 비공개로, 소유자 전용으로.

내 도메인 확인하기 → · SPF 고치기 → · DMARC 고치기 → · 등급 산정 방식 → · 종합 데이터만 사용합니다. 데이터는 EU에서 저장 및 처리됩니다.