DMARC 격리와 거부 정책으로 가기 전 확인해야 할 것

DMARC의 목적은 수신자가 보는 From 도메인을 공격자가 함부로 사칭하지 못하게 만드는 것이다. 수신 시스템은 SPF와 DKIM 결과 자체뿐 아니라 각각의 인증 도메인이 메시지의 From 도메인과 정렬(alignment) 되는지 판단한다.

SPF가 통과해도 Return-Path가 다른 도메인이라면 DMARC에는 도움이 되지 않을 수 있고, DKIM 서명이 유효해도 d= 도메인이 From과 관계없다면 마찬가지다.

따라서 정책 강화의 첫 질문은 “DMARC 레코드가 있는가”가 아니라 “우리 도메인을 From으로 쓰는 모든 발송 흐름을 알고 있는가”다. 마케팅 SaaS, 채용 시스템, 청구서 발송기, 고객지원 티켓, 지점 SMTP, 프린터와 장비 알림까지 목록에 없으면 reject 전환이 정상 메일 차단으로 이어진다.

1. 정책 전환 전에 발송원 지도를 만든다

최소 2~4주의 집계 보고서를 수집하되 월말·분기말 배치와 비정기 캠페인을 포함한다.

분류	확인할 증거	조치
승인된 직접 발송	소유 팀, 서비스 계정, 문서화된 인프라	SPF/DKIM 정렬 표준화
승인된 외부 SaaS	계약, 서비스 소유자, 벤더 설정	고유 DKIM과 반송 도메인 검토
전달·메일링리스트	헤더·본문 변경 기록	DKIM 보존, ARC, 별도 서브도메인 검토
미확인 또는 악성	소유자·변경 기록·업무 근거 없음	차단 후보로 두고 증거 보존

인벤토리에는 발송 IP만 적지 말고 From 도메인, Return-Path, DKIM selector와 d= 값, 예상 발송량, 소유 팀, 변경 티켓, 종료 예정일을 함께 남긴다. 클라우드 발송 서비스는 IP가 바뀔 수 있으므로 주소 목록만으로 소유권을 판단하면 안 된다.

2. 집계 보고서에서 봐야 할 지표

단순한 “DMARC 통과율 99%”로는 부족하다. 대량 마케팅이 통과하면 소량이지만 중요한 급여·계약 메일의 실패가 평균에 묻힐 수 있다.

• SPF 정렬과 DKIM 정렬 통과율을 각각 본다.
• 실패 메시지의 From, 소스 네트워크, disposition을 흐름별로 본다.
• 주요 수신 사업자의 보고가 갑자기 사라지는 보고 공백을 탐지한다.
• 새 selector, 새 발송 네트워크, 국가·ASN 변화에 소유자를 붙인다.
• 서브도메인별 실패율을 루트 도메인 평균과 분리한다.

보고서 파서는 XML 오류, 중복, 시간대 차이, 압축 크기 제한을 처리해야 한다. 처리 실패 건수와 마지막 정상 수신 시각을 모니터링하지 않으면 “문제가 없다”가 아니라 “관측이 끊겼다”일 수 있다.

3. none에서 quarantine, reject로 가는 단계

기본 레코드는 조직 도메인에 맞게 검토하되 다음처럼 단순하게 시작할 수 있다.

v=DMARC1; p=none; rua=mailto:[email protected]

전환은 문자열보다 중단 기준을 먼저 정한다.

1. p=none에서 승인 발송원을 식별하고 정렬 실패를 수정한다.
2. 영향이 작은 서브도메인이나 별도 발송 도메인부터 시험한다.
3. p=quarantine 후 스팸함 이동, 문의, 반송 증가를 확인한다.
4. 중요 흐름의 실패가 허용 범위 아래이고 미확인 발송원이 정리되면 p=reject로 올린다.
5. 루트·서브도메인과 존재하지 않는 서브도메인 정책을 따로 확인한다.

