Defaults.Exposed

Defaults.Exposed › 수정 › SPF (Sender Policy Framework)

SPF (Sender Policy Framework) 수정 방법

SPF는 도메인 설정에 등록하는 한 줄의 코드로, 어떤 메일 서비스가 귀사 명의로 이메일을 발송할 수 있는지 목록화합니다. 이 설정이 없으면 전 세계 누구나 귀사에서 보낸 것처럼 이메일을 발송할 수 있으며, 실제로 귀사가 보내는 이메일은 고객의 스팸함에 빠질 가능성이 높아집니다.

비즈니스에 미치는 핵심 영향: 범죄자가 귀사 명의로 고객, 직원, 공급업체에게 이메일을 보낼 수 있습니다. 청구서 위조, 결제 정보 변경 요청 등 모든 종류의 사기가 가능합니다. 동시에 귀사가 실제로 발송한 견적서와 청구서는 스팸으로 걸러질 가능성이 높아져 거래가 조용히 끊어질 수 있습니다.

발생 가능한 비용

중요한 이유. 이메일의 발신자 주소를 위조하는 것은 매우 쉽고 공격자에게 아무런 비용도 들지 않습니다. SPF는 가장 빠르고 저렴하게 도메인 사칭을 어렵게 만들고 정상 메일을 스팸에서 보호하는 수단입니다. Google과 Yahoo는 이제 인증되지 않은 도메인의 메일을 적극적으로 차단하거나 거부하므로, 이 설정은 선택이 아닌 기본 필수 조건이 되었습니다.

핵심 요약

현재 SPF가 올바르게 설정되어 있지 않다면, 전 세계 누구나 귀사 명의의 이메일을 발송할 수 있습니다. 고객에게 가짜 청구서를 보내고, 직원에게 허위 결제 요청을 보내고, 공급업체에게 귀사인 척 연락할 수 있습니다. 도메인 자체가 이를 막을 장치가 없기 때문에 메일은 진짜처럼 보입니다.

SPF(Sender Policy Framework)가 바로 해결책입니다. 도메인 DNS 설정에 어떤 메일 서비스가 귀사 명의로 발송할 권한이 있는지를 나열하는 텍스트 한 줄을 추가합니다. Gmail, Outlook 등 수신 메일 공급업체는 이 목록을 확인한 후 메일의 진위 여부를 판단합니다.

이 페이지는 두 가지를 모두 올바르게 설정해야 한다는 점을 다룹니다: SPF 레코드 존재 여부와 충분히 엄격한 정책 설정 여부.

비즈니스 피해 사례

SPF가 없거나 취약할 때 실제로 발생하는 피해 유형입니다.

SPF란 무엇인가

메일이 수신될 때 수신 서버는 한 가지를 확인합니다: 이 메일이 정말 주장하는 발신자에게서 온 것인가? SPF가 그 질문에 부분적으로 답합니다.

도메인 DNS 설정에 다음과 같은 짧은 TXT 레코드를 등록합니다:

v=spf1 include:_spf.google.com include:sendgrid.net -all

쉽게 말하면: “귀사의 정상 메일은 Google 서버와 SendGrid 서버에서 발송됩니다. 다른 곳에서 귀사 명의로 온 메일은 거부하세요.”

등급에 영향을 주는 두 가지 요소:

  1. 레코드가 존재하는가? 레코드가 없으면 수신자가 확인할 목록이 없으므로 사칭이 가능합니다. SPF 레코드가 두 개 이상 존재하면 모두 무효가 됩니다.

  2. 정책이 충분히 엄격한가? 레코드가 있어도 효력이 없을 수 있습니다:

    • -all (하드 페일) — 목록에 없는 발신자 거부. 가장 강력. 만점.
    • ~all (소프트 페일) + DMARC reject — 현대적 권장 설정. 만점.
    • ~all + DMARC quarantine — 허용 가능하나 약간 약함.
    • ~all 단독 (DMARC 없음) — 취약. 사칭 메일이 여전히 통과됩니다.
    • ?all (중립) — 아무런 보호 없음.
    • +all — 매우 위험: 전 세계 누구나 귀사 명의로 발송 가능. 절대 사용 금지.

SPF 평가 시 최대 10번의 DNS 조회만 허용됩니다. 많은 SaaS 도구를 사용하면 이 한도를 초과해 레코드 전체가 무효화됩니다.

수정 방법 (무료, 약 10분)

