2026년 11월 5일부터 마이크로소프트 이메일 필터가 정당한 메일을 DMARC 미비로 차단합니다. 갑작스러운 정책 변화와 버그가 겹쳐 혼란을 주며, 이메일 보안의 미래를 예고하는 사건입니다.
2026년 11월, 마이크로소프트 이메일 차단 사태 발생
2026년 11월 5일부터 마이크로소프트의 이메일 서비스(아웃룩, 핫메일, 라이브, MSN)를 이용하는 사용자들 사이에서 심각한 문제가 발생하고 있습니다. DMARC(Domain-based Message Authentication, Reporting, and Conformance) 레코드를 게시하지 않은 도메인에서 보낸 정당한 이메일들이 수신 거부되고 있는 현상입니다. 마이크로소프트는 이러한 정책 변경에 대한 공식적인 발표나 고지 없이 문제가 발생하여 사용자들의 혼란이 가중되고 있습니다. 전문가들은 이번 사태가 정책 변경과 버그가 동시에 작용한 결과일 수 있다고 지적합니다.
DMARC, SPF, DKIM: 이메일 보안의 새로운 표준
DMARC는 스푸핑, 피싱, 비즈니스 이메일 침해(BEC)로부터 사용자를 보호하기 위한 중요한 이메일 인증 프로토콜입니다. 마이크로소프트는 이미 2025년 5월부터 하루 5,000건 이상의 대량 이메일을 보내는 도메인에 대해 DMARC를 요구해왔습니다. 그러나 2026년 11월 5일부터는 소규모 일반 발신자들까지 DMARC, SPF(Sender Policy Framework) 또는 DKIM(DomainKeys Identified Mail)의 부재를 이유로 이메일이 차단되고 있습니다. 발신자들은 550 5.7.1 또는 550 5.7.23 오류 메시지를 받지만, 차단이 일관적이지 않아 더욱 혼란스럽습니다.
혼란을 가중시키는 오류 메시지와 불일치
현재 사용자들은 “메시지가 신뢰할 수 있는 위치에서 전송되었음을 확인할 수 없습니다”와 같은 다양한 오류 메시지를 보고하고 있습니다. 더욱이, 일부 차단된 도메인은 이미 유효한 SPF, DKIM, DMARC 레코드를 가지고 있는 것으로 확인되어 혼란을 더하고 있습니다. 마이크로소프트의 외부 스태프 모더레이터는 이를 “서비스 저하”로 표현하며 현재 활발히 조사 중이라고 밝혔습니다. MailRoute와 같은 이메일 보안 회사는 dig +short TXT _dmarc.example.com 명령어로 도메인의 DMARC 레코드 존재 여부를 확인할 수 있다고 조언합니다. 임시 해결책으로 v=DMARC1; p=none 레코드를 추가하여 보고서만 요청하고 조치는 취하지 않도록 설정할 수 있습니다.
DMARC: 이메일 위조를 어렵게 만드는 방패
DMARC는 SPF와 DKIM이라는 두 가지 핵심 인증 도구를 기반으로 합니다. SPF는 발신 서버의 IP 주소가 해당 도메인 대신 이메일을 보낼 권한이 있는지 확인하고, DKIM은 메시지에 암호화된 서명을 추가하여 메시지가 변조되지 않았음을 증명합니다. DMARC는 이 둘을 검사하여 발신 주소의 도메인이 인증된 도메인과 일치하는지 확인하고, 위조된 메시지에 대한 수신자의 처리 방식을 지시합니다. 이전에는 대량 발신자에게만 DMARC가 요구되었기 때문에, 많은 중소기업, 비영리 단체, 학교 등 소규모 발신자들은 이에 대비하지 못했습니다.
조용하고 불규칙적인 실패의 위험성
이번 오류의 가장 큰 문제는 불규칙성과 침묵입니다. 발신자는 알 수 없는 약어로 가득 찬 반송 메시지를 받고 단순한 오류로 여기고 넘어가는 반면, 정작 수신자는 이메일이 전송되었다는 사실조차 알지 못합니다. 이는 이메일 마케터들에게는 치명적인 문제입니다. 송장, 비밀번호 재설정, 예약 확인, 합격 통지서와 같은 중요한 이메일이 아웃룩, 핫메일, 라이브, MSN 사용자에게 전달되지 않으면, 고객이나 환자는 자신이 무시당한다고 생각할 수 있습니다. 다행히 모든 거부 메일은 반송을 생성하며 로그에 기록됩니다.
지금 당장 필요한 조치: 문제 해결 가이드
기업들은 2026년 11월 5일 이후의 메일 로그, 이메일 플랫폼의 반송 보고서, 헬프데스크 티켓에서 “메시지에 SPF/DKIM/DMARC가 없습니다”와 같은 항목을 즉시 검색해야 합니다. 가장 시급한 시간 민감성 거래 메일을 먼저 재전송하고, 모든 발신 도메인에 DMARC 레코드가 게시되었는지 확인하여 근본 원인을 해결해야 합니다. DMARC 레코드가 없는 경우, v=DMARC1; p=none과 같은 기본 모니터링 레코드를 추가하여 현재의 반송을 막을 수 있습니다. Microsoft 365 고객은 아직 DKIM을 활성화하지 않았다면 지금 바로 활성화해야 합니다. 궁극적인 목표는 위조 메일을 완전히 거부하는 p=reject 설정입니다.
다가올 미래의 신호: DMARC의 전면적 의무화
이번 마이크로소프트의 이메일 차단 문제는 단순한 버그를 넘어 DMARC가 모든 발신자에게 의무화될 미래를 예고하는 명확한 신호입니다. 구글과 야후는 2024년 2월부터 대량 발신자에게 DMARC를 요구했으며, 마이크로소프트 역시 2025년 5월부터 이를 따랐습니다. DMARC 요구사항은 항상 대량 발신자로부터 시작하여 모든 발신자의 기본 요건이 되는 추세입니다. 비록 이번 마이크로소프트의 DMARC 적용 방식은 미숙했지만, 그 목적지인 이메일 보안 강화는 분명합니다. “누구도 새로운 규칙을 반송 메시지를 통해 알게 되어서는 안 됩니다.”라는 지적처럼, 이메일 시스템의 투명하고 일관된 변화가 절실합니다.
