Defaults.Exposed

Defaults.Exposed수정Guides

누군가 귀사 도메인에서 이메일을 보내고 있습니다: 긴급 대응 가이드 (2026)

게시일 2026-07-08

기준일: 2026-06-29 · 방법론 v7. 261백만 개 등급 도메인에 대한 집계 센서스 데이터. 등급 산정 방식을 참고하세요.

먼저 가짜 이메일이 정확한 귀사 도메인을 사용하는지 유사 도메인을 사용하는지 확인하세요. 수정 방법이 완전히 다르기 때문입니다. 정확한 도메인 스푸핑은 DNS에서 차단할 수 있습니다 — 그리고 대부분의 도메인은 이것을 하지 않았습니다: Defaults.Exposed의 261,086,232 등급 도메인 센서스에 따르면 89.41%가 집행된 DMARC 정책이 없고, 46.4%는 SPF를 전혀 게시하지 않습니다.

이것은 사고 체크리스트입니다: 첫 한 시간 — 악화시키지 않고 무슨 일이 일어나고 있는지 확인; 첫 하루 — 열린 문을 닫거나, 문이 귀사 것이 아닌 경우 삭제 시작; 첫 주 — 모니터링, 피해 가능성 있는 사람들에게 경고, 집행. 이것이 일어날 수 있는지 궁금하다면? 누군가 내 도메인을 스푸핑할 수 있나요?로 시작하세요 — 이 페이지는 이미 일어나고 있을 때를 위한 것입니다.

먼저: 정말 귀사 도메인인가요, 아니면 모방 도메인인가요?

가짜 이메일 하나를 구해 발신자 주소를 문자 하나하나 읽으세요. 이후 모든 것이 이것에 달려 있습니다:

From 주소가 보여주는 것무슨 일이 일어나고 있는지귀사의 경로
[email protected] — 정확히 맞게 철자된 귀사 도메인스푸핑: 낯선 서버가 From 줄에 귀사 도메인을 위조하고 있습니다. 귀사 시스템은 해킹되지 않았습니다.DNS 수정 — SPF, DKIM, 집행된 DMARC. 경로 1.
[email protected], yourcompany-billing.com, yourcompany.co — 비슷하지만 귀사 것이 아님다른 사람이 등록한 유사 도메인. 귀사 DNS는 조회되지 않습니다.삭제 + 경고. 경로 2.
정확한 귀사 주소이며 메시지가 귀사 보낸 편지함에 있거나 실제 스레드에 회신됨계정 침해 — 누군가 실제 사서함 안에 있습니다. 별개의 사고입니다.비밀번호 변경, 세션 취소, 2FA 활성화, 전달 규칙 확인 — 다른 무엇보다 먼저.

데이터 기준: 2026-06-29.

굵게 표시된 행이 가장 일반적이며 가장 수정하기 쉽습니다. 이메일의 핵심 프로토콜은 From 줄을 검증한 적이 없습니다 — 누구든 귀사 도메인을 그 줄에 입력할 수 있습니다 — 따라서 수정 방법은 수신자가 스스로 확인할 수 있는 DNS 레코드를 게시하는 것입니다. 불편한 센서스 숫자: 261,086,232 등급 도메인 중 121,145,609개(46.4%)가 SPF 레코드를 전혀 게시하지 않으며, SPF를 게시하는 138,927,207 도메인 중 36,014개가 +all로 끝납니다 — 말 그대로 전 인터넷이 자신들로 발송하는 것을 승인하는 것입니다(기준: 2026-06-29).

첫 한 시간: 반응하지 말고 확인하세요

  1. defaults.exposed에서 무료 검사를 실행하세요. 30초, 가입 불필요. DNS를 건드리기 전에 귀사 도메인이 현재 스푸핑이 가능한지 알려줍니다 — SPF가 있고 엄격한지, DMARC가 집행되는지.
  2. 가짜 이메일에 회신하지 말고, 그 안의 링크를 클릭하지 말고, 아직 연락처에 대량 이메일을 보내지 마세요. 같은 도메인에서 보낸 공황적인 “우리 이메일을 무시하세요!” 메시지는 정확히 사기처럼 보입니다. 경고는 나중에, 타겟을 정해 대역 외로 합니다.
  3. 전체 헤더가 포함된 샘플을 하나 수집하세요. 수신자에게 가짜 이메일을 첨부 파일로 전달해 달라고 요청하세요(Gmail: “원본 보기” → 다운로드; Outlook: “메시지 소스 보기”). From 줄의 스크린샷은 충분하지 않습니다 — 헤더가 이후 모든 것의 증거입니다.
  4. 수신 서버가 이미 내린 판정을 읽으세요. 헤더에서 Authentication-Results:를 찾으세요 — 정확한 귀사 도메인에 대한 dmarc=fail귀사 도메인의 스푸핑을 확인하고; header.from=의 유사 도메인은 경로 2를 확인합니다. 한 가지 주의: 수신자는 수신자가 보는 From 헤더가 아닌 Return-Path 도메인(RFC5321.MailFrom, 바운스 주소)에 대해 SPF를 평가합니다 — 스푸핑된 메일은 심지어 스패머의 도메인에 대해 spf=pass를 보여주면서 귀사 것을 From에 위조할 수 있습니다. DMARC의 정렬 검사가 정확히 그 간격을 닫습니다.

