Microsoft 365 DMARC 롤아웃 가이드: 메일 전달을 깨뜨리지 않고 None에서 Reject까지

By Mirko Peters · 2026-10-21

Microsoft 365에서 조직의 정상적인 메일 전송에 영향을 주지 않으면서 모니터링 단계에서 엄격한 거부 정책까지 DMARC를 안전하게 도입하는 방법을 알아봅니다.

Automatically translated with AI from the original post. Read the English original

Microsoft 365 테넌트 전반에 이메일 인증 프로토콜을 순서 없이 적용하면 폭탄 해체처럼 아찔한 작업이 될 수 있습니다. 이 단계별 Microsoft 365 DMARC 롤아웃 가이드는 IT 관리자가 초기 모니터링에서 엄격한 거부 정책으로 안전하게 전환하는 과정을 안내하며, 정상적인 업무 송장, 마케팅 캠페인, 자동 알림이 실수로 사라지는 일을 막는 데 도움을 줍니다.

핵심 요약

• 이메일 인증은 반드시 올바른 순서로 도입하십시오. 먼저 SPF, 다음으로 DKIM, 마지막으로 DMARC를 적용합니다.
• DMARC 정책은 p=none으로 시작하여 트래픽을 모니터링하고, 정상적인 발신 서비스와 승인되지 않은 발신 서비스를 모두 파악하십시오.
• 마케팅 플랫폼이나 헬프데스크 같은 타사 서비스를 주의 깊게 점검하여 SPF의 10회 조회 한도를 넘지 않도록 하십시오.
• 엄격한 거부(reject) 정책에 도달하기 전에 격리(quarantine)와 백분율 설정을 단계적으로 적용하십시오.
• 지속적인 가시성을 확보하려면 집계 보고서를 개인 사서함이 아닌 공유 사서함으로 보내도록 구성하십시오.

배포 순서의 황금률

보안 강화 프로젝트에서 한 가지 원칙만 기억하신다면, 바로 배포 순서입니다. 많은 조직이 표준을 거꾸로 구현하면서 문제를 겪습니다. 이메일 시스템은 검증보다는 신뢰를 기반으로 설계된 SMTP 같은 레거시 프로토콜에 의존하므로, 인프라를 파악하기 전에 엄격한 시행 정책을 도입하면 정상적인 메일이 실패하게 됩니다.

올바른 순서는 모든 단계에서 안전망을 구축합니다. 먼저 허용 목록을 작성하고, 위변조 방지 봉인을 적용한 다음, 이 모든 것을 연결하는 심판 역할의 정책을 도입해야 합니다. 순서를 건너뛰면 자사 메일 흐름을 추측에 의존하게 되며, 추측은 외부 수신자에게 회사 메일이 차단되는 가장 빠른 길입니다.

1단계: SPF 설정과 조회 한도의 위험

첫 단계는 도메인의 루트에 발신자 정책 프레임워크(SPF) 레코드를 게시하는 것입니다. 이는 고급 클럽 입구의 방문자 명단과 같습니다. 여러분의 도메인 이름으로 메일을 보낼 수 있는 서버를 명시적으로 알려줍니다.

초기 Microsoft 365 SPF 레코드를 작성할 때는 하드 페일(-all) 대신 소프트 페일(~all)로 마무리하십시오. 이는 수신 서버가 승인되지 않은 메일을 즉시 거부하지 않고 의심스럽게 처리하도록 알려줍니다. 이 유예 기간을 통해 누락했을 수 있는 서비스를 찾아낼 여유가 생깁니다.

10회 조회 함정 피하기

SPF 관리에서 가장 큰 함정은 엄격한 10회 조회 한도입니다. 수신 서버가 SPF 레코드를 처리하면서 별도의 DNS 쿼리가 필요한 메커니즘, 예를 들어 타사 마케팅 자동화 플랫폼, 고객 지원 헬프데스크, 급여 처리 업체 같은 것을 만날 때마다 한도 중 하나를 소모합니다.

조직이 외부 서비스를 너무 많이 추가하면 총 조회 횟수가 10회를 넘어 SPF 평가 전체가 실패하게 됩니다. 수백만 개 도메인을 조사한 결과, 놀랍도록 많은 기업이 이런 방식으로 자사 이메일 보안을 의도치 않게 망가뜨리고 있는 것으로 나타났습니다. 서비스를 정기적으로 점검하여 SPF 구성을 간결하게 유지하십시오.

2단계: Microsoft 365에서 DKIM 활성화

게스트 목록을 게시한 뒤에는 메시지가 전송 중에 변조되지 않도록 보장할 방법이 필요합니다. DomainKeys Identified Mail(DKIM)은 발신되는 모든 메시지에 찍히는 디지털 밀랍 봉인과 같은 역할을 합니다. 제목, 본문, 표시되는 보낸 사람 주소를 포함하는 암호화 서명이 들어갑니다.

Microsoft 365 내에서 기본 onmicrosoft.com 도메인으로 보낸 이메일은 자동으로 서명됩니다. 그러나 사용자 지정 비즈니스 도메인은 관리 센터에서 DKIM을 명시적으로 구성하기 전까지 서명되지 않습니다. 이를 올바르게 설정하려면 공개 DNS에 두 개의 선택기 포인터(selector1, selector2)를 모두 만들어야 합니다. 이 이중 포인터 구성 덕분에 Microsoft는 나중에 서비스 중단 없이 서명 키를 순환할 수 있습니다.

