이 페이지의 내용Outlook.com과 2025년 5월 규정
"Outlook"에는 서로 다른 세 가지 필터가 있으며, 어떤 필터가 이메일을 Junk로 이동했는지에 따라 해결 방법이 달라집니다. 첫째는 Microsoft의 개인용 메일 서비스인 Outlook.com이며, hotmail.com, live.com, msn.com 주소도 이 서비스를 사용합니다. 둘째는 기업이 비용을 지불해 사용하는 비즈니스 메일함인 Microsoft 365이며, 수신자 회사의 관리자가 스팸 정책을 설정합니다. 셋째는 사용자의 컴퓨터에 설치된 Outlook 앱이며, 서버의 판단과 별도로 자체 Junk 필터를 추가로 실행할 수 있습니다. Microsoft가 2025년에 발표한 발신자 규칙은 이 중 첫 번째에만 적용됩니다.
따라서 DNS 레코드를 하나라도 변경하기 전에 먼저 수신자의 주소를 확인합니다. hotmail.com 또는 outlook.com 주소라면 아래의 개인용 서비스 규칙이 적용됩니다. Microsoft에서 메일을 운영하는 회사의 주소라면 해당 회사의 IT 팀이 작성한 테넌트 정책이 적용됩니다.
Outlook.com과 2025년 5월 규정
2025년 4월, Microsoft는 소비자 서비스로 하루 5,000통이 넘는 이메일을 보내는 도메인에 대한 요구 사항을 발표했습니다. Postmaster 정책 페이지에 따르면 이 요구 사항은 2025년 5월 5일부터 적용되었습니다. 이 발송량을 초과하면 다음 조건을 충족해야 합니다.
- 발송 도메인의 SPF 검증을 통과해야 합니다.
- DKIM 검증을 통과해야 합니다.
- DMARC를 "최소 p=none"으로 게시하고 SPF 또는 DKIM과 정렬해야 하며, "둘 다 정렬하는 것이 좋습니다". 정책 페이지에서는
p=reject사용도 권장합니다.
반송 메일 관련 지원 문서에서는 이를 약간 다르게 설명합니다. From 주소에 모두 같은 도메인을 사용하는 메시지를 Microsoft 소비자 서비스로 5,000통 이상 보내는 경우로 계산하며, SPF와 DKIM 검증을 모두 통과해야 한다고 명시합니다. 도메인이 이 기준에 도달하면 Microsoft는 기준을 넘게 만든 뉴스레터뿐만 아니라 "도메인 내 발신자가 보내는 모든 메시지"가 규정을 충족하기를 요구합니다. 문서에 나온 DMARC 예시는 레코드로서 거의 최소한의 구성입니다.
Hostname: _dmarc
TXT value: v=DMARC1; p=none여기에 보고서 수신 주소를 추가하는 것이 좋습니다. rua=mailto:dmarc@example.com 또는 실제로 메일을 확인하는 주소를 사용하세요. Outlook.com은 집계 보고서를 전송합니다. Microsoft의 FAQ에 따르면 RUA는 전송하지만 RUF는 전송할 계획이 없습니다. DMARC 검사기에서 지정한 주소가 보고서를 받을 수 있는지 확인할 수 있습니다.
Google은 2024년 2월 Gmail에 대해 하루 5,000통이라는 동일한 기준을 도입했고, 2025년 11월에는 수신 거부를 포함한 단계적 적용을 시작했습니다. Yahoo도 기준량을 명시하지 않은 채 유사한 규정을 적용합니다.
이 규정의 적용 방식은 발표가 나온 지 얼마 되지 않아 변경되었습니다. 최초 게시물에서는 규정을 준수하지 않는 메일을 먼저 Junk로 보내고 추후 거부할 수 있다고 설명했습니다. 4월 29일 자 업데이트에는 Microsoft가 메일을 거부하기로 결정했다고 나옵니다. 하지만 같은 게시물 아래쪽에는 먼저 Junk로 보낸다는 기존 문단이 여전히 남아 있습니다. 현재 신중하게 해석하면 2025년 5월 5일부터 규정을 준수하지 않는 메일은 Junk로 전달되며, 이제 Outlook.com은 다음 메시지와 함께 메일을 거부하기도 합니다.
550 5.7.515 Access denied, sending domain example.com does not meet the required authentication level.
수신 거부 방식으로 전환된 날짜는 공개된 자료에서 찾지 못했습니다. 지원 문서는 단순히 현재 시제로 이를 설명합니다.
반송 코드가 알려주는 내용
Outlook.com의 반송 응답은 정크 메일함에 조용히 들어간 메시지보다 유용합니다. 반송 이유를 알려주기 때문입니다. Microsoft의 문제 해결 페이지에는 코드 표가 있으며, 일반 발신자에게 자주 발생하는 코드는 다음과 같습니다.
| 코드 | Microsoft가 설명하는 의미 |
|---|---|
550 5.7.515 | 도메인에서 하루 5,000통이 넘는 이메일을 보내지만 SPF, DKIM 및 DMARC 인증이 설정되지 않음 |
550 SC-001 | 정책에 따른 거부, "content with spam-like characteristics or IP/domain reputation" |
550 SC-004 | 해당 IP에서 발송된 이메일에 대한 신고로 인해 IP가 차단됨 |
421 RP-001 | 연결하는 IP에 적용된 전송 속도 제한이며, 이 역시 평판이 원인임 |
Microsoft 고유 코드가 없는 일반적인 550 5.7.1은 또 다른 유형의 거부이며, 이 응답을 해석하는 별도 페이지가 있습니다.
타사 발신자와 SPF 요구 사항
많은 도메인이 뉴스레터 플랫폼, CRM, 헬프 데스크, 청구 서비스 등 여러 서비스를 통해 동시에 이메일을 보냅니다. 각 서비스는 From 줄에 해당 도메인을 사용해 이메일을 보내므로 모두 DNS 레코드에 포함되어야 합니다. 제공업체가 대신 이메일을 보내는 경우에도 규칙이 적용되는지에 대해 Microsoft의 FAQ는 "그렇습니다. 이메일 발송을 외부에 맡기더라도 인증은 해당 도메인에 연결됩니다."라고 답합니다. 지원 문서에는 확인해야 할 사항도 명시되어 있습니다. DKIM이 해당 도메인으로 서명하는지, SPF 레코드에 "서비스에 필요한 IP 주소 또는 include 값이 포함되어 있는지" 확인해야 합니다.
SPF와 DKIM을 모두 요구하면 이 부분이 복잡해집니다. 많은 플랫폼은 반송 주소에 자체 도메인을 사용하며, SPF가 실제로 확인하는 것은 이 Return-Path입니다. 이 경우 플랫폼에 대해 SPF가 통과하므로 "통과해야 한다"는 조건은 충족되고, DMARC 정렬은 해당 도메인을 사용하는 DKIM 서명을 통해 이루어져야 합니다. 플랫폼이 자체 도메인으로 서명하면 두 검사는 통과하지만 정렬은 하나도 되지 않으며, 그 결과 발생하는 DMARC fail이 바로 5.7.515의 원인입니다. 지원 문서에서는 Return-Path 도메인이 From 도메인과 정렬되는지도 확인하라고 안내합니다.두 검사 통과, 정렬은 0개: 이것이 5.7.515의 전체 원인입니다
SPF에 서비스를 추가할 때마다 DNS 조회 횟수도 늘어납니다. Microsoft의 FAQ에서는 이를 다음과 같이 설명합니다. "DNS 조회 횟수가 10회를 초과하면 SPF 검사에 실패할 수 있습니다." SPF 검사기가 조회 횟수를 계산해 주며, 10회를 초과했다면 10회 미만으로 줄이는 방법을 확인하세요. DKIM 검사기는 각 플랫폼의 selector가 일치하는지 확인합니다.
Microsoft 365는 다른 조직의 정책에 따라 필터링됩니다
Microsoft 365 조직에는 관리자가 구성하는 스팸 방지 정책이 있습니다. 기본 설정에서는 스팸, 신뢰도 높은 스팸, 대량 메일이 Junk Email 폴더로 이동하며, 피싱은 격리되고 신뢰도 높은 피싱은 항상 격리됩니다. 발신자 입장에서 가장 큰 피해를 주는 결과는 격리입니다. 수신자가 직접 찾아보지 않으면 어떤 폴더에서도 메시지를 발견할 수 없기 때문입니다. 기본 정책은 메시지를 15일간 격리하며, Standard 및 Strict 사전 설정은 30일간 격리합니다.
대량 메일에는 별도 지표인 대량 메일 신고 수준이 적용됩니다. BCL 1~3은 신고가 적은 대량 발신자를, 8 또는 9는 신고가 많은 발신자를 의미합니다. 기본 정책은 BCL 7부터 대량 메일을 Junk로 보내며, Standard 사전 설정은 6부터, Strict는 5부터 보냅니다. 2026년 7월부터는 새로운 계층도 추가됩니다. 홍보 성격의 대량 메일에는 BCL과 관계없이 Promotions 태그가 지정되며, 관리자가 "Bulk moves enabled"를 켠 경우 Promotions 폴더로 이동합니다. 이는 스팸은 아니지만 Inbox에 도착한 것도 아닙니다. 이 기능은 아직 단계적으로 배포되고 있습니다.
두 Microsoft 시스템은 서로 분리되어 있지 않습니다. Microsoft는 Microsoft 365 스팸 필터링이 "learns from known spam and phishing threats and user feedback from our consumer platform, Outlook.com"이라고 설명합니다. 따라서 hotmail.com 사용자의 신고 내용이 비즈니스 받은편지함에서 사용하는 필터에도 반영됩니다.
관리자는 발신자를 허용 목록에 추가할 수도 있습니다. 이렇게 하면 멀웨어 및 신뢰도 높은 피싱을 제외한 대부분의 보호 기능을 우회합니다. 협력사가 계속 청구서를 Junk에서 받는다면 실제 판정 결과는 해당 회사의 IT 팀이 확인할 수 있습니다.
헤더에서 판정 확인하기
Microsoft 365 사서함이 수신한 상태의 메시지를 확보할 수 있다면 스팸 방지 헤더에 판정 결과가 명시되어 있습니다. X-Forefront-Antispam-Report에는 알아둘 만한 필드가 몇 가지 있습니다.
SFV:SPM은 스팸 필터링에서 스팸으로 표시했다는 뜻이고,SFV:NSPM은 스팸이 아니라는 뜻이며,SFV:SFE는 발신자가 사용자의 Safe Senders 목록에 있어 필터링을 건너뛰었다는 뜻입니다.CAT은 적용된 정책 범주를 나타냅니다:SPM,HSPM(신뢰도가 높은 스팸),BULK,PHSH,SPOOF.SCL은 -1 또는 0부터 9까지의 숫자입니다. 이전 가이드에서는 이 값을 판정 결과로 취급합니다. Microsoft의 현재 SCL 페이지에 따르면 이 값은 "스팸 필터링에서 메시지를 스팸 또는 신뢰도가 높은 스팸으로 식별할지 결정하지 않습니다". 따라서CAT을 먼저 확인하세요.
헤더에는 SPF, DKIM, DMARC 및 메시지의 기타 요소를 바탕으로 만든 Microsoft의 종합 판정인 compauth도 포함됩니다. 이유 코드 001은 암시적 인증에 실패했다는 뜻이며, 일반적으로 발신 도메인에 인증 레코드가 게시되지 않았거나 약한 정책만 설정된 경우에 발생합니다.
SNDS와 JMRP, 이제 Postmaster 사이트에서 제공
Smart Network Data Services, 즉 SNDS는 이제 새로운 Postmaster 사이트에서 제공되며, sendersupport.olc.protection.outlook.com의 기존 사이트를 대체합니다. SNDS는 IP 주소별로 보고하므로 데이터를 확인하려면 먼저 IP 대역의 소유권을 증명해야 합니다. 데이터에는 전송량, 신고율, 필터가 트래픽 중 스팸으로 판단한 비율을 나타내는 색상이 포함됩니다. 10% 미만은 녹색, 10%에서 90% 사이는 노란색, 90% 초과는 빨간색입니다. 이제 접근 권한은 승인 또는 이전 후 10개월이 지나면 만료되며 갱신해야 합니다.
소규모 발신자의 경우 SNDS에 아무 데이터도 표시되지 않을 수 있습니다. 특정 날짜에 전송한 메시지가 100개 미만인 IP는 제외될 수 있기 때문입니다. 또한 플랫폼의 공유 IP를 통해 이메일을 보내는 경우 해당 주소를 소유하지 않으므로 등록할 수 없습니다.
JMRP, 즉 Junk Mail Reporting Program은 피드백 루프입니다. SNDS를 통해 등록하면 Microsoft가 Outlook.com 사용자가 정크 메일로 표시한 메시지 중 일부의 헤더를 보내며, 일반적으로 72시간 이내에 전송이 시작됩니다. 새 IP를 추가할 때마다 JMRP에도 추가하세요.
Microsoft는 정크 메일 신고율을 발신자 평판의 "주요 요인 중 하나"라고 설명하며, SNDS FAQ에서는 0.3% 미만의 신고율을 "목표로 삼기 좋은 기준"이라고 합니다. 새 IP가 자리를 잡는 데는 시간이 걸립니다. Microsoft에 따르면 새 IP는 "전송량과 목록 정확도에 따라 2주 이내 또는 그보다 빨리" 완전히 안정화될 수 있습니다. 비용을 내고 등록할 수 있는 목록도 없습니다. 문제 해결 페이지에서는 발신자가 등록할 수 있는 Outlook.com 허용 목록을 운영하는지 묻고 "아니요."라고 답합니다.
상대방이 변경할 수 있는 항목
일부 설정은 수신자가 관리하므로 독자에게 도움을 요청해도 무방합니다. Outlook.com에서 사용자는 Settings, Mail, Junk email로 이동해 메시지를 Not junk로 표시하거나 발신자를 Safe senders and domains에 추가할 수 있습니다. 이 목록에는 최대 10,000개의 항목을 저장할 수 있으며, Microsoft에 따르면 목록에 있는 발신자의 링크와 이미지는 일반적으로 기본 활성화됩니다. 엄격한 설정을 원하는 사용자는 Contacts와 Safe Senders에서 보낸 메일만 수신하는 "exclusive" 모드를 켤 수도 있습니다.
Junk 버튼은 반대로 작동합니다. Microsoft는 이러한 신고를 바탕으로 같은 발신자가 이후에 보내는 메일을 차단할지 판단합니다. 이와 별도로 발신자 권장 사항에서는 "clearly visible" 구독 취소 링크를 요구합니다. Microsoft의 안내에는 Gmail과 Yahoo가 요구하는 원클릭 List-Unsubscribe 헤더가 언급되어 있지 않지만, 같은 캠페인을 세 서비스 모두에 보내므로 모든 메일에 추가하는 것이 좋습니다(두 헤더).
데스크톱 앱에는 별도의 Junk Email Filter가 있습니다. 기본 설정은 "No Automatic Filtering"이며, 그 위에 Low, High, "Safe Lists Only" 옵션이 있습니다. 마지막 옵션은 사용자의 안전 목록에 없는 모든 발신자의 메일을 정크 메일로 처리합니다. 안전 목록과 차단 목록은 서버에 동기화되며 서버에서도 사용됩니다.
또한 Focused Inbox는 받은편지함을 Focused와 Other로 나누며, Microsoft의 표현에 따르면 "filters out noisy sources like automatically generated or bulk email"입니다. Other는 받은편지함의 탭이므로, 뉴스레터가 여기에 있다면 이미 스팸 필터링을 통과한 것으로 볼 수 있습니다.
실제 발송 전 테스트
Microsoft의 문제 해결 페이지에서는 "실제 커뮤니케이션을 발송하기 전에 이메일 테스트를 수행할 것을 강력히 권장합니다"라고 안내합니다. Email Spam Tester는 이 단계를 지원합니다. 실제 사용할 서버나 플랫폼에서 페이지가 생성한 주소로 실제 메시지를 보내면 보고서에서 42개 항목을 확인합니다. 여기에는 정렬을 포함한 SPF, DKIM 및 DMARC, 역방향 DNS, 21개 차단 목록에 등록된 발신 IP(차단 목록이 중요한 이유), 수신 거부 헤더와 콘텐츠가 포함됩니다. 실패한 검사에는 수정 계획과 복사할 DNS 레코드가 제공되며, 각 수정으로 얻는 점수는 채점표를 기준으로 합니다.
수신함 배치 테스트를 추가하면 같은 메시지가 Gmail, Outlook, Yahoo 및 기타 제공업체의 수신함에도 전송됩니다. 보고서에는 각 제공업체에서 메시지가 도착한 위치를 해당 사서함에서 직접 확인해 표시하며, 제공업체가 이런 방식으로 분류하는 경우 Focused 또는 Other도 포함됩니다. 가입 없이 무료로 사용할 수 있습니다. 문서에서 모든 검사와 각 검사에 배정된 점수를 설명합니다.
다음 단계로 지원 티켓을 제출하려는 경우, Microsoft의 전송 가능성 문의 양식은 @outlook.com, @hotmail.com, @live.com 및 @msn.com 주소와 관련된 사례만 접수한다는 점에 유의하세요. 또한 정책 페이지에서는 규정을 준수하지 않으면 "지원팀에서 도움을 드리지 못할 수 있습니다"라고 경고합니다.