경로 1 — 정확한 귀사 도메인: 첫 하루

귀사 정확한 도메인을 스푸핑하는 것은 귀사 DNS가 수신자가 거부할 수 있는 것을 전혀 말하지 않는 동안에만 가능합니다. 오늘 세 가지 레코드를 게시(또는 강화)하고 집행은 이번 주에 걸쳐 이루어집니다.

  1. SPF: 실제 발송자를 나열하고 -all(“다른 모든 곳: 실패”)로 끝나는 레코드를 하나 게시하세요. 귀사 것이 +all 또는 ?all로 끝난다면 먼저 그것을 수정하세요 — 귀사가 직접 게시한 열린 문입니다. 가이드: SPF 수정 방법, GoDaddy 클릭 경로 GoDaddy의 SPF.
  2. DKIM: 이메일 공급업체와 모든 뉴스레터/인보이스 도구에서 도메인 서명을 활성화하세요(보통 각각 CNAME 레코드 몇 개).
  3. DMARC: 오늘 v=DMARC1; p=none; rua=mailto:...를 게시하여 보고서가 흐르기 시작하게 하세요; p=reject는 이번 시간이 아닌 이번 주 프로젝트입니다 — 전체 참고: DMARC 수정 방법. 도메인이 합법적인 이메일을 전혀 보내지 않는다면 — 오래된 브랜드, 주차된 도메인 — 주의를 건너뛰고 오늘 잠그세요: 리브랜딩할 때 남긴 그 오래된 도메인은 열어둔 문입니다.

긴장을 풀기 전에 솔직한 주의 사항: 집행된 DMARC 정책은 수신 서버에 정확한 도메인 위조를 정크 처리하거나 거부하도록 지시합니다 — 그리고 대형 공급업체들은 이를 준수합니다. 하지만 이것은 확인하는 수신자들에게만 적용되며, 유사 도메인에 대해서는 전혀 효과가 없습니다: 범죄자들이 yourcompany.com으로 발송할 수 없게 되면, yourcompany-billing.com을 등록하는 데 몇 유로밖에 들지 않습니다. DMARC는 공격을 축소하지만 이야기를 끝내지는 않습니다 — 첫 주 단계도 귀사에게 중요합니다.

경로 2 — 유사 도메인: 이것은 DNS 수정이 아닙니다

귀사 도메인에 게시하는 어떤 레코드도 귀사가 소유하지 않은 도메인에서 오는 메일에 영향을 주지 않습니다 — 귀사 DNS의 어떤 것도 조회되지 않습니다. 플레이북은 삭제 plus 경고입니다:

  1. 유사 도메인 뒤에 있는 사람을 찾으세요. RDAP/WHOIS(예: lookup.icann.org)에서 조회하여 등록기관을 확인하고 웹사이트를 호스팅하는지 확인하세요.
  2. 전체 헤더 샘플을 첨부하여 등록기관의 악용 신고처에 신고하세요 — 등록기관은 매일 피싱 도메인을 정지시키고, 명확한 증거는 처리를 빠르게 합니다. 피싱 사이트라면? 호스트, Google 세이프 브라우징, Microsoft SmartScreen에도 신고하세요.
  3. 수신 사서함에서 이메일을 피싱으로 신고하세요(Gmail/Outlook “피싱 신고”) — 이것은 어떤 편지보다 빠르게 유사 도메인에 대한 대형 필터를 훈련시킵니다.
  4. 가능성 있는 대상에게 대역 외로 경고하세요 — 실제로 돈이 나가는 것을 막는 단계. 고객, 공급업체, 경리에게 전화하거나 메시지를 보내세요(이메일만 보내지 마세요): 가짜 도메인을 알리고, “귀사에서 온” 어떤 은행 계좌 변경도 전화로 확인 가능하게 하세요. 그 습관이 들으신 인보이스 사기 이야기에 대한 최선의 방어입니다.
  5. 유사 도메인이 귀사 상표를 침해한다면, UDRP 이의신청으로 도메인을 양도받을 수 있습니다 — 삭제보다 느리지만 영구적입니다.

그리고 어찌됐든 경로 1도 실행하세요: 공격자들은 실제 도메인이 아직 열려 있는 동안 유사 도메인을 쓸 이유가 별로 없습니다. 89.41%의 도메인에 집행된 DMARC가 없습니다(기준: 2026-06-29, 전체 261,086,232 중 27,640,987개만 — 10.59% — 집행 중). 상관없이 귀사의 문을 닫으세요.

