Defaults.Exposed

Defaults.Exposed › 보고서

DMARC p=reject vs p=quarantine: 어떤 정책을 선택해야 할까?

게시일 · 업데이트됨

2026-08-16 기준 수치 · 방법론 v8. 276백만 개의 등급이 매겨진 도메인에 걸친 집계 인구조사 데이터입니다. DMARC는 인증에 실패한 메시지를 수신 메일 서버가 어떻게 처리할지 지시하는 DNS 정책입니다. 등급을 매기는 방법을 참조하세요.

DMARC 필러의 일부 — 전체 인구조사에 걸쳐 측정한 DMARC 도입률, 성숙도, 리그 테이블입니다.

DMARC 보고서에서 모든 정상 발신자가 통과하는 것이 확인된다면 p=reject를 선택하세요 — 위조된 메일을 즉시 거부하는 유일한 정책이며, 대부분의 도메인에게는 최종 목적지입니다. p=quarantine은 그곳으로 가는 의도적인 중간 단계로 선택하거나, 잘못 걸러진 진짜 메시지가 반송되는 대신 복구 가능한 스팸 폴더에 들어가야 하는 경우 영구 설정으로 선택하세요. 둘 다 시행(enforcement)에 해당하며, 둘 다 p=none이 그냥 통과시키는 일상적인 위조를 막아냅니다. 그리고 인터넷의 시행 도메인들은 거의 정확히 반으로 갈려 있습니다: 2026-08-16 기준, 도메인의 **6.43%**가 quarantine을, **5.40%**가 reject를 사용합니다 — 애초에 시행하는 도메인이 **11.83%**에 불과한 가운데서 말입니다. 이 가이드는 그 둘 사이의 선택, 그리고 안전하게 도달하는 방법을 다룹니다.

각 정책이 수신 측에서 실제로 하는 일

DMARC 정책은 당신이 DNS에 게시하는 지시이고, 그에 따라 행동하는 것은 수신 메일 서버입니다. 당신의 도메인에서 왔다고 주장하는 메시지가 인증에 실패하면, p= 값이 수신자에게 원하는 처리 방식을 알려줍니다:

정책요청하는 내용위조된 이메일잘못 설정된 진짜 이메일
p=none”그래도 배달하고, 보고만 해달라”받은편지함에 도착받은편지함에 도착
p=quarantine”의심스러운 것으로 취급해달라”스팸/정크함으로 이동스팸함으로 이동 — 복구 가능
p=reject”거부해달라”문 앞에서 반송반송 — 발신자가 오류를 받음

실무에서는 두 가지 세부 사항이 중요합니다. 첫째, DMARC 정책은 명령이 아니라 요청입니다 — 수신자는 재량에 따라 적용합니다. 주요 메일박스 제공업체들은 이를 존중하며, 그래서 시행이 작동하는 것입니다; 일부 소규모 업체는 quarantine을 느슨하게 해석합니다. 둘째, 실패 시 결과가 다르다는 점이 전체 결정을 좌우합니다: quarantine에서는 인증에 실패한 정상 메시지가 잘못 분류됩니다 — 짜증나지만, 정크 폴더에서 발견되기를 기다리고 있습니다. reject에서는 배달 중에 거부됩니다 — 발신 서버가 반송 통지를 받습니다. 그 반송은 시끄럽지만(발신자가 뭔가 깨졌다는 것을 즉시 알게 됩니다), 메시지는 도착하지 않습니다.

p=none이 보호가 아니라 감시인 이유

시행하는 두 정책을 비교하기 전에, 시행하지 않는 하나에 대해 분명히 해둡시다. p=none은 수신자에게 위조된 메일을 배달하고 그에 대한 보고서를 보내달라고 말합니다. 당신은 가시성을 얻고, 위조자는 배달을 얻습니다. 올바른 첫걸음이지만 — 가장 흔하게 멈춰 서는 지점이기도 합니다: 전체 도메인의 **13.96%**가 p=none에 머물러 있으며, 이는 시행하는 11.83%보다 많습니다. 공격자의 관점에서, p=none에 세워둔 도메인은 DMARC가 아예 없는 도메인과 동일합니다. 지금 당신의 도메인이 그 상태라면, 질문은 reject 대 quarantine이 아니라 — 얼마나 빨리 안전하게 둘 중 하나에 도달할 수 있는가입니다. p=none이 보호가 아닌 이유를 참조하세요.

단계별 경로: none → quarantine → reject

