Defaults.Exposed › 수정 › DMARC (이메일 사칭 방지)

DMARC (이메일 사칭 방지) 수정 방법

DMARC는 전 세계 메일 공급업체에게 귀사 비즈니스 이름을 위장한 이메일을 차단하도록 실제로 지시하는 단 하나의 설정입니다. SPF와 DKIM은 자물쇠를 확인합니다; DMARC는 위조가 검사에 실패했을 때 무엇을 할지 결정합니다 — 버리거나, 표시하거나, 통과시키거나. 잘못 설정하면 도메인이 완전히 위조 가능하고; 올바르게 설정하면 사칭이 메일함에서 차단됩니다.

비즈니스에 미치는 핵심 영향: DMARC 집행 없이 범죄자가 정확히 귀사 비즈니스에서 온 것처럼 보이는 이메일을 — 귀사 고객, 직원, 공급업체에게 — 보낼 수 있으며 스팸이 아닌 메일함에 도착합니다. 사람들이 귀사 이름으로 사기를 당하며 귀사를 탓합니다.

발생 가능한 비용

• 사기꾼이 귀사 계정 팀에서 온 진짜 같은 청구서를 고객에게 이메일로 보내며 자신의 은행 계좌 정보를 씁니다. 고객이 지불합니다. 이미 지불한 상품을 추적할 때 몇 주 후에 알게 됩니다 — 고객이 귀사를 책임지게 합니다.
• '긴급 결제' 이메일이 귀사, 소유자에게서 온 것처럼 보이며 귀사 재무 담당자에게 갑니다. 아무도 다시 확인할 생각을 하기 전에 돈을 보냅니다 — 범죄자 계좌에 들어간 돈은 거의 회수되지 않습니다.
• 큰 잠재 고객의 IT 팀이 서명 전 귀사 도메인에 대한 보안 확인을 실행합니다. '이메일이 보호되지 않음 — 사칭 가능'으로 돌아옵니다. 귀사는 통과한 경쟁사에게 거래를 잃습니다.
• 귀사 도메인이 피싱 파도에 사용됩니다. 속은 고객들이 화난 리뷰를 남기고 다른 사람에게 경고합니다. 평판 손상이 공격보다 몇 달 더 지속됩니다.
• 귀사 진짜 이메일조차 스팸으로 분류되기 시작합니다. 왜냐하면 Google과 Yahoo가 집행된 DMARC가 없는 도메인을 점점 더 불신하고 이제 때로는 거부하기 때문입니다.

중요한 이유. 이메일은 실제로 누가 보냈는지 증명하도록 구축된 적이 없으므로 '보낸 사람' 주소를 위조하는 것은 쉽습니다. DMARC는 '가짜를 감지할 수 있다'를 '가짜가 차단된다'로 바꾸는 유일한 제어입니다 — 또한 귀사 브랜드로 이메일을 보내는 모든 사람을 드러내는 일일 보고를 제공합니다. 큰 메일함 공급업체들이 이제 없거나 집행되지 않은 DMARC 정책을 귀사에 반하는 신뢰 신호로 취급하므로 귀사 이메일 배달에도 영향을 미칩니다.

쉬운 설명

이메일에는 더러운 비밀이 있습니다: ‘보낸 사람’ 줄은 그냥 입력한 텍스트입니다. 어디서든 누구나 이메일의 ‘보낸 사람’ 필드에 귀사 비즈니스 이름과 주소를 쓰고 보낼 수 있습니다. 인터넷은 그것을 막도록 설계된 적이 없습니다.

함께 이것을 고치는 세 가지 설정이 있습니다. 건물의 보안으로 생각하세요:

• SPF는 누가 앞문으로 들어올 수 있는지의 목록입니다(어떤 메일 서비스가 귀사로서 보낼 수 있는지).
• DKIM은 메시지가 전송 중에 변경되지 않았다는 것을 증명하는 변조 방지 봉인입니다.
• DMARC는 목록과 봉인을 확인하는 보안 경비원입니다 — 그리고 중요하게, 일치하지 않을 때 무엇을 할지 결정합니다: 통과시키거나, 스팸으로 보내거나, 문 앞에서 돌려보내거나.

목록(SPF)과 봉인(DKIM)을 가지고도 경비원이 없을 수 있습니다. 그것이 가장 일반적이고 가장 위험한 상황입니다: 자물쇠가 존재하지만 아무것도 집행하지 않습니다. DMARC가 집행입니다. “이 이메일이 가짜라는 것을 알 수 있다”와 “이 가짜 이메일이 절대 고객에게 도달하지 않는다”의 차이입니다.

비즈니스 피해 사례

이것은 이론적이 아닙니다. 보호되지 않은 도메인이 실제 돈과 실제 피해로 어떻게 변하는지:

1. 가짜 청구서 사기. 범죄자가 고객에게 귀사 계정 팀에서 온 진짜 같은 청구서 — 같은 이름, 같은 도메인, 전문적인 레이아웃 — 이지만 자신의 은행 계좌 정보를 이메일로 보냅니다. 도메인이 집행되지 않아 스팸이 아닌 메일함에 도착합니다. 고객이 지불합니다. 주문이 어디 있는지 물을 때 몇 주 후에 발견합니다. 돈은 대개 사라지고 고객은 종종 귀사를 침해에 대해 책임있게 합니다.

