DMARC p=none vs quarantine vs reject: 운영자를 위한 가이드

핵심 트레이드오프

DMARC 정책을 고르는 일은 가시성과 적용 강도 사이에서 선택하는 일입니다. p=none은 전달에 영향을 주지 않고 모니터링만 합니다. p=quarantine은 의심스러운 메일을 스팸함으로 보냅니다. p=reject는 인증되지 않은 메일을 아예 차단합니다. 가장 안전한 방법은 단계적으로 적용하는 것입니다. 먼저 none으로 시작해 정상 발신처를 모두 파악하고, quarantine으로 영향을 시험한 다음, 마지막으로 reject에 도달해 도메인 스푸핑을 완전히 차단합니다.

정책이 장애 대응 큐에 영향을 주는 이유

전달성을 책임지는 엔지니어의 가장 큰 목표는 정상적인 트랜잭션 메일이 수신자에게 도달하게 하면서, 공격자가 여러분의 도메인을 악용하지 못하게 막는 것입니다. 모니터링 단계 없이 곧바로 p=reject로 가면, 잊고 있던 레거시 시스템이나 서드파티 마케팅 도구의 메일이 갑자기 전달되지 않아 긴급 장애가 발생할 가능성이 큽니다.

DMARC(Domain-based Message Authentication, Reporting, and Conformance)는 SPF와 DKIM의 정렬에 의존합니다. 메시지가 둘 다 실패하면 p= 태그가 수신 메일 서버에 해당 메시지를 어떻게 처리할지 정확히 알려 줍니다.

세 가지 정책 수준

1. p=none (모니터링 모드)

이 모드에서는 인증 결과와 관계없이 수신 측이 메시지에 아무 조치도 하지 않습니다. 순전히 데이터 수집용입니다.

사용 시점:

• DMARC를 처음 설정할 때.
• 내 도메인으로 메일을 보내는 서비스를 모두 파악하지 못했을 때.
• 새 이메일 API로 마이그레이션하는 동안.

페이로드:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

트레이드오프: 스푸핑에 대한 보호가 전혀 없습니다. 공격자가 여전히 내 도메인으로 메일을 보낼 수 있으며, RUA(집계) 보고서에서 확인할 수 있을 뿐입니다.

2. p=quarantine (소프트 적용)

DMARC에 실패한 메시지는 의심스러운 메일로 처리됩니다. 대부분의 수신 측은 이런 메일을 스팸함이나 정크 폴더로 옮깁니다.

사용 시점:

• p=none 보고서를 분석하고 모든 정상 발송 흐름이 정렬되었는지 확인한 뒤.
• 완전한 reject로 넘어가기 전의 안전 완충 단계로.

페이로드:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com;

트레이드오프: 스푸핑된 메일이 눈에 덜 띄게 될 뿐 사라지지는 않습니다. DKIM 키를 잘못 교체했거나 SPF 레코드가 DNS 조회 10회 제한에 걸리면 정상 메일도 스팸함으로 갈 수 있습니다.

3. p=reject (완전 적용)

도메인 보안의 최고 기준입니다. 메시지가 DMARC에 실패하면 수신 서버가 메시지 수락 자체를 거부합니다.

사용 시점:

• 모니터링 결과 모든 정상 트래픽의 정렬률이 99.9%일 때.
• 도메인 스푸핑의 위험이 간헐적인 전달 실패의 위험보다 클 때.

페이로드:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;

트레이드오프: 안전망이 없습니다. 핵심 시스템이 잘못 설정되어 있으면 메일은 사라집니다. 이런 실패는 RUA 보고서에서 볼 수 있지만, 사용자는 메일을 받지 못합니다.

운영자를 위한 적용 체크리스트

감으로 정책을 바꾸지 마세요. 집계 보고서의 데이터를 근거로 옮겨야 합니다. 단계를 바꾸기 전에 SendHQ 이메일 DNS 확인 도구 같은 도구로 레코드가 제대로 전파되었는지 확인하세요.

1단계: 탐색 (p=none)

1. rua 주소와 함께 p=none을 게시합니다.
2. 주간 보고서를 포함해 업무 주기 전체를 담을 수 있도록 7~14일 기다립니다.
3. 보고서에서 "정렬되지 않은" 트래픽을 분석합니다.
4. 정상적인 서드파티 발신처(예: Zendesk, Salesforce, Shopify)를 파악합니다.
5. 파악한 모든 발신처에 DKIM을 설정합니다. 정렬을 확보하는 가장 확실한 방법입니다.

2단계: 테스트 (p=quarantine)

1. 정책을 p=quarantine으로 변경합니다.
2. "이메일을 받지 못했어요", "이메일이 스팸함에 있어요" 같은 지원 티켓이 없는지 살핍니다.
3. RUA 보고서에서 실패가 새로 급증하지 않았는지 확인합니다.
4. 실패가 발생하면 인증을 수정하고 quarantine 단계에서 한 주 더 유지합니다.

