합법적인 이메일을 잃지 않고 DMARC p=none에서 p=reject로: 단계적 전환 (2026)

게시일 2026-07-08

2026-06-29 기준 수치 · 방법론 v7. 261백만 개의 평가된 도메인에 대한 집계 데이터. 평가 방식 보기.

DMARC를 p=none에서 p=reject로 4단계로 이동하세요: 2~4주 동안 rua 보고서 모니터링, 모든 합법적인 발신자 수정, pct와 함께 p=quarantine 증가, 그런 다음 reject — 절대 reject로 바로 건너뛰지 마세요. Defaults.Exposed 센서스에 따르면 평가된 261,086,232개 도메인 중 70,368,600개가 소프트 SPF와 DMARC 적용 없이 정체되어 있습니다.

이것은 운영 절차서입니다: 종료 기준이 있는 단계 표, 각 단계의 레코드, reject 시 “50%“가 의미하는 것을 바꾸는 RFC 7489 pct 미묘함, 하위 도메인의 sp= 태그. 적용 여부를 결정하는 경우 먼저 DMARC 성숙도 6단계를 읽으세요 — 그것이 프레임워크입니다; 정책 수준 자체가 새로운 경우 p=none, p=quarantine, p=reject가 실제로 의미하는 것이 입문서입니다. 이 페이지는 실행입니다.

왜 p=reject로 바로 건너뛸 수 없나요?

p=reject는 모든 준수하는 수신자에게 DMARC에 실패하는 메일을 반송하라고 합니다 — 그리고 보고서를 보기 전에는 무엇이 실패하는지 모릅니다. 모니터링을 켜는 거의 모든 도메인이 잊혀진 합법적인 발신자를 발견합니다: CRM, 인보이스 도구, 문의 양식. 1일부터 reject로 건너뛰면 그 메일이 스팸으로 가지 않습니다; SMTP 시점에 사라집니다. 인보이스 발송을 잃으면 조직이 DMARC를 두려워하게 되고 레코드가 영구적으로 p=none으로 롤백됩니다 — 평가된 261,086,232개 도메인 중 37,312,637개가 정확히 거기에 정체되어 있으며 10.59%(27,640,987개)만이 적용된 정책에 도달합니다.

다른 이유는 정렬입니다. DMARC는 SPF 또는 DKIM이 통과하고 그리고 보이는 From 도메인과 정렬될 때만 통과합니다 — Return-Path(RFC5321.MailFrom) 도메인에 대한 SPF, 서명의 d=에 대한 DKIM. 제3자 발신자는 보통 자체 도메인에서 SPF를 통과하고, 여러분의 도메인에서는 아닙니다. 따라서 소스-수정 단계가 주로 각 벤더의 사용자 정의 도메인 DKIM 활성화에 관한 것입니다 — DMARC는 실패하지만 SPF와 DKIM은 통과에서 자세히 설명합니다.

4단계 전환은 무엇인가요?

단계	정책 레코드	pct	실패하는 메일에 일어나는 일	종료 기준
1. 모니터링	`p=none; rua=mailto:…`	—	정상 배달; 집계 보고서 수신	2~4주 보고서; 그 안의 모든 발신자를 합법 여부 식별
2. 소스 수정	`p=none` (변경 없음)	—	여전히 정상 배달	모든 합법적인 소스가 정렬되어 DMARC 통과 (발신자별 사용자 정의 도메인 DKIM); 남은 실패는 알 수 없는/사칭 트래픽만
3. Quarantine 증가	`p=quarantine`	10 → 25 → 50 → 100	샘플링된 부분은 스팸 폴더로; 샘플링 외 부분은 p=none으로 처리 (배달)	pct=100에서 1~2주, 합법적인 메일이 격리되지 않음
4. Reject	`p=reject`	100	SMTP 시점에 반송; 발신자는 반송을 받고 수신자는 아무것도 보지 않음	지속 — 새 발신자를 잡으려면 `rua`를 영구적으로 유지

2026-06-29 기준 데이터; RFC 7489에 따른 정책 동작.

3단계는 도메인이 정체하거나 당황하는 곳입니다. 스팸 폴더에 가는 것은 회복 가능합니다 — 사용자가 메일을 찾고, pct를 낮추고, 소스를 수정합니다. 거부는 회복 가능하지 않으며, pct=100에서 깨끗하게 실행되는 quarantine이 4단계의 입장권인 이유입니다.

단계별로 전환을 어떻게 실행하나요?