현행 DMARC 규격의 테스트·하위 도메인 관련 태그는 수신 사업자와 도구의 지원 상태가 다를 수 있다. 오래된 pct 중심 문서도 현장에 남아 있으므로 실제 적용 전 보고 분석기와 주요 수신자의 현재 지원 범위를 공식 문서로 다시 확인한다.

4. 가장 자주 생기는 실패 모드

SPF만 믿는 경우 전달 과정에서 발송 IP가 바뀌어 SPF가 깨질 수 있다. DKIM만 믿는 경우 메일링리스트가 제목이나 본문을 수정해 서명이 무효가 될 수 있다. 두 인증을 모두 구성하되 어느 하나가 정렬된 상태로 통과하도록 설계하는 편이 복원력이 높다.

외부 SaaS가 공용 DKIM 도메인으로만 서명하면 인증은 통과해도 조직 From과 정렬되지 않을 수 있다. 반대로 엄격 정렬을 성급하게 켜면 정상 서브도메인이 실패할 수 있다. 오래된 프린터나 장비 알림은 SMTP 릴레이를 우회해 직접 발송하면서 인벤토리에서 빠지는 경우가 많다.

한 도메인을 모든 목적에 쓰는 것도 위험하다. 대량 캠페인, 임원 메일, 트랜잭션 알림을 발송 서브도메인으로 나누면 평판과 정책 변경의 피해 범위를 줄일 수 있다.

5. 탐지와 대응 플레이북

신호	첫 확인	즉시 조치 후보
승인 발송원의 정렬 실패 급증	DNS·벤더·게이트웨이 변경	변경 중단, 이전 설정 비교
새 대량 발송 네트워크	캠페인·SaaS 도입 티켓	소유자 확인 전 허용 금지
reject 후 문의 급증	반송 코드와 대상 흐름	DKIM/SPF 수정, 정책 완화 검토
집계 보고서 수신 중단	메일박스·파서·주소 변경	관측 복구 전 상향 중단
브랜드 사칭 신고 지속	유사 도메인과 실제 From	유사 도메인 모니터링 병행

DNS TTL 때문에 정책 완화가 즉시 모든 수신자에 반영되지 않을 수 있다. 변경 창 전에 현재 TTL과 전파 시간을 기록한다. 롤백은 reject에서 quarantine 또는 none으로 완화하는 순서로 준비하되 SPF와 DKIM 레코드를 급히 삭제하지 않는다.

6. 변경 승인 체크리스트

• 조직 도메인을 From으로 쓰는 발송원이 소유자와 함께 등록돼 있다.
• 중요 흐름마다 SPF 또는 DKIM 정렬 통과 증거가 있다.
• 보고서 파서 실패와 보고 공백 알림이 있다.
• 전달·메일링리스트·SaaS 예외에 이유와 만료일이 있다.
• 정책 상향 후 확인할 반송률·문의·스팸 분류 지표가 정해져 있다.
• DNS 변경 권한과 이전 레코드 보존 절차가 있다.
• 롤백 담당자, 승인자, 예상 복구 시간이 문서화돼 있다.

함께 읽을 글

발송 시스템 계정과 외부 SaaS 권한은 SaaS 접근권한 검토와 함께 정리할 수 있다. 계정 자체의 피싱 저항성은 피싱 저항형 MFA 로드맵에서 이어서 볼 수 있다.

참고 기준

• RFC 9989: DMARC
• RFC 9990: DMARC Aggregate Reporting
• RFC 8617: Authenticated Received Chain
• NIST Cybersecurity Framework 2.0

DMARC 강제 정책의 완료 조건은 DNS에 reject가 보이는 순간이 아니다. 합법 발송원이 계속 도착하고, 미확인 발송은 차단되며, 보고 공백과 오탐을 운영팀이 정해진 시간 안에 설명할 수 있을 때 비로소 운영 가능한 상태가 된다.