none·quarantine·reject DMARC 정책은 언제 바꿔야 할까?

none·quarantine·reject는 실패한 메일의 처리 요청입니다

먼저 인증 결과와 정책을 나눠 생각해 보겠습니다. DMARC의 통과 조건은 SPF 또는 DKIM 중 하나가 통과하면서, 그 인증 도메인이 화면에 보이는 From 도메인과 맞는 것입니다. 이 연결을 도메인 정렬이라고 합니다. p=를 바꾸는 것은 이 통과 조건을 바꾸는 일이 아닙니다. 조건을 만족하지 못한 메일을 어떻게 다뤄 달라고 요청할지 바꾸는 일입니다.

none에서도 인증 검사는 가능합니다. 스팸·악성코드 등 다른 이유로 메일이 차단될 수도 있습니다. quarantine 역시 “언제든 되찾을 수 있는 임시 보관함”을 뜻하지는 않습니다. 고객이 스팸함을 보지 않으면 청구서나 로그인 안내는 사실상 전달되지 않은 것과 같습니다. Microsoft도 정책별 처리와 다른 필터링의 관계를 구분해 설명합니다. Microsoft의 DMARC 실패 메일 처리 ↗

처음에는 none으로 상태를 확인하는 편이 좋습니다. 다만 레코드를 등록한 뒤 계속 방치하면, 회사 도메인을 무단으로 쓴 메일에 대해 격리·거부를 요청하는 단계로 나아가지 못합니다. 반대로 달력에 정해 둔 날짜가 됐다는 이유만으로 강화해서도 안 됩니다. 관찰할 업무와 해결할 문제, 다시 판단할 날짜를 함께 정해야 합니다.

전체 99% 뒤에 숨어 있는 청구서 100통

이 예시에서 가온상사는 example.com을 알림·청구서처럼 용도가 제한된 발송에만 사용하고, 직원의 일반 업무 메일은 별도 도메인으로 보냅니다. 실제로는 전용 하위 도메인으로 나눌 수도 있습니다. 한 관찰 구간에서 일반 알림 9,900통과 월말 청구서 100통이 확인됐습니다. 알림은 모두 DMARC를 통과했지만, 외부 회계 서비스에서 보내는 청구서는 모두 실패했습니다. 아래 숫자는 설명을 위한 가상 데이터입니다.

가온상사의 첫 판단은 전환 보류입니다. 실패율 1%가 작다는 이유로 넘기지 않습니다. 재무팀에 발신 서비스와 담당자를 확인하고, 발송 로그의 시간·대상 건수와 RUA 집계를 대조합니다. RUA는 수신 서버가 보내 주는 DMARC 집계 보고서입니다. 보고서의 IP만 보고 회계 서비스라고 단정하지 않고, 실제로 사용 중인 서비스라는 근거부터 찾습니다.

청구서는 보냈는데 회사 도메인으로 인증하지 않았습니다

테스트 청구서를 외부 계정으로 받아 원본 헤더를 확인해 보니, 두 인증은 회계 서비스의 도메인으로 통과했습니다. 고객 화면에는 회사 주소가 보이지만 인증은 회사와 연결되지 않았던 것입니다.

From: billing@example.com

[변경 전]
SPF:  pass · MAIL FROM=bounce@mailer.example.net
DKIM: pass · d=mailer.example.net
DMARC: fail · example.com과 정렬된 통과 경로 없음

[회사 도메인 DKIM 설정 후]
SPF:  pass · MAIL FROM=bounce@mailer.example.net
DKIM: pass · d=example.com
DMARC: pass · DKIM으로 인증과 정렬을 만족

IT 담당자는 회계 서비스의 회사 도메인 인증 기능을 확인합니다. 해당 회사에 발급된 DKIM DNS 값을 등록하고, 서비스에서 서명을 활성화합니다. 이후 재무팀이 실제 월말 발송과 같은 경로로 테스트 청구서를 다시 보냅니다. 위 예시에서는 DKIM이 회사 도메인으로 통과하면서 DMARC도 통과합니다. SPF에 보이는 도메인이 여전히 다르다고 이 결과를 실패로 판단하지 않습니다. Google의 DMARC 인증·정렬 안내 ↗

