Outlook.com DMARC 거부, 대량 발신자 범위를 넘어선 것으로 보고
Microsoft가 공개한 인증 규정은 대량 발신 도메인에 초점을 맞추고 있지만, Outlook.com이 11월 5일부터 일부 소규모 발신자의 메시지를 거부하기 시작했다는 보고가 나왔다. 보고된 Outlook.com DMARC 거부는 DMARC가 없는 도메인과 관련이 있다. DMARC는 인증 결과를 수신자에게 보이는 주소와 연결하는 이메일 표준이다. 이 차이는 중요하다. 뉴스레터를 운영한 적 없는 발신자라도 일반적인 업무 회신이 전송 문제로 이어질 수 있기 때문이다.
이 보고는 자사 발신 시스템에서 관찰한 내용을 설명한 이메일 보안 제공업체 MailRoute에서 나왔다. Microsoft의 문서화된 정책은 이미 대량 발신자에게 더 강력한 인증을 요구한다. 새롭게 보고된 동작이 의도적인 확대 적용인지, 필터링 조정인지, 또는 구현상의 문제인지는 아직 확인되지 않았다.
핵심 쟁점은 예측 가능한 전송이다. 기업은 공개된 요구사항을 기준으로 계획을 세우지만, 수신 제공업체는 들어오는 메시지에 대해 재량권을 유지한다. Gmail은 이미 확립된 인증 요건을 이해하는 데 유용한 참고 사례를 제공한다. 그러나 당면한 질문은 Microsoft에 관한 것이다. 소규모 발신자가 공개 문서에서 명확히 설명하지 않은 더 광범위한 의무를 마주하고 있는가?
Outlook.com DMARC 거부에는 다른 오류가 표시된다
11월에 보고된 동작은 Microsoft가 이미 시행 중인 대량 발신자 규정과 구분해야 한다.
MailRoute 설립자 Thomas A. Johnson은 11월 6일 게시물에서 이러한 관찰이 전날부터 시작됐다고 밝혔다. 그는 Outlook.com, Hotmail, Live, MSN을 포함한 Microsoft 소비자 서비스에서 간헐적인 실패가 발생했다고 설명한다. MailRoute는 영향을 받은 트래픽에 일반적인 저용량 이메일도 포함된 것으로 보인다고 말한다.
보고된 오류에는 550 5.7.1 및 식별자 AS9031519가 포함되며, 인증 레코드 누락에 관한 문구가 함께 표시된다. 이는 Microsoft가 대량 발신자용 인증 거부로 문서화한 550 5.7.515와 다르다. 이 차이는 MailRoute의 인증 거부 설명에서 확인할 수 있다.
이 차이는 관리자가 보고 사례를 구분할 수 있는 구체적인 기준을 제공한다. 하지만 모든 발생 사례가 같은 원인을 가진다는 점을 입증하지는 않는다. 오류 식별자는 조사 출발점일 뿐, 수신자의 판단을 완전히 설명하는 근거는 아니다.
MailRoute는 일부 메시지는 성공하고 다른 메시지는 실패하는 등 결과가 일관되지 않았다고도 보고했다. 해당 설명은 보편적인 거부율이나 영향을 받은 도메인의 측정된 규모를 제시하지 않는다. 따라서 현재 증거는 서비스 전체 정책 발표가 확정됐다는 사실보다는, 전송 문제가 보고됐다는 점을 뒷받침한다.
시점 역시 신중하게 다뤄야 한다. 11월 5일은 MailRoute가 이러한 실패를 처음 관찰했다고 밝힌 날짜다. 이를 자동으로 Microsoft 규정의 공식 시행일로 간주해서는 안 된다. 동작을 관찰하는 것과 제공업체가 의도적으로 도입한 시점을 확인하는 것은 서로 다른 보도 주장이다.
“조용히”라는 표현에도 단서가 필요하다. 제공업체는 모든 조정을 발표하지 않은 채 필터링을 변경할 수 있으며, 운영상 결함은 문서화되지 않은 규정처럼 보일 수 있다. 어느 가능성도 의도를 입증하지는 않는다. 현 증거로는 Microsoft가 새 요구사항을 의도적으로 숨겼다고 말할 수 없다.
그러나 영향을 받은 조직의 입장에서는 이러한 불확실성이 운영상 질문을 없애주지 않는다. 근본 정책에 대한 논쟁이 확정적인 답에 이르기 전에도, 거부된 메시지는 여전히 조치가 필요하다. 유용한 대응은 전체 오류 내용, 대상 서비스, 발신 시스템, 시간을 포함한 증거를 보존하는 일에서 시작된다.
이러한 기록은 이 보고를 관련 없는 전송 실패와 구분하는 데 도움이 된다. 또한 흔한 실수를 예방한다. 가장 최근 주목받은 설명 아래 모든 Outlook 문제를 묶어 버리는 일이다. 증상이 메시지를 보내는 사람에게 비슷하게 보이더라도, 서로 다른 실패에는 서로 다른 대응이 필요할 수 있다.
그래서 광범위한 헤드라인보다 정확한 주장이 더 중요하다. 현재 이야기는 한 제공업체가 공개된 요구사항의 예상 범위를 넘어서는 특정 패턴을 보고한 데 관한 것이다. 그 패턴이 확립된 정책이 될지는 여전히 열린 질문이다.
소규모 발신자는 정책 답변보다 먼저 신뢰성 문제에 직면한다
소규모 조직도 대량의 이메일을 보내지 않으면서 심각한 전송 실패를 겪을 수 있다.
가상의 채용 과정을 생각해 보자. 채용 담당자가 지원자의 개인 Microsoft 메일함으로 면접 확인을 보낸다. 전송에 실패했는데 아무도 거부 통지에 대응하지 않으면, 지원자는 기술적 문제와 고용주의 침묵을 구분할 수 없다.
같은 논리는 잠재 고객에게 답하는 컨설턴트나 참석 확인을 보내는 커뮤니티 조직에도 적용된다. 이 사례들은 11월 보고서에 문서화된 사건이 아니라 노출 가능성을 보여 준다. 그 중요성은 전송과 누군가가 다음에 기대하는 행동 사이의 관계에서 나온다.
개별 메시지의 중요성을 판단하는 데 전송량은 좋은 척도가 아니다. 마케팅 캠페인은 일부 전송에 실패해도 여전히 잠재고객에게 도달할 수 있다. 반면 개인적인 교류는 실패한 바로 그 한 통의 메시지에 전적으로 좌우될 수 있다. 이러한 비대칭성은 소규모 발신자 관련 보고가 주목받을 만한 이유를 설명한다.
압박은 여러 역할에 걸쳐 발생한다. 직원은 실패한 대화를 마주하고, 관리자는 인증을 조사하며, 사업주는 놓친 약속을 처리한다. 명확한 인계가 없으면 각자는 다른 누군가가 문제를 담당하고 있다고 생각할 수 있다.
거부는 조직의 기존 워크플로에 있는 약점도 드러낼 수 있다. 자동 시스템에서 반송된 메시지를 누군가 검토하는가? 지원 담당자는 어떤 서비스가 고객 알림을 보냈는지 식별할 수 있는가? 중요한 교류가 실패했을 때 대체 연락 경로가 있는가?
Microsoft가 나중에 일시적 장애를 확인하더라도 이러한 질문은 유효하다. 이는 최종 정책 설명을 예측하는 문제가 아니라 운영 복원력에 관한 문제다. 조직은 예상한 연락이 실패했다는 사실을 알아차리기 전에 플랫폼의 확정적인 발표를 기다릴 필요가 없다.
간헐적인 동작은 이러한 책임을 더 까다롭게 만든다. 성공한 테스트는 팀을 성급하게 안심시킬 수 있고, 실패한 테스트는 불필요하게 광범위한 대응을 유도할 수 있다. 어느 결과 하나만으로는 조직의 모든 정상 메시지가 어떻게 동작할지 입증할 수 없다.
조사의 관련 단위는 실제 발신 경로다. 직원 메일함, 고객 지원 서비스, 애플리케이션 알림 시스템은 연관된 브랜드를 사용해 발신할 수 있다. 그럼에도 각각은 별도의 구성과 별도의 운영 책임자를 의미한다.
이러한 분산은 실질적인 위험을 낳는다. 팀이 가장 잘 아는 시스템만 수정한 뒤 조직 전체가 보호된 것으로 가정하는 것이다. 직원의 회신이 성공했다고 해서 송장이나 계정 알림을 보내는 무관한 서비스에 대해 알려 주는 것은 거의 없다.
조사를 문서화하는 팀은 전송 증거를 검색 가능한 지식 베이스와 함께 보관할 수 있다. 핵심 가치는 증상, 구성 변경, 책임자, 검증된 결과 간의 연결을 보존하는 데 있다.
따라서 즉각적인 비즈니스 대응은 상황에 맞아야 한다. 중요한 실패 교류를 식별하고, 증거를 보존하며, 책임자를 지정해야 한다. 그다음 통신 복구와 Microsoft의 동작에 관한 더 광범위한 주장을 입증하는 일을 구분해야 한다.
Microsoft의 공개 규정은 여전히 대량 발신 도메인에 초점을 둔다
Microsoft는 대량 발신자 인증 요건을 문서화했으며, 11월 보고는 이처럼 명확히 제시된 초점 밖의 동작에 대한 질문을 제기한다.
Microsoft는 2025년 4월 2일 요구사항을 발표했고, 4월 29일 시행 관련 설명을 업데이트했다. 이 업데이트에서는 2025년 5월 5일부터 거부가 시작된다고 명시했다. Microsoft의 대량 발신자 요구사항은 하루 5,000통을 초과해 발송하는 도메인을 설명한다.
이 발표는 해당 그룹에 SPF, DKIM, DMARC를 요구한다. SPF(Sender Policy Framework)는 도메인을 사용해 발신하도록 승인된 인프라를 식별한다. DKIM(DomainKeys Identified Mail)은 도메인의 암호화 서명을 사용해 서명된 메시지 콘텐츠를 인증한다.
Microsoft의 별도 인증 오류 안내는 550 5.7.515를 대량 발신자와 관련된 거부로 설명한다. SPF와 DKIM이 모두 통과해야 하며, 그중 최소 하나는 수신자에게 보이는 발신자 도메인과 정렬되어야 한다.
이러한 도메인 수준의 기준은 중요하다. 활발히 사용되는 조직 도메인에서 가끔 메시지를 보내는 사람이 문서화된 요구사항의 적용 대상 밖에 있는 것은 아닐 수 있다. 개별 메일함 활동과 도메인 전체 활동은 서로 다른 측정 기준이다.
따라서 겉보기에 소규모인 발신자를 조사하려면 그 직원이 몇 통을 보내는지만 물어봐서는 안 된다. 조직은 해당 도메인의 더 광범위한 발신 활동을 이해해야 한다. 그렇지 않으면 저용량 증거로 제시된 사례가 이미 공개된 범주에 포함될 수 있다.
이 차이는 핵심 갈등도 명확히 한다. 이 이야기는 단순히 Microsoft가 인증을 요구하고 기업이 이에 저항하는 문제가 아니다. 더 유용한 질문은 관리자가 문서화된 범위와 관찰 가능한 오류를 통해 자신의 의무를 정확히 파악할 수 있는지에 관한 것이다.
Gmail은 이 질문을 해결하지는 않지만 관련 맥락을 제공한다. Gmail의 이메일 발신자 요구사항은 일반 의무와 개인 Gmail 계정에 하루 5,000통을 초과해 보내는 발신자에게 적용되는 추가 규정을 구분한다. 추가 인증 요건에는 DMARC가 포함된다.
이 비교는 더 강력한 인증 요구가 확립된 업계 관행임을 보여 준다. 그러나 Microsoft가 11월의 동작을 의도적으로 구현했다는 사실을 입증하지는 않는다. 유사한 보안 목표는 서로 다른 임계값, 오류 처리, 시행 일정, 지원 절차와 공존할 수 있다.
기업에 있어 Outlook DMARC 요구사항의 실질적인 문제는 규정을 이해하는 것과 해당 규정이 적용됐음을 인식하는 것 사이의 간극이다. 문서는 관리자가 실패가 그 규정 때문인지, 다른 수신 측 판단 때문인지 판단하는 데 도움을 줘야 한다.
Microsoft에 있어서는 더 명확한 소통이 불필요한 문제 해결을 줄일 수 있다. 정확한 설명은 영향을 받는 트래픽, 예상 인증 상태, 관련 거부 식별자를 명시할 수 있다. 그러면 정상 발신자는 산발적인 관찰을 보편적 주장으로 확대하지 않고 대응할 수 있다.
그러한 설명이 나오기 전까지는 확립된 정책이 신뢰할 수 있는 기준점으로 남는다. 11월 보고는 실제로 보여 주는 범위를 넘어 어느 한 출처도 확대 해석하지 않으면서, 기존 정책과 함께 조사할 가치가 있다.
공개된 레코드와 인증된 메일은 같지 않다
DMARC 레코드를 추가하면 누락 문제는 해결할 수 있지만, 레코드가 존재한다는 사실만으로 메시지가 올바르게 인증된다는 뜻은 아니다.
이 구분은 이 이야기의 기술적 쟁점 중심에 있다. 기업은 도메인에 관한 선언을 게시할 수 있지만, 특정 발신 서비스는 여전히 잘못 구성되어 있을 수 있다. 선언 자체와 실제로 전송된 메시지의 동작은 별도로 평가해야 한다.
정렬은 인증된 도메인이 메시지의 From 주소에 표시된 도메인과 일치하거나 적절한 관련성이 있음을 의미합니다. DMARC는 이 관계에 따라 달라집니다. 관련 없는 서비스 도메인에 대한 인증 검사가 통과했다고 해서 조직의 표시상 신원이 자동으로 검증되는 것은 아닙니다.
DMARC specification도 도메인 소유자의 처리 선호와 수신 시스템의 처리 방식을 구분합니다. v=DMARC1; p=none만 포함된 최소 레코드는 인증 실패에 대한 특별한 처리 방침을 선호하지 않는다는 뜻입니다.
이 설정은 누락된 권한을 보완하거나, 유효한 서명을 만들거나, 관련 없는 인증 신원을 정렬 상태로 만들지 않습니다. 또한 받은편지함 도착을 보장하지도 않습니다. 이 텍스트를 범용적인 전송 문제 해결책으로 간주하면 도메인 선언과 성공적인 메시지 인증을 혼동하게 됩니다.
보고 기능은 또 다른 구분을 만듭니다. 위의 최소 레코드는 관찰된 인증 활동을 요약하는 집계 보고서의 수신처를 지정하지 않습니다. 이러한 보고서를 요청하려면 rua 필드를 통해 적절한 보고 주소를 설정해야 합니다.
이는 누군가 최소 레코드가 자동으로 모니터링을 활성화한다고 설명할 때 중요합니다. 정책을 게시하는 일과 활용 가능한 피드백을 받는 일은 별개의 활동입니다. 조직이 그 피드백을 의사결정에 활용하려면 실제 보고 체계를 갖춰야 합니다.
11월의 주장을 추적하는 독자에게 더 넓은 교훈은 증거의 질에 관한 것입니다. 의미 있는 복구 보고서는 무엇이 바뀌었고 이후 어떤 일이 일어났는지 말해야 합니다. 누군가가 “DMARC를 추가했다”고 발표하는 것만으로는 중요한 질문들이 남습니다.
관리자가 발신 서비스를 함께 변경했는가? 다른 경로가 성공한 테스트를 처리했는가? 원래의 메시지 유형은 같은 수신 서비스에 도달했는가? 이러한 세부 사항이 관찰자가 겉보기 수정 조치를 얼마나 신뢰해야 하는지 결정합니다.
조직은 직원 이메일과 다른 발신 시스템도 분리해 살펴봐야 합니다. 애플리케이션 공급업체는 주 메일함 제공업체와 다르게 인증을 구성할 수 있습니다. 같은 표시 브랜드라고 해서 동일한 인증 신원을 의미하지는 않습니다.
이는 전송 가능성이 도메인 소유권과 서비스 구성 사이의 지속적인 관계임을 보여줍니다. 도메인 설정을 관리하는 사람에게는 발신 애플리케이션을 운영하는 사람들의 정보가 필요합니다. 어느 한 역할만으로 전체 상황을 반드시 파악할 수 있는 것은 아닙니다.
실질적인 균형점은 분명합니다. 작은 구성 변경은 간단할 수 있지만, 그 효과를 검증하려면 신중함이 필요합니다. 책임 있는 결론은 누락된 레코드는 주의가 필요하지만, 성공적인 인증에는 실제로 전송되는 메시지의 증거가 필요하다는 것입니다.
증거는 아직 보편적인 Microsoft 정책을 입증하지 못한다
현재 이용 가능한 보고서는 신뢰할 만한 조사 단서를 제시하지만, 11월 현상의 범위와 원인은 여전히 해결되지 않은 상태로 남아 있습니다.
MailRoute는 자사 시스템을 통과하는 트래픽을 직접 확인할 수 있습니다. 따라서 그 관찰은 이 사안과 관련이 있습니다. 동시에 이메일 서비스를 판매하기 때문에, 독자는 운영상 증거와 자사의 상업적 제공과 연결된 권고를 구분할 필요가 있습니다.
상업적 관여가 보고서의 효력을 무효로 만들지는 않습니다. 다만 서로 다른 인프라를 사용하는 조직의 교차 검증 가치를 높입니다. 독립적인 관찰은 해당 패턴이 특정 제공업체의 고객과 발신 경로를 넘어 확장되는지 판단하는 데 도움이 됩니다.
현재의 검증 공백은 누군가가 거부 메시지를 받았는지 여부를 넘어섭니다. 왜 그 메시지가 실패했는지, 그리고 같은 설명이 다른 상황에도 적용되는지가 핵심입니다. 실제 실패 사례도 지나치게 광범위한 해석을 뒷받침할 수 있습니다.
여러 설명이 여전히 가능합니다. Microsoft가 추가 인증 신호를 적용하고 있을 수 있고, 기존 필터링을 조정하고 있을 수도 있으며, 구현 문제를 겪고 있을 가능성도 있습니다. 도메인에 관리자가 처음 인지한 것보다 더 많은 발신 활동이 있을 수도 있습니다. 현재 증거는 이 설명들 중 어느 하나를 결정적으로 선택하지 못합니다.
이는 조사를 위한 가설이지 Microsoft 내부 시스템에 대한 발견이 아닙니다. 뒷받침하는 증거 없이 메커니즘을 단정하면 이야기는 더 완전해 보일 수 있지만 신뢰도는 낮아집니다.
가장 강력한 추가 증거는 수신 측 오류를 메시지의 인증 상태 및 관련 도메인 구성과 연결하는 것입니다. 통제된 비교는 실패와 복구 사이의 변경 사항도 기록해야 합니다. 이런 연결이 없다면 시점만으로도 오해를 낳을 수 있습니다.
예를 들어, 구성 업데이트 후 전송에 성공했다고 해서 업데이트의 모든 부분이 중요했다는 뜻은 아닙니다. 이후 재전송이 성공했다고 해서 원래의 거부가 무해했다는 증거도 아닙니다. 간헐적인 결과는 두 인과 주장 모두를 복잡하게 만듭니다.
수신자가 메일을 거부하는 것과 메일이 조용히 사라지는 것의 차이도 신중히 다뤄야 합니다. 거부는 발신자에게 눈에 보이는 실패를 만들 수 있습니다. 그 실패가 관리되지 않는 시스템에 도달하거나 후속 조치가 없을 때 운영상의 문제는 덜 눈에 띄게 됩니다.
이런 모든 사건을 “무음 차단”이라고 부르면 그 차이가 흐려집니다. 조직은 수신자가 메시지를 거부했는지, 수락했는지, 혹은 예상치 못한 곳에 배치했는지 알아야 합니다. 이 결과들은 서로 다른 증거와 책임을 의미합니다.
Outlook과 Gmail의 인증 비교 역시 인과관계를 입증할 수 없습니다. Gmail에는 도달했지만 Outlook에서는 실패한 메시지는 서로 다른 결과를 보여줍니다. 그것만으로는 어떤 Microsoft 검사가 차이를 만들었는지 식별할 수 없습니다.
따라서 가장 방어 가능한 설명은 경계를 명시적으로 유지합니다. 한 제공업체는 겉보기에는 소규모 발신자와 관련된 새로운 패턴을 보고합니다. Microsoft는 기존의 대량 발신 요건을 문서화하고 있습니다. 이 두 사실의 관계는 여전히 핵심적인 미해결 질문입니다.
독자는 이 불확실성을 유용한 정보로 다뤄야 합니다. 이는 추가 보도가 무엇을 입증해야 하는지 정의하고, 관리자가 진단을 헤드라인으로 대체하지 않도록 돕습니다.
다음 상황을 결정할 세 가지 신호
이 이야기의 다음 단계는 더 명확한 범위, 독립적인 재현, 그리고 검증된 복구에 달려 있습니다.
첫 번째 신호는 Microsoft의 공개 설명입니다. 앞으로 수개월간 가장 중요한 전개는 보고된 11월 거부 식별자를 직접 다루는 지침일 것입니다. 유용한 업데이트라면 영향을 받는 발신자, 인증 기대치, 기존 대량 발신 규정과의 관계를 명시할 것입니다.
낮은 발신량의 도메인으로 명시적으로 확대한다면 Outlook.com의 DMARC 거부가 더 광범위한 의무를 반영한다는 해석이 강화됩니다. 문서화된 사고나 수정은 그 해석을 약화시킵니다. 어느 결과든 관리자에게 의사결정의 더 확고한 근거를 제공합니다.
설명의 질은 존재 여부만큼 중요합니다. 이메일 인증에 대한 일반적인 알림은 보고된 불일치를 해결하지 못합니다. 관리자는 관찰된 거부를 문서화된 원인과 연결할 수 있을 만큼 충분한 세부 정보가 필요합니다.
두 번째 신호는 독립적 재현입니다. 관련 없는 발신 제공업체들의 보고는 비교 가능한 증거를 포함할 때 더 큰 비중을 갖습니다. 핵심 질문은 같은 누락 레코드 조건이 같은 수신 오류와 반복적으로 함께 나타나는지입니다.
진정으로 낮은 발신량 도메인과 관련된 증거는 특히 중요합니다. 이는 개별 발신자는 작아 보였지만 전체 도메인은 기존 임계값을 충족했을 가능성을 다룹니다. 따라서 보고서는 개인의 발신 활동과 도메인 전체 트래픽을 구분해야 합니다.
서로 다른 환경에서 일관되게 재현된다면 더 광범위한 동작이라는 주장이 강화됩니다. 실패가 특정 경로 또는 구성에 한정된다면 이야기의 범위는 좁아집니다. 두 결과 모두 누가 압박을 받는지에 대한 불확실성을 줄이므로 유용합니다.
세 번째 신호는 문서화된 수정 후 지속적인 복구입니다. 관리자는 원래 발신 경로의 정상 트래픽이 계속 작동한다는 증거가 필요합니다. 초기 문제가 간헐적인 결과에 관한 것이라면, 단 한 번의 성공적인 메시지는 안심할 근거가 되기 어렵습니다.
가장 유익한 복구 사례는 구성 변경을 분리하고 비교 가능한 변경 전후 증거를 보존합니다. 다른 변경 없이 유효한 레코드를 추가하는 것만으로 같은 실패가 일관되게 해결된다면, 보고된 연관성은 더 설득력을 얻습니다.
올바른 인증에도 실패가 지속된다면 누락 레코드 설명은 덜 완전해집니다. 그러면 관심은 다른 수신 결정이나 구현 문제로 향하게 됩니다. 또한 도메인 레코드를 전체 해결책으로 제시하는 단순화된 조언에도 의문을 제기하게 됩니다.
이 신호들은 전망을 현실에 기반하게 합니다. 문제는 이메일 인증이 유행하게 될지, 또는 제공업체가 계속 악용과 싸울지가 아닙니다. 문제는 Microsoft가 요건을 얼마나 명확하게 정의하고, 정상적인 발신자가 준수 사실을 얼마나 안정적으로 입증할 수 있느냐입니다.
비즈니스 독자에게 이러한 답을 기다린다고 해서 현재의 실패를 무시해서는 안 됩니다. 오류를 반환한 중요한 통신을 검토하고, 그 발신 시스템을 식별하며, 누군가가 조사를 책임지도록 하십시오. 설정을 바꾸기 전에 원본 증거를 보존하고, 이후에는 같은 정상 경로를 통해 전송을 검증하십시오. Outlook.com DMARC 거부는 관련 없는 인프라 변경의 이유가 아니라 구체적인 신뢰성 문제로 다루십시오. 제공업체에 어떤 인증 검사가 통과했는지, 어떤 신원을 검증했는지, 수신 서비스가 실제로 무엇을 거부했는지 설명해 달라고 요청하십시오. 제안된 해결책이 레코드 존재만 다룬다면, 영향을 받은 메시지가 이제 인증을 통과하고 일관되게 도착한다는 증거를 요구하십시오. Microsoft의 더 광범위한 입장이 불분명한 동안 적용할 만한 실질적인 기준은 그것입니다.