2. CEO 사기 전신 이체. 귀사, 소유자로부터 재무 담당자에게 이메일이 보이는 것처럼: “이 결제를 급하게 처리해 주실 수 있나요, 회의 중입니다.” 귀사 주소이기 때문에 완전히 진짜 같아서 완전히 진짜입니다 — 단지 위조되었을 뿐. 결제가 나갑니다. 이 패턴 — 비즈니스 이메일 침해 — 은 이메일이 진짜로 귀사 도메인에서 오기 때문에 의심을 깨끗이 통과하여 소규모 비즈니스를 강타하는 가장 비싼 사기 중 하나입니다.

3. 잃은 계약. 진지한 잠재 고객이 서명 전에 보안 또는 구매 확인을 실행합니다. 도구가 도메인을 “사칭 가능 — 이메일 인증 집행 없음”으로 보고합니다. 그 단일 빨간 표시가 통과한 경쟁사에게 계약을 수여하기에 충분할 수 있습니다. 진짜 이유를 절대 듣지 못합니다.

4. 되돌릴 수 없는 평판 손상. 도메인이 피싱 캠페인에 쓸려 들어갑니다. 속은 수십 명이 경고와 리뷰를 게시합니다. 공격은 일주일 동안 지속되고; “이 회사가 안전한가요?” 질문이 몇 달 동안 지속됩니다.

5. 스팸으로 가는 귀사 이메일. Google과 Yahoo가 이제 집행된 DMARC가 없는 도메인을 적극적으로 불신합니다. 귀사가 진정으로 보낸 견적, 청구서, 답변이 스팸 폴더에 조용히 착지하기 시작합니다. 거래가 지연되고 귀사는 이유를 절대 알지 못합니다.

실제 내용과 “좋은 상태”

DMARC는 도메인 설정에 단일 텍스트 줄로 존재합니다 — 특별한 이름 _dmarc.yourdomain에 게시된 DNS “TXT” 레코드. 그 안에 몇 가지 짧은 지시가 있습니다. 두 가지가 가장 중요하며 정확히 이 평가가 확인하는 두 가지입니다.

1. 정책(p=) — 경비원의 명령. 이것이 검사의 무거운 부분입니다. 세 가지 중 하나일 수 있습니다:

• p=none — 지켜보기만. 경비원이 누가 통과하는지 기록하지만 아무도 막지 않습니다. 아무것도 보호하지 않고; 이것은 모니터링 단계이지 완료된 설정이 아닙니다. (엔진은 이것을 실패로 채점합니다 — DMARC가 없는 것보다 낫지만 보호가 아닙니다.)
• p=quarantine — 가짜를 스팸으로. 실제 보호이지만 결심한 공격자는 사람들이 스팸 폴더를 확인하는 것에 의존합니다. 합리적인 중간 단계 — 대략 절반의 점수를 얻습니다.
• p=reject — 문 앞에서 가짜 거부. 위조된 이메일이 절대 배달되지 않습니다. 이것이 목표이며 만점을 얻는 유일한 설정입니다.

좋은 상태는 **p=reject**입니다. 그 미만은 격차를 남깁니다.

주목할 두 가지 기술적 세부 사항:

• 하위 도메인 정책(sp=). 주 도메인에 강력한 정책을 설정하지만 실수로 하위 도메인(mail.yourdomain 또는 news.yourdomain 같은)을 열어 두를 수 있습니다. p=reject이지만 sp=none인 도메인은 공격자가 단순히 하위 도메인을 사칭하기 때문에 집행이 전혀 없는 것에 가깝게 점수가 낮아집니다.
• 퍼센트(pct=). 신중한 롤아웃 중에 메일의 일부에만 집행을 적용할 수 있습니다(예: pct=25). 그것은 합법적인 전환 도구이지만 부분적인 롤아웃은 부분적인 보호만 제공합니다.

2. 보고 주소(rua=) — 귀사 가시성. 이것이 이 페이지의 두 번째 검사입니다. rua= 태그는 세계의 모든 메일 공급업체에게 귀사 도메인으로 이메일을 보내려 한 사람 — 귀사 시스템 및 사칭자 — 의 일일 요약을 보내달라고 요청합니다. 없이는 눈이 멀어 있습니다: 귀사 이름을 누가 남용하는지 알 방법이 없습니다. 있으면 비즈니스들이 보통 첫날 5~50개의 무허가 발신자를 발견합니다.

좋은 상태는: 보고를 실제로 받는 유효한 rua=mailto: 주소.

수정 방법 (무료, 약 2주에 걸쳐 30분)

도메인, 웹사이트, IT를 관리하는 사람에게 이 섹션을 전달하세요 — 수정은 완전히 무료입니다.

황금 규칙: reject로 바로 점프하지 마세요. 먼저 모니터링을 켜고 보고를 지켜보고 실제 메일이 인식되는지 확인한 다음 강화하세요.

