마이크로소프트가 자사 소비자용 이메일 서비스에서 DMARC 레코드를 설정하지 않은 도메인에서 온 메일을 차단하기 시작했다. 지난 2026년 11월 5일부터 아웃룩닷컴, 핫메일, 라이브닷컴, MSN 주소로 발송되는 일부 메일이 ‘550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records’ 오류와 함께 반송되고 있다.
이번 조치는 사전 예고 없이 이루어졌다. 마이크로소프트는 별도의 공식 발표를 하지 않았으나, 관련 기술 커뮤니티와 관리자 포럼에서는 급격한 문의가 이어지고 있다. 특히 주목할 점은 이 차단이 대량 발송 업체에만 국한되지 않는다는 사실이다.
개인 사업자나 학교, 작은 사무실처럼 하루 수백 통 수준의 메일을 보내는 소규모 발송자들도 무작위로 메일이 튕겨 나가는 현상을 겪고 있다.
차단 패턴은 간헐적이다. 같은 발신 도메인에서 보낸 메일 중 하나는 정상 수신되지만 다음 하나는 반송되는 식이다. 이로 인해 발송자는 자신의 시스템에 문제가 있다고 오해하거나, 일시적인 네트워크 오류로 치부하기 쉽다.
하지만 제어 테스트 결과, DMARC 레코드를 삭제하면 아웃룩으로의 전송이 실패하고 비즈니스용 Microsoft 365로는 성공하는 것으로 확인되었다. 이는 소비자용 서비스에만 적용되는 별도 정책임을 시사한다.
마이크로소프트는 이미 2025년 4월, 일평균 5천 통 이상을 발송하는 대량 메일 발송자에게 SPF, DKIM 인증과 DMARC 레코드 게시를 의무화한 바 있다. 이를 위반하면 ‘550 5.7.515 Access denied’ 코드로 거절된다. 그러나 이번 새로운 차단은 이러한 대량 발송 기준과 무관하게 작동한다.
DMARC 레코드가 아예 존재하지 않는 모든 도메인을 대상으로 하기 때문이다.
해결 방법은 DNS 설정에 TXT 레코드를 추가하는 것이다. 가장 낮은 수준의 보호를 제공하는 ‘v=DMARC1; p=none’ 형식의 레코드만으로도 차단 현상은 즉시 멈춘다. 이 설정은 다른 수신처에서의 메일 처리 방식에는 영향을 주지 않으며, 마이크로소프트 측의 검증 로직을 충족시키는 최소한의 조건이다.
현재까지 마이크로소프트는 이 변경 사항에 대한 구체적인 로드맵이나 향후 확대 계획을 공개하지 않았다. 다만 기존 대량 발송 규정과 달리 소규모 발송자까지 포함한다는 점에서, 이메일 인증 인프라가 미비한 조직들은 즉각적인 대응이 필요하다. 반송 메시지에 포함된 서버 ID가 메시지마다 다르다는 점도 추적 난도를 높이는 요인으로 작용하고 있다.