Microsoft, 아무 공지 없이 DMARC 없는 도메인의 메일을 Outlook.com에서 거부하기 시작

Outlook.com Is Quietly Rejecting Email from Domains Without DMARC

Microsoft, 아무 공지 없이 DMARC 없는 도메인의 메일을 Outlook.com에서 거부하기 시작

2026년 11월 5일부터 Microsoft의 소비자 메일 서비스가 DMARC 레코드가 없는 도메인의 메일 일부를 조용히 반송하고 있다. 대량 발신자만 겨냥한 기존 규칙과 달리 소규모 사업자의 한 줄짜리 답장도 튕겨 나간다. 게다가 같은 도메인의 메일 중 일부만 반송돼 '내 메일은 잘 간다'는 착각을 부른다. 해결책은 `v=DMARC1; p=none` TXT 레코드 하나다.

DMARC를 p=none으로 두는 것은 이제 모범 사례가 아니라 최소선이다.
  1. Neikius

    Outlook.com은 공개되지 않은 블록리스트를 기반으로 메일을 거부하기도 하는데, 사실상 빠져나올 수가 없습니다. 제 VPS 제공업체는 거의 전부 차단되어 있는데, 그쪽의 일반 블록리스트 절차에서는 우리가 문제없다고 나오니 차단 해제할 것도 없습니다.

    Outlook.com 같은 것들은 이메일에 있어서 정말 골칫거리입니다. 그래서 사람들이 메일 서버를 직접 운영하지 말라고 하는 거죠.

    반면에 DMARC가 없는 도메인을 거부하는 건 괜찮습니다. 다만 조용히 처리되는 게 마음에 안 들 뿐입니다.

  2. codethief

    Outlook.com은 수년간 특정 도메인/IP에서 오는 이메일을 조용히 버려왔습니다[0]. SPF/DKIM/DMARC가 모두 제대로 설정되어 있고 스팸 이력도 없는데도 말이죠. 자체 메일 서버를 관리하는 사람으로서 Outlook은 제 존재의 골칫거리였습니다.

    [0]: 즉, (로그상으로는) 이메일을 잘 받아들였지만 수신자의 메일함에는 결국 도착하지 않았다는 뜻입니다.

  3. stephbook

    이미 모든 메일 발신자가 했어야 할 일처럼 들리네요.

    Microsoft 고객에게는 좋은 일이고, 이제 와서 뒤늦게 패치해야 하는 게으른 사람들은 전혀 신경 쓰지 않습니다.

  4. klodolph

    제 개인 도메인에 DMARC를 설정한 게 언제인지 기억도 안 날 정도로 오래전 일입니다. 10년 이상 됐나?

    많은 제공업체들이 DMARC를 지원하지 않는 도메인을 거부하기 시작할 거라고 어느 정도 예상하고 있었습니다. 이게 이렇게 늦게 일어난다는 게 놀랍네요.

  5. dwm

    조용히 거부하는 게 아닙니다. 5xx 영구 전송 실패를 보내고 있어요.

  6. stevefan1999

    글쎄요, DMARC 시행 덕분에 좀 더 편안한 이메일 자체 호스팅 경험을 얻을 수 있다면, 스팸 위험을 감수하는 것보다는 표현의 자유를 맞바꾸는 좋은 트레이드오프라고 생각합니다.

    요즘은 Stalwart https://stalw.art/ 덕분에 제대로 된 메일 서버를 호스팅하는 게 그렇게 어렵지도 않습니다. 저는 LA에 있는 Talos Linux 클러스터에 유휴 자원을 활용해서 해봤는데, 꽤 괜찮습니다.

  7. shevy-java

    > 그 규칙은 마케터와 대량 발신자를 겨냥한 것이고, 대부분의 소규모 사업체는 자신들에게는 해당되지 않는다고 당연히 생각했습니다.

    그건 순진한 생각입니다. 현재 이는 Microsoft가 검열하고 당신이 무엇을 볼 수 있는지를 결정한다는 뜻입니다. 저는 Microsoft에게 그런 권한을 준 기억이 없습니다. 반면에 저는 어차피 이메일에 Microsoft를 쓰지 않습니다(안타깝게도 여기 지역 대학 하나가 쓰고 있어서 무척 짜증나지만요. 유럽은 이 부분에서 전략적으로 사고하지 못하고 있습니다).

  8. verandaguy

    흥미롭네요. 언젠가는 DPF/DKIM/DMARC 삼중주가 설정된 이메일에 점점 더 긍정적인 가중치를 주는 것이 바람직해질 것이라고 생각합니다. 그런 이메일이 문제 이메일(스팸이나 피싱)일 가능성이 가장 낮으니까요. 하지만 그것을 실제로 기본값으로 만드는 최선의 방법이 무엇인지는 의문입니다. 분명 이런 종류의 예고 없는 차단은 아닐 겁니다.

    이메일은 인기 있는 온라인 서비스 중 가장 분산된 축에 속하고, 레거시이거나 자체 관리되거나 그 외 엉성한 것들이 엄청나게 많습니다. SPF, DKIM, DMARC를 지원하는 것은 독립 운영자에게 부담을 주지만, 현재 상황에서 그것이 과도하거나 불합리한 부담일까요? 아니면 그저 새로운 사업 비용일 뿐일까요?

  9. green-salt

    그들이 수년간 gmail 등과 함께 이걸 해왔다고 생각했습니다. 저는 기본적으로 외부로 이메일을 보낼 때 올바른 DNS 레코드를 설정하는 것을 사업의 일부로 추가했을 뿐입니다.

  10. himata4113

    저는 이 점에 전적으로 동의합니다. 합법적인 서비스로 위장한 사기와 관련된 위험이 너무 큽니다. 해당 서비스의 개발자들이 DNS 레코드 한두 개 추가하는 것을 귀찮아했기 때문이죠.

    다만 아무런 공지도 없었다는 점이 문제인 것 같습니다. 하지만 아무도 그런 걸 읽지 않으니 상세한 이메일을 보내는 것도 충분한 해결책으로 보입니다.

이 날의 다른 글

2026-11-08