1단계 — SPF와 DKIM이 먼저 있는지 확인. DMARC는 그것들에 의존합니다. 없다면 DMARC를 집행하기 전에 먼저 정리하세요(SPF 및 DKIM 페이지 참조).

2단계 — 보고가 켜진 모니터링 레코드 게시. DNS TXT 레코드 추가:

• 호스트 / 이름: _dmarc.yourdomain(DNS 공급업체에서 단순히 _dmarc로 표시될 수 있음)
• 유형: TXT
• 값: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain; adkim=s; aspf=s

이것은 아직 아무것도 차단하지 않고 지켜보고 보고합니다.

3단계 — 약 2주 동안 보고 읽기. 원시 DMARC 보고서는 밀도 높은 XML입니다. 읽을 수 있는 대시보드로 변환하기 위해 무료 보고 서비스(예: dmarcian 또는 Postmark의 무료 DMARC 도구)를 사용하세요. 모든 합법적인 발신자 — 메일함 공급업체, 뉴스레터 도구, CRM, 헬프데스크, 청구 앱 — 가 통과하는지 확인합니다.

4단계 — 격리로 이동. 실제 메일이 깨끗하면 p=none을 p=quarantine으로 변경합니다. 며칠 더 지켜봅니다.

5단계 — 거부로 이동. 마지막으로 p=quarantine을 p=reject로 변경합니다. 이제 완전히 보호됩니다. 최종 레코드:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain; adkim=s; aspf=s

6단계 — 하위 도메인 잊지 마세요. sp=none을 그대로 두지 않았는지 확인하세요. sp를 전혀 게시하지 않으면 하위 도메인이 주 p= 정책을 상속합니다.

일반 플랫폼별 참고:

• Google Workspace / Microsoft 365: 둘 다 DMARC를 완전히 지원합니다. DMARC 레코드 자체는 Google이나 Microsoft 관리 콘솔이 아닌 DNS 공급업체에 들어갑니다 — 먼저 관리 콘솔에서 SPF와 DKIM을 활성화하고 등록업체/DNS 호스트에서 DMARC TXT 레코드를 게시하세요.
• Cloudflare: DNS → 레코드 → 레코드 추가 → TXT, 이름 _dmarc, 위의 값 붙여넣기.
• 일반 호스트 / 등록업체: “DNS”, “DNS 영역”, 또는 “고급 DNS”를 찾아 이름 _dmarc와 위의 값으로 TXT 레코드를 추가하세요.

흔한 실수

• p=none에서 중단. 단연 가장 일반적인 오류. 모니터링이 시작점이지 마무리가 아닙니다 — none에 고착된 도메인은 여전히 완전히 사칭 가능합니다.
• 모니터링 없이 reject로 바로 점프. 반대 실수. 보고 단계 없이 합법적인 발신자(종종 뉴스레터나 청구 도구)가 정렬되지 않아 자체 메일을 차단하기 시작할 수 있습니다.
• 하위 도메인 정책 잊기. 강력한 p=reject이지만 sp=none은 공격자가 단순히 하위 도메인을 사칭하는 옆문을 열어 둡니다.
• 손상된 보고 주소. 오타가 있는 rua=(또는 mailto: 접두사가 없는)는 보고가 어디에도 가지 않고 알아채지 못하는 채로 눈이 멀어 있음을 의미합니다.
• “이메일을 보내지 않으니 건너뛸 것입니다.” 보내지 않는 도메인이 최우선 표적입니다 — 아무도 지켜보지 않기 때문에. 엄격한 reject 정책을 게시하여 완전히 잠그세요.

채점에 관한 참고

정책 검사(p=)는 전체 평가에서 가장 무거운 항목 중 하나입니다 — 귀사 비즈니스가 사칭될 수 있는지 여부의 단일 최대 요인이기 때문입니다. reject가 만점을 얻습니다; quarantine이 대략 절반을 얻습니다; none과 없는 레코드가 실패로 채점됩니다. 약한 하위 도메인 정책이나 부분적인 pct= 롤아웃은 실제로 보유한 보호 수준에 맞게 점수를 낮춥니다.

보고 검사(rua=)도 실제 무게를 가지지만 체크박스로 생각하기보다 안전하게 reject에 도달할 수 있게 하는 도구로 생각하세요. 모니터링 레코드와 동시에 설정하면 첫날 가시성으로 비용이 지불됩니다.

호스트에서 설정하기

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

• GoDaddy에서 DMARC 설정하기
• Namecheap에서 DMARC 설정하기
• Cloudflare에서 DMARC 설정하기
• Google Workspace에서 DMARC 설정하기
• Microsoft 365에서 DMARC 설정하기
• Squarespace에서 DMARC 설정하기
• Wix에서 DMARC 설정하기
• AWS Route 53에서 DMARC 설정하기
• Hostinger에서 DMARC 설정하기
• Porkbun에서 DMARC 설정하기
• IONOS에서 DMARC 설정하기
• Bluehost에서 DMARC 설정하기

FAQ