DNS를 건드리기 전에 defaults.exposed에서 무료 스캔을 실행하세요. 현재 정책과 SPF 및 DKIM이 아래에 있는지 확인합니다 — 적용이 의존하는 두 레그.
아직 모니터링을 켜지 않았다면 활성화하세요. rua=와 함께 p=none을 게시하는 것이 “DMARC policy not enabled”의 5분 단계입니다. 2~4주 보고서를 수집하세요 — 인보이스 발송 같은 월별 발신자를 잡기에 충분한.
보고서의 모든 소스를 목록화하세요. 발신자를 자체, 벤더, 알 수 없는 트래픽으로 분류하세요. 원시 보고서는 XML로 도착합니다 — 보고서 처리 도구(또는 공급자 대시보드)가 읽을 수 있는 발신자 인벤토리로 변환합니다.
각 합법적인 소스가 정렬되어 통과하도록 만드세요. 각 벤더의 사용자 정의 도메인 DKIM을 활성화하세요(보통 대시보드의 두 CNAME 레코드) 서명이 그들의 도메인이 아닌 여러분의 도메인을 사용하도록. 정렬을 위해 DKIM을 선호하세요: SPF는 안 됩니다만 전달(forwarding)에서 살아남습니다.
깨끗한 2주를 기다리세요. 보고된 실패가 인식하지 못하는 트래픽 — 차단하고 싶은 사칭 — 만 될 때 2단계를 종료하세요.
p=quarantine; pct=10으로 이동하세요 — 기존 _dmarc TXT 레코드를 편집하고(IONOS DMARC 설정 실제 예시), 구문에 주의하세요: 정책 태그의 오타가 레코드를 완전히 무효화할 수 있습니다. 보고서와 헬프데스크 티켓을 감시하면서 2~4주에 걸쳐 pct를 25, 50, 100으로 증가하세요. 스팸에 합법적인 것이 있으면: pct를 낮추고, 소스를 수정하고, 재개하세요.
pct=100에서 1~2주 깨끗하게 실행된 후 p=reject로 이동하세요. rua=를 영구적으로 유지하세요 — 회사가 채택하는 모든 새 도구가 미래의 실패하는 발신자입니다.

pct는 실제로 무엇을 하나요? RFC 7489 미묘함

pct는 수신자에게 그 비율의 실패하는 메일에 정책을 적용하도록 요청합니다. RFC 7489 §6.6.4의 미묘함: 샘플링되지 않는 메일은 “정상 배달”로 폴백하지 않습니다 — 다음으로 덜 심각한 정책을 받습니다. p=quarantine; pct=25 아래에서 다른 75%는 p=none으로 처리되어 배달됩니다. 하지만 p=reject; pct=50 아래에서 다른 50%는 배달되지 않고 격리됩니다. 부드러운 reject는 없습니다: 레코드에 reject가 있는 순간, 준수하는 수신자에서 모든 실패하는 메시지는 최소 스팸 폴더에 들어갑니다.

의도적으로 사용하면 기능입니다 — p=reject; pct=1은 “거의 모든 것을 격리하고, 소수를 reject”로 동작하며, 합법적인 마지막 진입로. 두 가지 주의: 수신자들이 샘플링을 동일하게 구현하지 않으므로 pct를 대략적인 다이얼로 처리하세요; 4단계가 안정되면 태그를 제거하거나 pct=100으로 설정하여 레코드가 의미하는 바를 명시적으로 나타내세요.

하위 도메인은 어떤가요 — sp= 태그?

기본적으로 하위 도메인은 조직 도메인의 정책을 상속합니다: yourdomain.com의 p=reject가 mail.yourdomain.com도 커버합니다. sp= 태그는 유용하고 위험한 두 방향으로 달라지게 합니다. 유용: p=quarantine; sp=reject는 apex가 아직 증가 중인 동안 절대 보내지 않는 하위 도메인을 잠급니다 — 사칭자는 의도적으로 모니터링되는 도메인의 하위 도메인을 표적으로 삼습니다. 위험: 잊혀진 sp=none이 6주 동안 얻은 reject 정책에서 모든 하위 도메인을 조용히 면제합니다. 4단계에서 확인하세요; 하나의 하위 도메인이 진정으로 더 느슨한 정책이 필요하다면 모든 것을 느슨하게 만드는 대신 그 하위 도메인에 _dmarc 레코드를 게시하세요.

NIS2가 EU 기업이 이것을 해야 한다는 의미인가요?

