DMARC p=none → quarantine → reject 안전 전환 가이드

DMARC 정책을 모니터링(none)에서 격리·거부로 단계적으로 강화하는 안전한 절차.

DMARC를 p=reject로 두면 도메인을 사칭한 메일이 수신함에 도착하기 전에 차단된다. 하지만 충분한 준비 없이 곧장 reject로 올리면 뉴스레터·결제 알림·구인 시스템처럼 회사가 실제로 보내는 정상 메일까지 함께 버려진다. 그래서 DMARC는 항상 모니터링(none) → 격리(quarantine) → 거부(reject)순서로, 보고서를 읽으면서 단계적으로 강화해야 한다.

이 가이드는 각 단계에서 무엇을 확인하고 무엇을 고쳐야 하는지, 그리고 pct로 위험을 어떻게 천천히 늘려가는지를 다룬다. 현재 도메인의 정책 상태는 DMARC 레코드 조회로 먼저 확인하고 시작하자.

0단계 — 전제: SPF·DKIM 정렬(alignment)이 먼저다

DMARC는 새로운 인증을 만들지 않는다. SPF와 DKIM의 결과를 보고, 거기서 인증된 도메인이 메일의 보낸사람 주소(From: 헤더 도메인)와 정렬(align)되는지를 판정할 뿐이다. 따라서 DMARC를 강화하기 전에 정상적인 발신 경로가 SPF 또는 DKIM 중 최소 하나로 정렬되어 통과해야 한다.

SPF 정렬: Return-Path(envelope from) 도메인이 From: 도메인과 같은 조직 도메인이어야 한다. SaaS 발송 도구는 보통 envelope from이 자기네 도메인이라 SPF는 통과해도 정렬이 깨진다.
DKIM 정렬: 서명의 d= 도메인이 From: 도메인과 정렬되어야 한다. 그래서 대부분의 SaaS 발송은 자체 서브도메인에 DKIM CNAME을 심어 정렬을 맞춘다.

DKIM 셀렉터가 실제로 게시돼 있고 키를 읽을 수 있는지는 DKIM 레코드 조회로 확인한다. 둘 중 하나라도 정렬되어 통과하지 못하면 그 발송원은 DMARC에서 실패로 잡히고, reject단계에서 메일이 사라진다.

1단계 — p=none + rua로 데이터 수집(절대 차단하지 않음)

p=none은 아무 메일도 격리·거부하지 않는 관찰 전용 정책이다. 핵심은 rua 태그로 집계 보고서(aggregate report)를 받는 것이다. 보고서가 쌓여야 누가 우리 도메인으로 메일을 보내는지(정상/사칭 모두) 전체 지도를 그릴 수 있다.

예시 레코드: v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1; — fo=1은 SPF/DKIM 중 하나라도 정렬 실패하면 실패 보고서를 보내라는 의미라 디버깅에 유용하다. 이런 레코드는 DMARC 레코드 생성기로 만들고, 게시 후 DMARC 조회로 정상 게시를 확인한다. 보고서는 최소 1~2주, 가능하면 4주는 모은다(주간 발송·청구 주기를 모두 포함하려면).

2단계 — 집계 보고서를 읽고 정상 발송원을 고친다

집계 보고서는 발송 IP별로 메일 수와 SPF/DKIM 정렬 결과를 알려주는 XML이다. 여기서 할 일은 단순하다: 우리가 보낸 정상 메일인데 실패로 잡힌 것들을 모두 통과시키는 것이다. 흔한 정상 발송원과 조치는 다음과 같다.

마케팅 메일(Mailchimp, Stibee 등) → 제공 업체의 DKIM CNAME과 SPF include 등록
결제·트랜잭션 메일(Stripe, Toss 등) → 발송 서브도메인에 DKIM 위임
그룹웨어·ERP·구인 시스템 → 자체 서버 IP를 SPF에 추가하고 DKIM 서명 활성화
오래된 포워딩(전 직원 별칭 등) → SPF는 깨지지만 DKIM은 보존되므로 DKIM 정렬에 의존

목표는 보고서에서 알 수 없는(=사칭 가능성) 발송만 실패로 남고, 정상 발송은 100% 정렬 통과하는 상태다. 여기서 충분히 시간을 쓰지 않고 다음 단계로 넘어가는 것이 가장 흔한 실수다.

3단계 — quarantine + pct 점진 적용(25 → 50 → 100)