Google 및 기타 주요 공급업체는 DMARC를 건드리기 전에 SPF와 DKIM이 최소 48시간 동안 문제없이 작동하도록 두라고 권장합니다. 이 안정화 기간을 거쳐야 심판이 등장하기 전에 기본 검사가 확실히 갖춰집니다.

3단계: 모니터 모드로 DMARC 배포하기

Domain-Based Message Authentication, Reporting, and Conformance(DMARC)는 심판 역할을 합니다. DMARC는 메시지 내용에 대해 별도의 검사를 수행하지 않습니다. 대신 SPF 및 DKIM 검사 결과를 살펴보고, 그 결과가 보낸 사람(From) 줄에 표시된 도메인 이름과 일치하는지 확인합니다.

처음으로 _dmarc.yourdomain.com에 DMARC TXT 레코드를 게시할 때는 정책 매개변수를 엄격하게 모니터 모드인 p=none으로 설정해야 합니다. 왼쪽에서 오른쪽으로 읽으면 이 레코드는 수신 서버에 다음과 같이 알려줍니다. "이것은 DMARC 레코드이며, 검사에 실패하더라도 당분간 시행 조치는 하지 말고, 집계 보고서를 이 이메일 주소로 보내라."

이 모니터링 단계는 절대 건너뛰지 마십시오. XML 파일로 전달되는 일별 집계(RUA) 보고서는 정상 서비스든 악성이든, 도메인을 대신해 메일을 보내는 모든 서비스를 낱낱이 드러냅니다. 이 보고서는 개인 직원의 받은 편지함이 아니라 모니터링되는 공유 사서함으로 보내서, 휴가 기간에 누락되지 않도록 하십시오.

4단계: 격리에서 거부로 전환하기

주간 검토에서 모든 정상 메일 흐름이 정렬 검사를 깔끔하게 통과하는 것을 확인했다면, 이제 나사를 조일 때입니다. DMARC 정책 매개변수는 세 가지 뚜렷한 운영 상태를 거칩니다.

• None(p=none): 감시탑입니다. 순수하게 관찰만 하며, 감사와 집계 보고 데이터 수집에 사용됩니다.
• Quarantine(p=quarantine): 경고 표지입니다. 수신 서버에 의심스럽거나 실패한 이메일을 표시하도록 지시하며, 일반적으로 수신자의 정크 메일 또는 스팸 폴더로 바로 보냅니다.
• Reject(p=reject): 잠긴 문입니다. 수신 측에 인증되지 않았거나 스푸핑된 메시지를 받은 편지함에 도달하기 전에 완전히 폐기하도록 지시합니다.

이 전환을 최대한 원활하게 하려면 DMARC 백분율 다이얼(pct=)을 활용하십시오. 실패한 메일의 일부(예: 10%, 그다음 25%, 50%)에만 격리 또는 거부를 적용한 뒤 완전히 전환할 수 있습니다. 이렇게 점진적으로 확대하면 잘 알려지지 않은 뉴스레터 도구를 놓쳤을 때에도 갑작스러운 업무 중단을 막을 수 있습니다.

결론

비즈니스 이메일 침해(BEC)와 도메인 스푸핑으로부터 조직의 이메일 인프라를 보호하려면 인내심과 체계적인 배포 전략이 필요합니다. SPF를 설정하고 DKIM을 활성화한 다음, 관찰 단계에서 엄격한 거부 단계까지 DMARC 정책을 신중하게 단계적으로 높이면, 회사의 이름을 지키고 정당한 커뮤니케이션이 언제나 목적지에 도달하도록 보장할 수 있습니다.

이메일 인증 프로토콜의 작동 원리를 더 깊이 알고 싶다면, 전문가의 통찰, 실질적인 아키텍처 전략, Microsoft 365 테넌트를 위한 실습 가이드를 확인할 수 있는 전체 에피소드를 들어보십시오.

자주 묻는 질문

Microsoft 365에서 DMARC 정책을 none으로 얼마나 오래 유지해야 하나요?

Google 및 이메일 보안 전문가들은 DMARC 정책을 최소 1주일 동안 p=none으로 유지할 것을 권장합니다. 이 기간이면 주간 및 주기적인 비즈니스 메일 흐름을 포괄하는 완전한 집계 보고서를 확보할 수 있습니다.

DMARC를 켜기 전에 DKIM을 활성화해야 하는 이유는 무엇인가요?

DKIM은 메시지에 암호화 서명을 하고 메시지와 함께 전달되므로, SPF가 자주 깨지는 이메일 전달 상황에서도 유지됩니다. SPF와 DKIM을 모두 올바르게 구성해야 DMARC 정렬 검사가 안정적으로 통과합니다.

Microsoft 365는 DMARC 포렌식 보고서를 보내나요?

아니요. Microsoft 365는 지정된 보고 주소로 종합(RUA) 보고서를 보내지만, DMARC 레코드에 요청되어 있더라도 포렌식(RUF) 보고서는 생성하거나 보내지 않습니다.

사용자 지정 도메인에 DMARC 레코드를 두 개 게시하면 어떻게 되나요?

DMARC 레코드를 여러 개 게시하면 수신 메일 서버가 혼란을 일으켜 어떤 정책도 적용하지 않게 되고, 그동안 기울인 보안 노력이 전부 무력화됩니다. 도메인에는 반드시 DMARC TXT 레코드를 정확히 하나만 두십시오.