3단계: 강화 (p=reject)

1. 정책을 p=reject로 변경합니다.
2. 가장 중요한 트랜잭션 흐름(비밀번호 재설정, 청구서)이 여전히 전달되는지 확인합니다.
3. 모니터링을 계속합니다. DMARC는 "한 번 설정하고 잊어도 되는" 설정이 아닙니다.

이메일을 부수 효과로 다루기

AI 에이전트나 자동화 워크플로를 만드는 제품 엔지니어에게 이메일 발송은 외부 부수 효과입니다. 즉 애플리케이션 로직과 무관한 이유(DNS 문제, DMARC 거부, 속도 제한)로 실패할 수 있습니다.

멱등성과 승인

AI 에이전트가 이메일을 트리거할 때는 재시도 중 중복 발송을 막아야 합니다. API 요청에 멱등성 키를 사용하면 네트워크 타임아웃 때문에 고객이 같은 이메일을 다섯 번 받는 일을 방지할 수 있습니다.

또한 에이전트가 중요도가 높은 이메일을 자율적으로 보내도록 허용해서는 안 됩니다. 에이전트가 생성한 콘텐츠에 승인 큐를 도입해 "From" 주소와 콘텐츠가 브랜드 및 인증 정책에 부합하는지 확인하세요.

전송 인프라 비용

발송 제공업체를 어디로 정하느냐에 따라 DMARC 관리 방식도 달라집니다. DKIM 설정이 매우 간단한 제공업체도 있고, 서브도메인마다 DNS 항목을 수동으로 추가해야 하는 제공업체도 있습니다.

비용을 평가할 때는 총 소유 비용을 살펴보세요. 예를 들어 50,000통을 발송하는 데 Amazon SES 종량제에서는 약 5 USD(1,000통당 0.10 USD)가 들지만, Postmark 요금제에서는 같은 발송량에 약 66 USD(10,000통에 15 USD, 초과분은 1,000통당 1.20~1.80 USD)가 듭니다.

그 밖의 선택지로는 월 3,000통(일 100통 한도)의 무료 플랜을 제공하는 Resend, 월 10,000통에 월 15 USD부터 시작하는 Mailgun이 있습니다. SendGrid는 이제 무료 플랜을 60일 체험판으로 운영하며, Essentials는 월 19.95 USD부터 시작합니다.

어떤 제공업체를 쓰든 DMARC 정책은 도메인의 가장 중요한 방패입니다. SPF만 지원하는 제공업체를 사용하면 p=reject로 전환할 때 전달 실패 위험이 커집니다. 이메일 전달(forwarding) 과정에서 SPF가 깨지기 때문입니다. 전달을 거쳐도 정렬을 유지할 수 있는 방법은 DKIM뿐입니다.

흔한 실패 유형

전달(포워딩) 함정

사용자 A가 사용자 B에게 이메일을 보냅니다. 사용자 B는 사용자 C로 자동 전달을 설정해 두었습니다. 전달 서버는 스팸으로 분류되지 않도록 엔벨로프 발신자를 자신의 도메인으로 바꾸는 경우가 많으며, 이 때문에 SPF 정렬이 깨집니다. p=reject가 설정되어 있고 DKIM 서명이 없으면 사용자 C는 그 이메일을 끝내 받지 못합니다.

DNS 조회 제한

SPF 레코드는 DNS 조회를 10회까지만 할 수 있습니다. SPF 레코드에 제공업체를 너무 많이 추가하면 수신 측이 permerror를 반환하고, 이는 DMARC 실패로 이어집니다. 이를 해결하려면 DKIM 우선 인증을 권장하는 제공업체를 쓰거나 SPF 플래트닝을 사용하세요.

"그림자 IT" 문제

마케팅 팀은 엔지니어링 팀에 알리지 않고 새 도구(예: 새 뉴스레터 서비스)에 가입하는 경우가 많습니다. 그 도구가 내 도메인으로 메일을 보내면 DMARC에 실패해 거부됩니다. p=none 단계를 건너뛸 수 없는 이유입니다.

운영자를 위한 요약 표

정책 | 동작 | 위험 | 가시성 | 권장 용도

p=none | 없음 | 낮음 | 높음 | 탐색 및 감사

p=quarantine | 스팸함 | 중간 | 높음 | 테스트 및 전환

p=reject | 차단됨 | 높음 | 중간 | 완전한 프로덕션 보안

이 레코드의 기술적 구현을 더 자세히 알아보려면 DKIM, SPF, DMARC 가이드를 참고하세요.

이 레코드를 수동으로 관리하는 일은 번거롭습니다. SendHQ는 검증된 도메인 기반의 트랜잭션 발송과 인프라를 에이전트에 적합하게 갖추도록 돕는 도구를 제공해 이 과정을 간소화합니다.

자세한 내용은 https://sendhq.cc에서 확인하세요.