도메인이나 웹사이트를 관리하는 담당자에게 이 섹션을 전달하세요. 수정은 무료입니다.

1단계 — 귀사 명의로 메일을 발송하는 모든 서비스 파악. 메일박스 공급업체(Google Workspace, Microsoft 365 등), 뉴스레터 도구, CRM, 헬프데스크, 이커머스 플랫폼, 청구서/회계 앱, 예약 시스템 등을 모두 작성하세요.

2단계 — 루트 도메인에 TXT 레코드 하나 등록. 모든 발신자의 “include” 줄을 하나의 레코드로 합칩니다:

조합 예시:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

공급업체별 등록 위치:

3단계 — 안전하게 시작한 후 강화. 발신자 목록이 완전한지 확인하는 동안 ~all(소프트 페일)로 시작합니다. 정상 메일이 모두 잘 전달되는 것을 확인한 후 -all로 강화하거나 ~all + DMARC p=reject 조합을 사용합니다.

4단계 — 레코드가 정확히 하나인지 확인. 기존 SPF 레코드가 있다면 새로 추가하지 말고 기존 것을 수정하세요.

5단계 — 조회 횟수 확인. 발신자가 많으면 10회 한도를 초과할 수 있습니다.

6단계 — 도메인 재확인. 레코드가 정상이고 정책이 충분히 강한지 확인합니다.

흔한 실수

전체 그림에서의 위치

SPF는 기반이지만 세 계층 중 하나입니다. DKIM은 메시지가 변조되지 않았음을 증명하는 암호화 서명을 추가하고, DMARC는 SPF와 DKIM을 하나로 묶어 실패한 메일에 대한 처리 지시를 내립니다. SPF부터 올바르게 설정한 뒤(가장 빠른 효과, 가장 높은 가중치) DKIM과 DMARC를 추가하세요. 세 가지 모두 무료입니다.

호스트에서 설정하기

주요 제공업체별 단계별 안내:

FAQ

기술적 지식이 없는데 직접 처리할 수 있을까요?

세부 내용을 이해하지 않아도 됩니다. 도메인 설정에 한두 줄을 추가하는 작업으로, 웹사이트나 IT를 관리하는 담당자가 몇 분 만에 처리할 수 있습니다. 아래의 '수정 방법' 섹션을 전달하면 됩니다. 비용은 무료입니다.

이미 SPF 레코드가 있으면 보호받고 있는 건가요?

반드시 그렇지는 않습니다. 레코드가 존재하는 것이 첫 번째이고, 충분히 엄격하게 설정되어 있는지가 두 번째입니다. 레코드 끝이 '~all'(소프트 페일)이고 DMARC가 없다면, 수신 서버에게 '가짜일 수 있지만 그래도 배달하라'는 지시가 됩니다. 두 개 이상의 SPF 레코드가 있거나 DNS 조회 횟수 초과 시 모두 무효화되어 보호가 사라집니다.

수정하면 실제 발송 메일이 차단될 수 있나요?

정상 발신자를 모두 목록에 포함하지 않으면 그럴 수 있습니다. 청구서 앱, 뉴스레터 도구 등 귀사 명의로 메일을 보내는 모든 서비스를 먼저 등록하고, 이상이 없음을 확인한 뒤 정책을 강화하는 순서가 안전합니다.

'~all'과 '-all'의 차이는 무엇이며 어느 것을 써야 하나요?

'-all'(하드 페일)은 목록에 없는 발신자를 거부합니다. 가장 강력한 설정입니다. '~all'(소프트 페일)은 '정상이 아닐 수 있지만 그래도 수락'이라는 의미입니다. 현대적 권장 설정은 '~all'과 DMARC 정책 'reject'의 조합으로, 전달 메일이 반송될 위험 없이 '-all'과 동일한 보호를 제공합니다.

SPF만으로 이메일 사칭을 완전히 막을 수 있나요?

아닙니다. SPF는 필수적인 첫 번째 계층이지만 전부는 아닙니다. 완전한 사칭 방지를 위해서는 DKIM과 DMARC도 필요합니다. SPF부터 시작해 나머지 두 가지를 추가하는 것을 권장합니다.

적용까지 얼마나 걸리며 비용이 드나요?

DNS 변경은 보통 수 분에서 몇 시간 이내에 적용됩니다. 수정 자체는 항상 무료입니다. DNS 공급업체에서 설정값을 수정하는 것뿐입니다.