정상 발송이 모두 통과하면 p=quarantine로 올린다. 실패한 메일은 보통 스팸함으로 간다 — 사라지지 않으므로 reject보다 위험이 낮다. pct 태그로 정책을 적용할 메일 비율을 조절해 한꺼번이 아니라 조금씩 적용한다.

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; — 며칠 관찰
문제 없으면 pct=50
다시 안정적이면 pct=100

각 단계 사이에 보고서를 다시 보고, 새로 실패하는 정상 발송이 없는지 확인한다. 단계별 레코드는 매번 DMARC 생성기로 만들어 교체하면 된다.

4단계 — reject로 최종 강화

p=quarantine; pct=100에서 며칠~몇 주간 정상 메일 손실이 없으면 p=reject로 올린다. 이제 정렬 실패 메일은 수신 서버 단에서 거부되어 사칭 메일이 수신함에 닿지 못한다. rua는 계속 유지해 새로운 발송원이나 침해 시도를 모니터링한다.

단계 요약 표

단계	레코드 핵심	실패 메일 처리	목적
1. 모니터링	`p=none; rua=…`	그대로 배달	발송원 지도 작성
2. 정비	(레코드 유지)	그대로 배달	정상 발송 정렬 수정
3. 격리	`p=quarantine; pct=25→50→100`	스팸함으로	위험 낮게 점진 적용
4. 거부	`p=reject`	수신 단계에서 거부	사칭 완전 차단

전체 흐름의 가장 큰 실수는 단 하나다: 발송원을 고치기 전에 reject로 점프하는 것. 보고서로 정상 발송이 모두 정렬 통과함을 눈으로 확인하기 전까지는 절대 reject로 올리지 말자.

자주 묻는 질문

p=none에서 바로 p=reject로 가면 안 되나요?

기술적으로는 가능하지만 매우 위험합니다. 보고서로 정상 발송원을 모두 확인·수정하기 전에는, SPF/DKIM 정렬이 깨진 정상 메일(뉴스레터, 결제 알림, ERP 메일 등)이 수신함에 닿지 못하고 거부됩니다. 반드시 none으로 데이터를 모으고 발송원을 고친 뒤 단계적으로 올리세요.

각 단계는 얼마나 유지해야 하나요?

정해진 규칙은 없지만, p=none은 최소 1~2주(가능하면 주간·청구 주기를 포함하도록 4주), quarantine의 각 pct 단계는 며칠씩 관찰하는 것을 권장합니다. 핵심은 시간이 아니라 보고서에서 정상 발송이 모두 정렬 통과하는지 확인하는 것입니다.

pct 태그는 무엇이고 왜 쓰나요?

pct는 DMARC 정책을 적용할 메일의 비율(%)입니다. pct=25면 실패한 메일의 약 25%에만 정책(격리)이 적용되고 나머지는 한 단계 약한 처리(배달)를 받습니다. 한꺼번에 전체에 적용하지 않고 25→50→100으로 천천히 올려 위험을 분산할 때 씁니다. reject 단계에서는 보통 pct=100(기본값)으로 둡니다.

SPF가 통과하는데 왜 DMARC는 실패하나요?

SPF 통과와 SPF '정렬'은 다릅니다. DMARC는 SPF 인증에 쓰인 envelope from 도메인이 From: 헤더 도메인과 같은 조직 도메인인지(정렬)까지 봅니다. SaaS 발송 도구는 envelope from이 자기네 도메인이라 SPF는 통과해도 정렬이 깨집니다. 이럴 때는 그 도구에 DKIM을 위임해 DKIM 정렬로 통과시키면 됩니다.

reject까지 갔는데 새 발송 도구를 추가하면요?

rua 보고서를 계속 받고 있다면 새 도구의 메일이 정렬 실패로 보고서에 나타납니다. 그 도구의 SPF include나 DKIM 위임을 먼저 설정해 정렬을 맞춘 뒤 본격 발송하세요. reject 상태에서는 정렬 안 된 메일이 즉시 거부되므로, 새 발송원은 항상 인증을 먼저 갖추는 것이 원칙입니다.

이 가이드와 함께 쓰면 좋은 도구

DMARC 레코드 조회·검사

_dmarc TXT 레코드를 조회하고 정책·태그를 해석합니다.

DMARC 레코드 생성기

정책·리포트 주소를 선택해 DMARC TXT 레코드를 생성합니다.

DKIM 레코드 조회

selector._domainkey TXT 레코드를 조회해 DKIM 공개키를 확인합니다.