첫 주: 모니터링, 경고, 집행

  1. DMARC 보고서를 읽으세요. rua= 태그가 작동하고 하루 이틀 후 집계 보고서가 귀사 도메인으로 발송하는 모든 서버를 보여줍니다 — 실제 서버와 스푸퍼, 발송량과 판정 포함. 이것이 공격이 사라지는 것을 지켜보는 방법입니다.
  2. 합법적인 발송자가 통과하는지 확인하세요. 모든 실제 발송 소스(메일 공급업체, 뉴스레터 도구, 인보이스 앱, 웹사이트 연락처 양식)가 집행하기 전에 귀사 도메인과 정렬된 SPF 또는 DKIM을 통과해야 합니다 — 그렇지 않으면 reject가 귀사 자신의 메일도 차단합니다.
  3. DMARC를 p=quarantine, 그런 다음 p=reject로 단계적으로 강화하세요. 활성 스푸핑 상황에서는 보통 몇 달을 일주일 또는 이주일로 압축합니다 — 하지만 단계를 압축하는 것이지 건너뛰는 것이 아닙니다. 단계적 롤아웃, pct 증가, 서브도메인 정책: 합법적인 이메일을 잃지 않고 p=none에서 p=reject로.
  4. 가짜 이메일을 받았을 수 있는 거래처에 차분하고 타겟을 정한 공지 하나를 보내세요: 무슨 일이 있었는지, 가짜 이메일이 무엇을 요청했는지, 결제 변경에 대한 전화 확인 규칙, 그리고(경로 2의 경우) 차단할 정확한 유사 도메인.
  5. 재검사하고 보고서를 보관하세요. 보험사와 고객들이 점점 더 이메일 보안에 대해 무엇을 했는지 묻습니다; 날짜가 기재된 등급 보고서가 서면으로 답합니다.

자주 묻는 질문

내 주소로 발송된 사기 이메일을 받았습니다. 해킹당한 건가요? 거의 항상 아닙니다 — “귀사에서 귀사로” 협박 메일은 귀사 도메인이 가짜를 거부하지 않는다는 사실을 이용하는 동일한 위조 트릭입니다. 보낸 편지함과 최근 로그인을 확인하세요; 깨끗하면 스푸핑이고, 집행된 DMARC 정책이 그것을 준수하는 수신자에서 그 변형을 차단합니다. 2026-06-29 기준으로, 261,086,232 등급 도메인 중 89.41%가 이것을 하지 않았습니다.

DMARC가 유사 도메인 이메일을 차단할까요? 아니오. 귀사의 DMARC 정책은 정확한 귀사 도메인(및 서브도메인)만 관장합니다 — 유사 도메인은 귀사 레코드와 전혀 비교되지 않는 자체 DNS를 가진 다른 사람의 도메인입니다. 유사 도메인은 DNS가 아닌 등록기관 악용 신고, 피싱 신고, 거래처 경고로 대응합니다.

p=reject가 실제로 얼마나 빨리 스푸핑을 차단할까요? DNS 변경은 몇 시간 안에 수신자에게 도달하며, Gmail, Outlook 및 대부분의 주요 공급업체는 DMARC 판정을 준수합니다 — 정책이 적용되는 날부터 정확한 도메인 위조가 사라지기 시작합니다. 두 가지 솔직한 한계: DMARC를 확인하지 않는 소규모 수신자는 여전히 가짜를 전달할 수 있으며, 귀사 자신의 발송자가 정렬되기 전에 집행하면 합법적인 메일도 차단됩니다 — 단계를 가속화하되 건너뛰지 마세요.

보고서를 담당자에게 전달하세요

이것을 처리하는 IT 계약업체라면: 레코드가 작동하면 검사를 다시 실행하고 등급 보고서를 비즈니스 오너에게 전달하세요. 일반 언어로 스푸핑이 일어난 이유, 변경한 내용, 현재 도메인 상태를 보여줍니다 — “이제 안전한가요?”에 대한 서면 답변이자, 보험 갱신이나 고객 설문지의 증거. 오너라면: 정확히 그 보고서를 요청하고, 이전과 이후를 보관하세요.

귀사 도메인이 스푸핑 가능한지 무료로 확인하세요

낯선 서버가 현재 귀사를 사칭할 수 있는지 — 그리고 정확히 무엇을 수정해야 하는지 — 비공개로, 소유자만 확인하세요.

도메인 확인하기 → · p=none에서 p=reject로 → · DMARC 수정 → · 누군가 내 도메인을 스푸핑할 수 있나요? → · 집계 데이터만 사용. 데이터는 EU 내에서 저장 및 처리됩니다.