여기서 완료 기록은 “DNS 저장 성공”이 아닙니다. 어느 서비스에서 어떤 주소로 보내 어느 수신처에서 확인했는지, 수신 측 인증 결과가 무엇인지 남깁니다. Gmail과 Microsoft 365를 포함해 실제 고객이 주로 쓰는 수신 서비스로 시험하고, 제목·첨부파일·회신 주소도 업무 의도와 같은지 확인합니다. 재무 담당자가 테스트가 실제 청구서 발송 경로를 대표한다는 점까지 확인하면 이 누락을 해결했다고 판단할 근거가 생깁니다.

전환 기준은 날짜보다 확인한 발신 경로입니다

청구서 하나를 고쳤다고 모든 준비가 끝나지는 않습니다. 비밀번호 재설정, 고객지원 답장, CRM, 분기 공지도 같은 주소를 쓸 수 있습니다. 평소 발송량이 적거나 지금은 보내지 않는 경로가 빠지기 쉽습니다. 아래 순서로 업무 담당자와 함께 확인하면 “문제없어 보인다”를 구체적인 근거로 바꿀 수 있습니다.

가온상사는 일일 알림과 월말 청구서를 확인했습니다. 분기 공지는 아직 보고서에 없습니다. 이때 선택은 무작정 다음 분기까지 기다리거나, 그 경로를 빼고 전환하는 두 가지뿐이 아닙니다. 담당자가 실제 발송 기능으로 내부 승인된 시험 대상을 정해 보내고, 자동 배치·별도 SMTP 서버 등 운영 경로가 테스트와 다른 부분이 없는지 확인할 수 있습니다. 재현하지 못한 부분은 미확인 상태로 남겨 판단에 반영합니다.

RUA 한 가지로 모든 수신 결과를 알 수는 없습니다

RUA는 보고서를 제공하는 수신자가 관찰한 범위의 집계입니다. 도착까지 시간이 걸리고, 모든 수신 서비스가 보고서를 보내는 것도 아닙니다. 따라서 “실패 보고가 없다”는 말과 “모든 정상 메일이 잘 도착했다”는 말은 다릅니다. 스팸함인지 받은편지함인지도 일반적인 RUA만으로 확정할 수 없습니다. DMARC 집계 보고서의 범위 ↗

전환 근거에는 보고서와 함께 실제 외부 수신 시험, 발송 서비스의 반송 로그, 고객지원 문의를 넣습니다. 반송이 있으면 코드와 설명, 발송 시각, 발신 서비스를 모아 DMARC 때문인지 확인합니다. 고객지원에는 “정책을 바꿨으니 잘 보세요”보다 “청구서·로그인 메일 미수신 문의에 발송 시각과 수신 도메인을 함께 기록해 주세요”라고 요청하는 편이 쓸모 있습니다.

전체 실패율을 0%로 만드는 것을 목표로 삼을 필요도 없습니다. 회사와 무관한 서버의 주소 도용 시도는 계속 실패하는 것이 맞습니다. 미확인 IP를 무조건 SPF에 넣지 말고, 허용한 발신처인지 확인한 뒤 정상 발송의 실패를 해결하세요.

하위 도메인과 전달 메일은 따로 확인합니다

이제 가온상사가 뉴스레터를 news.example.com으로 보낸다고 해 보겠습니다. 루트 도메인의 정책을 바꿀 때 뉴스레터도 영향을 받을 수 있습니다. 다음 표는 example.com이 조직 도메인이고, 루트 레코드가 p=reject; sp=quarantine인 단순한 구성의 예시입니다.