DMARC는 어디서나 동일하게 작동합니다 — 이 절차서의 어느 것도 EU 경계에서 바뀌지 않습니다. 바뀌는 것은 규정 준수 요구입니다. NIS2 제21(2)(j)조는 적용 범위 내 기관이 통신을 보안하도록 요구하며, EU 집행 규정 2024/2690은 디지털 인프라 기관에 적용하는 기술 요건을 명시합니다 — 부속서(6.7.2(k))는 국제적으로 합의된 현대 이메일 보안 표준 도입을 위한 구현 계획을 요구하고, 6.7.2(l)은 DNS 보안 모범 사례를 요구합니다. SPF와 DKIM이 있는 적용된 DMARC 정책은 사칭을 위해 인정되는 감사 가능한 통제입니다; p=none은 명백히 모니터링이지, 보안이 아닙니다. 고객이 적용 범위에 있다면 공급업체 설문지가 점점 더 이것을 요청합니다.

자주 묻는 질문

전체 전환에 얼마나 걸리나요? 6~~10주가 일반적입니다: 2~~4주 모니터링, 1~~3주 소스 수정, 2~~4주 quarantine 증가, 그런 다음 reject. 달력 시간이지 노력이 아닙니다 — 대부분 각 변경을 확인하기 위한 보고서를 기다리는 것입니다. 적용된 정책이 없는 261,086,232개 평가 도메인 중 89.41%(2026-06-29 기준 데이터)는 대부분 전환 중이 아닙니다; 시계를 시작하지 않았습니다.

quarantine을 건너뛰고 낮은 pct로 p=reject를 사용할 수 있나요? 할 수 있습니다 — RFC 7489 §6.6.4에 따라 p=reject; pct=10은 10%가 reject되고 90%가 격리됨을 의미합니다. 대략 3단계 후반. 하지만 p=quarantine 먼저가 추론하기 더 쉬우며, 수신자들은 샘플링을 어떻게 충실히 구현하는지 다릅니다. 어느 쪽이든 1~2단계는 협상 불가입니다: 합법적인 발신자가 여전히 실패하는 동안에는 어떤 적용도 안전하지 않습니다.

수정할 수 없는 메일 — 전달자와 메일링 리스트 — 는 어떻게 하나요? 전달(forwarding)은 설계상 SPF를 깨뜨리며, 일부 메일링 리스트는 콘텐츠를 재작성하여 DKIM도 깨뜨립니다. 정렬된 DKIM은 일반 전달에서 살아남으며, 대부분을 처리합니다; 작은 잔재가 quarantine 단계가 있는 이유입니다 — 스팸 폴더에 들어간 메일은 평가하는 동안 회복 가능합니다. 자세한 내용은 전달된 이메일의 SPF 실패.

p=quarantine에서 멈추는 것으로 충분한가요? 대부분의 가치를 가지며, p=none에 정체된 37,312,637개 도메인(평가된 261,086,232개 기준, 2026-06-29 기준 데이터)보다 훨씬 낫습니다 — 하지만 사칭 메일이 여전히 스팸 폴더에 도달하며, 거기서 사람들이 꺼냅니다. Reject가 엔드포인트입니다: 평가된 도메인 중 10.59%만이 적용하며, 완성하는 것이 검사기, 보험사, 설문지가 인정하는 것입니다.

소유자에게 보고서 전달

클라이언트나 고용주를 위해 이 전환을 실행하는 경우 완료 지점이 보여줄 수 있습니다. p=reject가 해석되면 무료 스캔을 다시 실행하고 등급 보고서를 전달하세요: 도메인이 적용된 정책으로 이동하는 것이 타임스탬프와 알기 쉬운 언어로 보여집니다. 한 페이지가 사이버 보험 갱신과 NIS2 기반 공급업체 설문지의 이메일 보안 항목에 DNS 패널 스크린샷보다 훨씬 잘 답합니다 — 그리고 6주의 신중하고 보이지 않는 작업을 비용을 지불하는 사람에게 가시화합니다.

DMARC 정책 무료 확인

현재 정책이 무엇인지 — 그리고 SPF와 DKIM이 적용을 지원할 수 있는지 — 비공개로, 소유자만 확인하세요.

도메인 확인하기 → · DMARC 수정 → · “DMARC policy not enabled” — 솔직한 첫 단계 → · 집계 데이터만 사용합니다. 데이터는 EU에서 저장 및 처리됩니다.