모니터링에서 곧바로 p=reject로 뛰어들어야 하는 사람은 없고, 그럴 필요도 없습니다. 정책 램프는 작고 되돌릴 수 있는 단계로 오르도록 설계되어 있습니다:

  1. 보고 기능을 켠 채 p=none에서 시작하세요 — v=DMARC1; p=none; rua=mailto:reports@yourdomain 같은 레코드로요. 몇 주 동안 집계 보고서를 수집하며 모든 정상 발신자를 파악하세요: 메일 제공업체, 뉴스레터 플랫폼, 청구 도구, CRM. 각 발신자가 정렬(alignment)을 갖추고 SPF 또는 DKIM을 통과하게 만드세요.
  2. p=quarantine; pct=10으로 이동하세요. pct 태그는 실패하는 메일의 표본 — 여기서는 10% — 에만 정책을 적용해 달라고 수신자에게 요청합니다. 정상 메일이 스팸함에 들어가기 시작해도, 발신자를 고치는 동안 일부만 영향을 받습니다.
  3. pct를 올리세요 — 25, 50, 그리고 100(또는 태그 제거; 100이 기본값) — 각 단계에서 보고서를 지켜보면서요.
  4. p=reject로 전환하세요. 원한다면 같은 램프를 쓸 수 있습니다. 이것이 실제로 위조를 문 앞에서 거부하는 설정입니다.

각 단계는 DNS 편집 한 번입니다. 솔직한 주의사항 두 가지: pct 샘플링은 모든 수신자가 존중하지는 않습니다 — 일부는 어떤 시행 정책이든 전면 적용하므로, 램프를 보증이 아닌 피해 완화 수단으로 취급하세요 — 그리고 DMARC 표준의 2026년 개정판(DMARCbis)은 pct를 폐기하고 더 단순한 t=y 테스트 플래그로 대체하므로, 도구가 진화할 것을 예상하세요. 어느 주의사항도 경로의 형태를 바꾸지는 않습니다: quarantine 먼저, 관찰, 그다음 reject.

올라가는 길의 함정 하나 더: 정책 값은 정확히 none, quarantine, reject로 표기해야 합니다. 인구조사에서 수신자가 파싱할 수 없는 토큰 — quarentine, rejet, keine — 이 들어간 레코드를 가진 도메인 **38,650**개가 발견되었는데, 이는 레코드를 조용히 무정책 상태로 강등시킵니다. 게시하기 전에 오타 목록에 2분을 쓸 가치가 있습니다. 대형 제공업체에서 DNS를 관리한다면, 호스트별 안내가 정확한 클릭 경로를 다룹니다: Google Workspace, Microsoft 365, Cloudflare.

quarantine이 올바른 영구 선택인 경우

표준적인 조언 — quarantine은 경유지, reject가 목적지 — 은 대부분의 도메인에 맞습니다. 하지만 “대부분”이 “전부”는 아니며, 인구조사의 거의 반반인 분포(6.43% 대 5.40%)가 전부 이동 중인 도메인인 것도 아닙니다. quarantine은 다음의 경우 정당한 영구 정책입니다:

quarantine이 영구적으로 치르게 하는 비용: 위조된 메일이 여전히 도착합니다 — 정크 폴더로, 그리고 일부 사용자는 성실하게 그것을 꺼내 봅니다. reject는 참여하는 수신자에서 위조 메시지가 결코 사람에게 도달하지 않는 유일한 정책입니다. 보고서가 한 달 동안 깨끗했고 위의 어느 것도 해당하지 않는다면, 마지막 걸음을 내디디세요.

롤백 안전성: reject는 일방통행 문이 아닙니다

도메인을 몇 년씩 p=none에 묶어두는 두려움은 “진짜 메일을 깨뜨리면 어쩌지?”입니다 — 그러니 롤백이 어떤 모습인지 명확히 말해둘 가치가 있습니다: TXT 레코드 하나를 되돌려 편집하는 것입니다. 변경은 DNS TTL 안에 전파됩니다 — 정책을 옮기기 시작하기 전에 TTL을 짧게(300–3600초) 설정해 두면, 잘못된 단계를 몇 분 안에 완전히 되돌릴 수 있습니다.

두 정책은 실패하는 방식도 다르며, 이를 미리 아는 것이 안전의 대부분입니다:

시행하기 전에 서브도메인 노출도 확인하세요: sp= 태그는 서브도메인에 대한 별도 정책을 설정하며, sp=를 명시하지 않으면 p=를 상속합니다. 메일을 전혀 보내지 않는 도메인 — 세워둔 브랜드, 리디렉션 전용 도메인 — 은 램프 전체를 건너뜁니다: 보호할 정상 메일이 없으므로 오늘 바로 p=reject를 게시하세요. 전체 레코드 문법은 DMARC 수정 가이드에서 다룹니다.

이동 전에 (그리고 후에) 필요한 모니터링

이 가이드의 모든 안전한 정책 이동은 한 가지에 달려 있습니다: 무엇이 깨질지 볼 수 있다는 것. 그것이 집계(rua=) 보고서입니다 — 수신자가 보내주는 일일 요약으로, 당신의 도메인 이름으로 메일을 보낸 모든 출처와 통과 여부를 나열합니다. 인구조사 전체에서 이를 수집하는 도메인은 **10.16%**뿐입니다; 보고 주소 없는 DMARC 레코드는 눈을 감고 시행하는 것입니다.

각 정책 단계 전에, 보고서가 최소 2주 동안 깨끗하게 다음을 보여줘야 합니다: 알려진 모든 발신자가 통과하고 정렬됨, 설명되지 않는 정상처럼 보이는 출처 없음, 포워딩 흐름 파악 완료. 어려운 부분은 보고서를 읽는 것이 아니라 — 모든 출처를 실제 시스템에 귀속시키는 탐정 작업이며, 이것이 대부분의 멈춘 배포가 죽는 DMARC 성숙도 모델의 벽입니다. 그리고 모니터링은 p=reject에서 끝나지 않습니다: 새 SaaS 도구가 연결되고, 제공업체가 IP를 바꾸고, 설정은 썩습니다. 보고서는 고객보다 먼저 알아내는 방법입니다 — 주요 수신자들이 이제 대량 발신자에게 사실상 요구하는 규율이기도 합니다.

자주 묻는 질문

p=reject가 p=quarantine보다 낫나요? 사칭을 막는 데는 그렇습니다 — reject는 위조된 메일이 어딘가에 배달되는 대신 거부되는 유일한 정책입니다. quarantine은 확신을 쌓는 동안의 올바른 선택이며, 잃어버린 진짜 메일의 비용이 스팸함 속 위조 메일보다 클 때는 정당한 영구 선택입니다.

p=none에서 곧바로 p=reject로 갈 수 있나요? 도메인이 메일을 전혀 보내지 않는 경우에만 — 그렇다면 오늘 하세요. 발신하는 도메인이라면 quarantine을 거쳐(가급적 pct 램프와 함께) 이동하세요. 놓친 것이 있어도 반송되는 대신 복구 가능하게 잘못 분류되도록요.

pct=는 실제로 무엇을 하나요? pct=25는 실패하는 메시지의 약 25%에만 정책을 적용해 달라고 수신자에게 요청하여, 시행을 단계적으로 도입할 수 있게 합니다. 모든 수신자가 샘플링을 존중하지는 않으며, 2026년 DMARC 개정판은 이를 t=y 테스트 플래그로 대체합니다 — 보증이 아닌 피해 완화 수단으로 취급하세요.

p=quarantine에 얼마나 머물러야 하나요? 집계 보고서가 모든 정상 발신자의 통과와 정렬을 몇 주간 깨끗하게 보여줄 때까지 — 실무에서는 보통 2~6주입니다. 보고서가 깨끗하게 유지되고 구조적 이유(포워더, 마이그레이션, 복구 가능성)가 없다면, reject로 이동하세요.

reject가 잘못되면 메일이 영원히 사라지나요? 거부된 메시지는 도착하지 않지만, 제대로 동작하는 발신 시스템은 반송 통지를 받으므로 정상 발신자는 즉시 알게 됩니다 — 그리고 롤백은 TTL 안에 효력을 발휘하는 DNS 편집 한 번입니다. 전환 기간에는 TTL을 짧게 유지하세요.

당신의 도메인이 오늘 어떤 정책을 게시하는지 확인하세요

“DMARC가 있다”와 “DMARC를 시행한다” 사이의 격차가 바로 사칭이 사는 곳입니다. 무료로, 비공개로 도메인을 확인하세요 — 실제 정책, 보고서가 흐르고 있는지, 그리고 다음 단계로 가는 한 가지 조치를 볼 수 있습니다.

도메인 점검하기 → · DMARC 수정하기 → · DMARC란? → · DMARC 필러 → · 집계 데이터만 사용합니다. 데이터는 EU에서 저장·처리됩니다.