발신 도메인에 유효한 자체 DMARC가 있으면 그 정책을 먼저 사용합니다. 상속할 때는 sp가 기존 하위 도메인의 정책이며, 없으면 p를 따릅니다. np는 DNS에 존재하지 않는 하위 도메인에 대한 정책입니다. np가 없으면 sp, 그것도 없으면 p로 이어집니다. 메일을 안 보내거나 MX가 없다는 사실만으로 “존재하지 않는 도메인”이 되는 것은 아닙니다. DMARC 정책 항목과 상속 ↗

이런 구성을 이용해 검증이 끝난 도메인부터 전환할 수 있습니다. 다만 발송 서비스의 이름만 뉴스레터용으로 바꿔서는 분리되지 않습니다. 실제 From을 news.example.com으로 쓰고, 해당 주소와 정렬되는 인증을 설정하며, 그 주소의 정책을 확인해야 합니다. 고객이 보는 주소와 회신 경로도 달라질 수 있으므로 업무 담당자와 먼저 정합니다. 자체 p=none을 임시로 둔다면 책임자와 재검토일을 붙여 장기 누락으로 남지 않게 합니다.

직접 보낼 때와 전달받을 때의 결과가 다를 수 있습니다

자동 전달을 거치면 최종 수신자가 보는 발신 IP가 달라져 SPF가 실패할 수 있습니다. DKIM이 유지되면 DMARC가 통과할 수 있지만, 메일링 리스트가 서명 대상인 제목이나 본문을 고치면 DKIM도 깨질 수 있습니다. 실제로 쓰는 전달·메일링 리스트가 있다면 직접 발송 시험과 구분해 확인합니다. 전달·메일링 리스트와 DMARC ↗

ARC는 중간 서버의 인증 관찰을 최종 수신자에게 전달하는 데 도움이 됩니다. 그러나 ARC가 있다는 이유로 DMARC 실패가 자동으로 통과로 바뀌지는 않습니다. 수신자가 그 기록과 중간 서버를 어떻게 신뢰하는지에 따라 처리합니다. 따라서 “ARC가 지원된다”는 제품 설명만으로 중요한 전달 경로의 검증을 생략하지 않습니다. ARC와 수신 측 처리 판단 ↗

변경은 한 가지씩, 복구 조건은 변경 전에 정합니다

가온상사는 청구서 수정 후 주요 업무를 재시험하고, 정기 발송과 전달 경로의 확인 기록을 모았습니다. 대응 담당자도 정했습니다. 이 예시에서는 용도가 제한된 알림 도메인에 대해 none에서 reject로 전환하기로 합니다. 모든 발송 경로에 정렬된 DKIM 서명도 확인했습니다. reject 도메인은 SPF에만 의존하지 않아야 한다는 표준 요건을 반영한 것입니다. 직원의 일반 업무 도메인에 같은 결정을 적용하는 예시는 아닙니다.

먼저 현재 레코드와 TTL을 저장합니다. TTL은 DNS 응답을 얼마나 오래 캐시할 수 있는지 알려주는 값입니다. 필요하다면 DNS 서비스의 허용 범위에서 미리 낮추고, 기존 TTL이 지나 새 값이 조회되는지 확인합니다. 변경 시간에 담당자가 부재하거나 바로 대량 청구서 발송이 예정돼 있다면 대응할 수 있는 시간으로 조정합니다.

Name: _dmarc.example.com
Type: TXT

변경 전
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

변경 후
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

example.com과 보고서 주소는 설명용입니다. 실제 적용에서는 사용 중인 주소와 다른 항목을 유지하고, 해당 이름에 DMARC TXT를 중복으로 추가하지 않습니다. 정책 변경과 함께 정렬을 엄격 모드로 바꾸거나, 발송 서비스·DKIM 키까지 교체하면 문제가 생겼을 때 원인을 찾기 어려워집니다. 이번 변경에서는 p만 바꿉니다.

1. DNS에 공개된 값을 확인합니다

   관리 화면의 저장 결과뿐 아니라 외부 DNS 조회로 새 정책과 레코드 개수를 확인합니다. 캐시된 이전 값이 남을 수 있어 조회 시각도 적습니다.

