DMARC, 이메일 도메인을 피싱에서 지키는 최소한의 정책

슬랙, 팀즈, 메신저가 많아졌지만 이메일은 여전히 기업 커뮤니케이션의 중심에 있습니다. 계약, 청구, 계정, 알림, 마케팅까지 대부분의 외부 접점은 이메일을 지나갑니다.

그래서 이메일 도메인은 공격자에게 좋은 표적입니다. 우리 회사 도메인처럼 보이는 발신자로 피싱 메일을 보내면 수신자는 실제 내부 메일로 착각하기 쉽습니다.

DMARC는 이런 도메인 스푸핑 문제를 줄이기 위한 이메일 인증 정책입니다. SPF와 DKIM의 인증 결과를 바탕으로, 인증에 실패한 메일을 수신 서버가 어떻게 처리해야 하는지 알려줍니다.

SPF와 DKIM만으로 부족한 이유

SPF는 어떤 서버가 내 도메인으로 메일을 보낼 수 있는지 DNS에 등록하는 방식입니다. 수신 서버는 발신 IP가 허용 목록에 있는지 확인합니다.

DKIM은 메일에 디지털 서명을 붙이는 방식입니다. 수신 서버는 DNS에 공개된 키로 서명을 검증해 메일이 위조되거나 변조되지 않았는지 확인합니다.

하지만 SPF와 DKIM이 있다고 해서 정책이 완성되는 것은 아닙니다. 인증에 실패한 메일을 어떻게 처리할지 명확하지 않고, 도메인 소유자가 실패 현황을 체계적으로 받아보기 어렵습니다.

DMARC는 이 빈틈을 메웁니다. 도메인 소유자는 DNS TXT 레코드로 정책을 게시하고, 수신 서버는 SPF 또는 DKIM 정렬 결과를 확인한 뒤 그 정책을 적용합니다.

DMARC 레코드의 기본 형태

DMARC는 _dmarc.example.com 같은 위치에 TXT 레코드로 설정합니다.

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

가장 중요한 태그는 p입니다.

1. none: 실패 메일을 차단하지 않고 보고만 받습니다.
2. quarantine: 실패 메일을 스팸함 등 격리 위치로 보내도록 요청합니다.
3. reject: 실패 메일을 거부하도록 요청합니다.

처음부터 reject로 시작하는 것은 위험할 수 있습니다. 실제 발신 시스템이 모두 정리되지 않은 상태에서 강한 정책을 걸면 정상 메일도 막힐 수 있습니다.

정렬이라는 조건

DMARC에서 중요한 개념은 alignment, 즉 정렬입니다. 단순히 SPF나 DKIM이 통과하는 것만으로는 충분하지 않습니다. 인증에 사용된 도메인이 사용자에게 보이는 From 도메인과 정렬되어야 합니다.

예를 들어 메일 화면에는 example.com에서 온 것처럼 보이지만, SPF는 전혀 다른 발신 도메인으로 통과한다면 DMARC 관점에서는 문제가 될 수 있습니다. DMARC는 사용자가 보는 도메인을 보호하려는 정책이기 때문입니다.

이 지점 때문에 외부 발송 서비스 설정이 중요합니다. 마케팅 도구, 고객지원 도구, 결제 알림 도구가 각각 DKIM과 SPF를 제대로 설정하지 않으면 DMARC 정책 강화 단계에서 정상 메일이 실패할 수 있습니다.

보고서가 운영의 핵심입니다

DMARC의 장점은 정책뿐 아니라 보고서입니다. rua를 설정하면 수신 서버가 집계 보고서를 보내줄 수 있습니다. 이 보고서를 보면 어떤 IP와 서비스가 우리 도메인으로 메일을 보내고 있는지, 어떤 메일이 SPF/DKIM/DMARC를 통과하거나 실패하는지 확인할 수 있습니다.

실무에서는 보고서 없이는 정책을 강화하기 어렵습니다. 어떤 발송자가 정상인지, 어떤 발송자가 오래된 시스템인지, 어떤 발송자가 악성인지 구분해야 하기 때문입니다.

따라서 DMARC 도입은 보통 다음 순서가 안전합니다.

1. p=none으로 시작해 보고서를 수집합니다.
2. 정상 발송 시스템의 SPF와 DKIM을 정리합니다.
3. 실패 원인을 줄인 뒤 quarantine으로 일부 적용합니다.
4. 충분히 안정화되면 reject로 강화합니다.

피해야 할 접근

DMARC를 단순히 보안 체크리스트 항목으로만 보면 설정은 있지만 효과는 없는 상태가 됩니다.

예를 들어 p=none을 영구적으로 유지하면서 보고서를 보지 않으면 실제 차단 효과는 없습니다. 반대로 발송 시스템을 파악하지 않고 p=reject를 걸면 정상 업무 메일이 막힐 수 있습니다.

또한 SPF 레코드에 너무 많은 서비스를 무분별하게 추가하는 것도 좋지 않습니다. 권한을 넓게 열어두면 도메인 신뢰를 지키는 목적이 약해집니다.

정리

DMARC는 이메일 보안의 끝이 아니라 시작점입니다. SPF와 DKIM을 연결하고, 인증 실패 메일의 처리 정책을 정하고, 보고서를 통해 실제 발송 상태를 관찰하게 해줍니다.

가장 현실적인 접근은 작게 시작해 점진적으로 강화하는 것입니다. 먼저 p=none으로 관찰하고, 정상 발송 시스템을 정리한 뒤, quarantine, reject로 이동해야 합니다.

이메일 도메인은 브랜드 이름표입니다. 누가 그 이름표를 달고 메일을 보내는지 모른다면, DMARC부터 확인해야 합니다.

참고

• RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance
• dmarc.org - DMARC specifications