2. 같은 업무 경로를 다시 시험합니다

   알림·청구서·고객지원처럼 준비 때 확인한 경로로 보내 수신 측 인증, 실제 도착과 반송을 확인합니다. 한 수신처의 성공을 모든 고객의 성공으로 확대하지 않습니다.

3. 후속 보고서와 문의를 함께 봅니다

   RUA의 보고 기간이 변경 전인지 후인지 구분하고, 업무별 실패와 반송·미수신 문의를 대조합니다. 월말 등 다음 정기 발송 때도 다시 확인합니다.

어떤 경우에 되돌릴지 구체적으로 적습니다

“실패율이 올랐으니 복구”만으로 정하면 주소 도용 시도가 늘 때도 보호를 풀게 됩니다. 가온상사의 복구 조건은 승인된 중요 업무 메일이 변경 이후 DMARC 실패로 거부됐고, 즉시 발신 설정을 고칠 수 없는 경우입니다. 반송의 인증 오류, 해당 서비스의 발송 기록, 외부 테스트로 원인을 확인합니다. 원인이 아직 불명확하더라도 고객 영향이 크다면 기록된 비상 판단 절차에 따라 담당자가 결정합니다.

되돌려야 한다면 미리 저장한 값으로 수정하고 외부 조회와 발송 시험을 반복합니다. DNS 캐시 때문에 복구도 즉시 모든 수신처에 적용되지는 않습니다. 이미 거부된 메일은 정책을 되돌린다고 다시 배달되지 않으므로, 실패 건을 확인해 중복 청구·중복 알림이 생기지 않게 재발송 여부를 판단해야 합니다.

대상: example.com의 _dmarc TXT
변경: p=none → p=reject, 나머지 항목 유지
근거: 알림·청구서·고객지원 테스트와 정기 발송 목록 확인
증거: 테스트 시각, 발신 서비스, 수신처, 원본 헤더 보관 위치
담당: IT 담당자가 DNS 변경, 재무 담당자가 청구서 수신 확인
관찰: 주요 수신처 재시험, 반송·지원 문의, 변경 후 기간의 RUA
복구: 중요 정상 메일의 DMARC 거부 확인 + 즉시 수정 불가 시 판단
복구 값: 변경 전 TXT 전체 값 별도 저장
후속: 다음 월말 발송 결과 확인, 신규 발신 서비스 등록 시 재검증

pct와 새 테스트 모드는 현재 지원을 확인하세요

검색한 가이드에 pct=10이 보일 수 있습니다. 과거에는 정책을 일부 비율에 적용하도록 요청하는 항목이었습니다. 2026년 표준 RFC 9989에서는 pct, 보고 주기인 ri, 실패 보고 형식인 rf를 제거했으며, IANA 등록부도 세 항목을 historic으로 표시합니다. IANA의 DMARC 항목 등록부 ↗

반면 2026년 9월 확인한 Google과 Microsoft의 운영 문서에는 pct 예시가 남아 있습니다. 새 표준의 발행과 모든 수신 서비스의 구현 변경은 같은 일이 아닙니다. 이 글에서는 pct=10을 “실패 메일의 정확히 10%만 영향을 받는 안전장치”로 추천하지 않습니다. 서비스별 공식 안내와 실제 수신 결과를 확인해야 합니다. Google 배포 예시 ↗ · Microsoft 배포 예시 ↗

새 t=y는 테스트 모드 요청입니다. 표준상 p=reject; t=y는 실패 메일에 quarantine 수준을 요청하므로 none과도 다릅니다. 더구나 t를 모르는 구현이 이를 무시하면 p=reject가 남습니다. 테스트라는 이름만 믿고 운영 도메인에 복사하지 마세요. 테스트 모드의 의미 ↗

발신처 목록에서 아직 확인하지 못한 업무 하나를 골라 실제 메일을 보내 보세요. 그 메일이 어느 도메인으로 인증되는지, 실패하면 누가 고칠 수 있는지 확인한 기록이 다음 정책을 결정하는 데 가장 직접적인 도움이 됩니다.