Microsoft의 발송 지연(deferral)은 Outlook.com이나 Microsoft 365 서버가 지금 당장은 메시지를 받지 않겠다며 보내는 일시적인 SMTP 거부, 즉 4로 시작하는 응답이에요. 발신 서버는 메시지를 보관했다가 다시 시도해야 해요. 가장 잘 알려진 예가 451 4.7.500 Server busy. Please try again later 응답이에요. 그런데 이 코드는 “발송 패턴이 의심스럽다”는 뜻일 수도 있고, “Microsoft 쪽에 문제가 생겼다”는 뜻일 수도 있어요.

2026년 9월 4일에는 후자였는데, 경험 많은 운영자 중 적어도 한 명은 전자를 의심하며 오전 내내 원인을 쫓았어요. 둘을 구분하는 방법을 정리했어요.

핵심 요약

• 먼저 호스트를 읽으세요. *.olc.protection.outlook.com 호스트는 Outlook.com 개인 메일이고, *.mail.protection.outlook.com 호스트는 Microsoft 365 테넌트예요. 참고할 문서도, 문의 경로도 달라요.
• 4xx는 대기열에 두고 재시도하라는 뜻이에요. RFC 5321에 따르면 재시도 간격은 최소 30분, 재시도 기간은 최소 4~5일이에요. 5xx는 멈추라는 뜻이고, Microsoft 정책상 재시도가 금지돼요.
• Gmail과 Yahoo는 괜찮은데 모든 IP가 같은 1분 사이에 똑같은 Microsoft 코드를 받는다면 Microsoft 쪽을 의심하고, 아무것도 바꾸기 전에 mailop부터 확인하세요.
• 2025년 5월 5일부터 Outlook.com은 하루 5,000통 넘게 보내는 도메인에 SPF, DKIM, DMARC를 의무화했어요. 550 5.7.515 응답은 언제나 내가 고쳐야 하는 문제예요.
• 지금 바로 발신 IP를 SNDS와 JMRP에 등록하세요. SNDS 접근 권한은 재인증하지 않으면 10개월 뒤에 만료돼요.
• 재시도를 더 몰아붙이거나, 새 IP로 갈아타거나, 지연된 연락처를 발송 제외하지 마세요.

먼저 상대가 어느 Microsoft인지 확인하기

Microsoft는 수신 시스템을 두 가지 운영해요.

Outlook.com은 outlook.com, hotmail.com, live.com, msn.com 같은 개인 메일이고, MX 호스트는 hotmail-com.olc.protection.outlook.com 같은 형태예요. Outlook.com Postmaster 사이트, 평판을 확인하는 SNDS, 자체 발신자 지원 문의 폼이 있어요.

Microsoft 365(Exchange Online)는 업무용 메일함을 호스팅해요. acme.com 앞으로 가는 메일은 acme-com.mail.protection.outlook.com 호스트로 가요. 오류는 Microsoft Learn에 문서화되어 있고, 차단 해제 요청은 sender.office.com에서 하며, 내 메일을 테넌트에서 어떻게 처리할지는 수신 측 관리자가 정해요.

도메인 이름만으로는 어느 쪽에 보내고 있는지 알 수 없어요. 응답을 보면 알 수 있어요. 9월 4일 mailop에 올라온 아래 로그에서 relay= 호스트는 Microsoft 365 테넌트예요.

relay=xxxx-com.mail.protection.outlook.com[52.101.10.16]:25, dsn=4.7.500,
status=deferred (host xxx-com.mail.protection.outlook.com[52.101.10.16] said:
451 4.7.500 Server busy. Please try again later from [199.89.3.6]. (S77714)
[BN2PEPF000055E1.namprd21.prod.outlook.com 2026-09-04T10:28:53.346Z ...]
(in reply to end of DATA command))

응답 해독하기

기본 코드(451), 확장 코드(4.7.500), 그리고 (S77714) 같은 괄호 안의 하위 코드를 읽으세요. Microsoft는 S 하위 코드를 공개하지 않지만, 많은 발신자가 같은 하위 코드를 동시에 보고한다면 그 자체가 신호예요.

출처: Microsoft의 Exchange Online NDR 레퍼런스, ASxxx 문서, Postmaster 코드 표, 550 5.7.515 문서, S775와 S3115에 관한 Al Iverson의 글, S3140/S3150 차단에 관한 Twilio SendGrid의 글.

4와 5의 차이가 곧 대응 지침

M3AAWG의 Sender Best Common Practices는 일시적 실패가 나면 “발신자는 연결을 닫고 나중에 새 연결을 열어야 한다”고 하고, 일시적 실패를 절대 영구적 실패로 취급해서는 안 된다고 말해요. 5xx에 대한 Microsoft의 발신자 정책은 이래요. “발신자는 해당 메시지를 해당 수신자에게 다시 전송하려고 시도해서는 안 된다.”

451은 반송이 아니에요. 사용하는 플랫폼이나 스크립트가 451을 반송으로 처리한다면 그것부터 고치세요.

Microsoft 장애와 내 평판 문제 구분하기

Microsoft의 4.7.500 안내는 원인을 내 발송에서 찾으라고 해요. 대개는 맞지만, 항상 그런 건 아니에요.

2026년 9월 4일에 벌어진 일

Qboxmail은 문제가 “9:47 CEST에 모든 IP에서 한꺼번에 시작됐다”고 mailop에 알렸고, 하위 코드는 S77714, S77717, S77719였어요. Poppulo의 상태 페이지는 11:19 BST에 시작된 Microsoft의 장애 ID EX1467029를 인용했어요.

emailexpert의 9월 10일 정리 글에 따르면, 한 운영자는 One.com, Qboxmail, Mailjet, Poppulo가 모든 발신 IP와 지역에서 같은 코드를 보고하기 전까지 광케이블 절단을 원인으로 의심했어요. Microsoft는 스팸 방지 모델을, 이어서 복구 중에도 계속 작동한 스로틀링 규칙을 원인으로 꼽았어요. emailexpert는 공개된 사후 장애 보고서를 찾지 못했어요. 이와 별개로 MO1465074라는 인증 장애가 8월 31일부터 9월 3일까지 약 67시간 이어졌어요. 이 열흘은 9월 리포트에서 다뤄요.

조치하기 전 다섯 가지 점검

1. 내 쪽의 영향 범위. 플랫폼 문제는 몇 분 안에 모든 IP, 도메인, 메일 흐름에 영향을 줘요. 평판 문제는 보통 하나에서 시작돼요.
2. 다른 메일 서비스 제공업체. Gmail, Yahoo, Apple은 정상적으로 메일을 받고 다른 발신자들도 같은 Microsoft 코드를 보고한다면, 원인은 아마 Microsoft에 있어요.
3. 최근 72시간. 발송량 급증, 새 IP, 가져온 리스트, DNS 수정, 휴면 연락처를 깨우는 발송이 있었다면 원인이 무엇이든 바로잡아야 해요.
4. 주변에 물어보기. mailop 아카이브와 상태 페이지를 확인하세요. Microsoft 365 관리자는 상태 > 서비스 상태(Health > Service health)를 열 수 있고, 여기 있는 문제 기록(Issue history)에서 내 테넌트에 게시된 최근 7일 또는 30일간의 장애를 볼 수 있어요. Poppulo도 여기서 EX1467029를 찾았어요.
5. SNDS. 발송 지연이 쌓이는데도 SNDS가 녹색이고 차단도 없다면, 원인은 내 쪽이 아닐 가능성이 커요.

Microsoft 문서와 2026년 9월 장애 보고를 바탕으로 정리한 Microsoft 응답별 대응 경로.

SNDS와 JMRP: 필요해지기 전에 미리 설정하기

Smart Network Data Services(SNDS)는 Outlook.com의 IP별 평판을 보여 주는 Microsoft의 무료 포털이에요. SNDS FAQ에 따르면 승인된 IP마다 다음 정보를 볼 수 있어요.

• 필터 결과. 스팸 판정이 10% 미만이면 녹색, 10~90%면 노란색, 90%를 넘으면 빨간색이에요.
• 스팸 신고율. 스팸 신고 수를 수신자 수로 나눈 값이에요. 30%가 넘는 IP가 0.3% 미만을 유지하는데, FAQ는 이를 “목표로 삼기 좋은 기준”이라고 해요.
• RCPT 명령 수 대비 메시지 수신자 수. 차이가 크다면 리스트가 오래됐다는 뜻이에요.
• IP 상태: Blocked, Bot, Junked.

SNDS는 “해당일에 100통 미만을 보낸 IP는 데이터가 없을 수 있다”고 해요. 접근 권한을 얻으려면 IP, IP 대역, ASN을 요청하세요. 그러면 SNDS가 역방향 DNS(postmaster@, abuse@)나 RDAP로 찾은 주소로 링크를 이메일로 보내요. 수동 요청은 받지 않아요.

SNDS는 2026년 6월에 새 버전으로 다시 출시됐어요. Al Iverson은 JMRP의 반송 경로(return-path)로 더 이상 캠페인과 수신자를 확실히 식별할 수 없다고 6월 19일에 짚었어요. 그러니 이 정보는 다른 곳에 담아 두세요. SNDS 홈페이지(9월 22일 업데이트)에 따르면 접근 권한은 승인이나 마이그레이션 후 10개월이 지나면 만료되고, 그 전에 알림이 세 번 와요. 캘린더에 적어 두세요.

SNDS 안에서 등록하는 Junk Mail Reporting Program(JMRP)은 Outlook.com 사용자가 정크로 표시한 메시지를 하나하나 돌려줘요. 등록한 뒤 “빠르면 72시간 이내”에 시작되는 경우가 많아요. 신고한 사람은 모든 리스트에서 제거하고, 새 IP를 추가할 때마다 등록하세요. 직접 등록할 수 없는 공유 IP를 쓴다면 이메일 제공업체가 무엇을 모니터링하는지 물어보세요.

발신자 지원과 등재 해제

Outlook.com. Postmaster 문제 해결 페이지의 지원 문의 폼은 Microsoft 계정이 있어야 쓸 수 있고, 개인용 도메인 네 개만 다루며, Microsoft는 이 폼이 전달을 “보장하지 않는다”고 밝혀요. 업체 측 조언이긴 하지만, Twilio SendGrid는 도메인, IP, 메일 흐름 설명, 반송 응답 텍스트, SNDS 스크린샷을 함께 보내고, 처음 오는 자동 회신에 답해 에스컬레이션을 요청하고, 발송량 할당량과 Volume-Based Limit 검토를 요청하라고 권해요.

Microsoft 365. 5.7.606-649 응답이라면 sender.office.com의 등재 해제 포털을 이용하세요. 한 번에 주소 하나와 IP 하나씩 처리하고, 이메일로 확인해요. Microsoft는 제외 처리에 “최대 24시간 또는 그 이상 걸릴 수 있다”고 해요. 5.7.511 응답이라면 NDR을 delist@microsoft.com 주소로 보내고, 48시간 안에 답장이 오기를 기다리세요.

ASxxx 스로틀링에는 등재 해제 절차가 없어요. Learn 문서에 따르면, 수신 측 회사가 Microsoft 365에 앞서 서드파티 서비스로 수신 메일을 필터링한다면 그 회사 관리자가 커넥터를 설정해 스로틀링을 없앨 수 있어요. 그렇지 않다면 발송 이력이 쌓이면서 풀려요.

재시도, 스로틀링, 워밍업

일정에 맞춰 재시도하기. RFC 5321 4.5.4.1절은 “재시도 간격은 최소 30분이어야 하고(SHOULD)”, 포기 시점은 “일반적으로 최소 45일은 되어야 한다”고 해요. RFC가 제시하는 일정은 처음 1시간 동안 두 번, 그 뒤로는 23시간마다 한 번씩 시도하는 방식이에요. 급한 발송이라고 이 일정을 줄이지 마세요.

목적지별로 속도 조절하기. M3AAWG에 따르면 수신 측은 조정이 “같은 IP 주소에서 자신에게 보내는 모든 이메일에 일괄적으로” 적용되기를 기대해요. Microsoft가 발송을 지연시키면, 해당 MX 계열(Outlook.com 또는 Microsoft 365)로 가는 모든 메일의 속도를 늦추세요.

연결 수 지켜보기. Outlook.com 정책은 발신자가 사전 협의 없이 “동시 연결을 500개 넘게 열어서는 안 된다”고 정해요. 이건 상한일 뿐이고, 4.7.652 (S3115) 응답을 받았다면 내게 허용된 한도를 넘었다는 뜻이에요.

새 IP와 도메인 워밍업하기. Microsoft는 새 IP가 발송량, 리스트 정확도, 스팸 신고에 따라 “2주 안팎, 또는 그보다 빨리 워밍업을 완전히 마칠 수 있다”고 해요. 기존 SPF 레코드에 포함된 새 IP는 도메인 평판을 어느 정도 물려받아요. 최근에 반응한 연락처부터 보내세요.

하지 말아야 할 일

• 재시도 몰아붙이기. 몇 분마다 대기열을 강제로 비우면, Microsoft가 속도를 늦추길 바라는 IP에 연결이 몰리고 결국 4.7.652 응답을 받게 돼요.
• 피하려고 IP 바꾸기. 새 IP는 평판이 없어서 문제가 생길 가능성이 더 크고, 새 IP 여러 개에 메일을 분산하는 건 스노슈(snowshoe) 스패머가 쓰는 수법이에요.
• 5xx 재시도하기. Microsoft는 이를 금지하고, “여러 번의 전달 불가 응답”을 받은 뒤에는 그 수신자에게 발송을 멈춰야 해요.
• 지연된 연락처 발송 제외하기. 주소는 여전히 유효해요.
• 지연된 수신자에게 다시 보내기. 그 메시지는 아직 대기열에 있어서 중복 발송이 돼요.
• 급하게 DNS 수정하기. 5.7.515 응답을 받은 게 아니라면, 장애 중에 SPF나 DKIM을 바꾸면 문제가 하나 더 생겨요.

DMARC 정렬과 p=none에서 정책 적용으로 넘어가는 과정은 전달성 가이드를 참고하세요. 비밀번호 재설정 이메일과 영수증이 막힘없이 나가게 하려면, 이를 별도 도메인으로 분리하는 방법을 다루는 트랜잭션 이메일 가이드를 참고하세요.

Brew에서 보이는 모습

Brew가 발송 인프라를 운영하고 일시적 실패를 재시도하므로, 대기열이나 연결 한도를 직접 조정할 일이 없어요. 대신 이런 것들을 볼 수 있어요.

• 전달 지연 이벤트. 발송이 지연되면 ‘전달 지연’ 이벤트(delivery_delayed)가 기록되고, 수신자 상태는 접수에서 지연으로, 그다음 전달 또는 반송으로 바뀌어요. 이벤트에서 “전달 지연”을 검색한 다음 @hotmail.com이나 @outlook.com을 입력하면 Outlook.com으로 범위를 좁힐 수 있어요(도메인 필터는 OR 조건으로 묶이고, Microsoft 365 수신자는 각자 자기 회사 도메인을 써요). 이 이벤트는 메시지가 대기 중이라는 사실만 알려 줄 뿐, 이유는 알려 주지 않아요.
• 반송 상세 정보. ‘반송됨’ 이벤트의 ‘메타데이터’에 반송 유형과 제공업체 메시지가 담겨 있어요.
• API로 보는 수치. 분석 개요 엔드포인트는 전달, 반송과 함께 deliveryDelayed와 pending 값을 돌려줘요. MCP에서는 get_email_analytics 도구가 같은 일을 해요.
• 4xx를 감안한 발송 제외. 영구 반송과 스팸 신고는 바로 발송 제외돼요. 일시 반송은 30일 안에 세 번 쌓여야 발송 제외돼요.
• 발송량 늘리기. 점진적 발송은 대량 발송을 시간 또는 일 단위의 비율별 배치로 나누고, Outlook.com이 발송을 지연시키기 시작하면 일시 중지할 수 있어요.
• 도메인 상태. 도메인마다 ‘전달성’ 카드가 받은편지함 도달, 평판, 인증, 콘텐츠, 발송 설정을 기준으로 0~100점 점수를 매기고, MCP의 get_domain_health 도구로도 확인할 수 있어요. 받은편지함 도달 테스트(크레딧 10개)는 Gmail, Outlook, Yahoo, Apple 등의 시드 메일함으로 테스트 메일을 보내요.

전달 웹훅과 SNDS·JMRP 데이터는 아직 Brew에 없으니(제공업체별 수치는 이벤트 API에 groupBy=recipientDomain 파라미터를 넣어 가져올 수 있어요), 평판은 Microsoft 포털에서 확인하세요. Microsoft 장애가 의심될 때 저희라면 발송은 그대로 두고, ‘전달 지연’이 ‘전달됨’으로 바뀌는 걸 지켜볼 거예요.

자주 묻는 질문

Outlook이나 Microsoft 365의 451 4.7.500 Server busy는 무슨 뜻인가요?

Microsoft 365(Exchange Online)가 보내는 일시적 거부로, 의심스러운 활동이 감지됐을 때의 “Access denied, please try again later”로 분류돼요. 대개는 발송 패턴이 바뀐 탓이지만, 2026년 9월 4일에는 Microsoft 장애(EX1467029)였어요. 발신 서버가 재시도하게 두고, 다른 발신자들도 같은 응답을 받는지 확인하세요.

Microsoft는 내 이메일을 얼마나 오래 지연시키나요?

Microsoft에 따르면 발송 패턴에 따른 스로틀링은 이력이 쌓이면서 “며칠에 걸쳐” 풀리고, 등재 해제에는 최대 24시간 또는 그 이상 걸릴 수 있어요. RFC 5321의 권장대로 최소 4~5일 동안 계속 재시도하면, 지연된 메일 대부분은 결국 전달돼요.

550 5.7.515는 무엇이고 어떻게 해결하나요?

Outlook.com은 하루 5,000통 넘게 보내면서 인증 규칙을 충족하지 못한 도메인의 메일을 거부해요. 이 규칙은 2025년 5월 5일부터 적용됐어요. SPF와 DKIM을 통과해야 하고, 도메인에 DMARC를 게시해야 하며(p=none이면 충분해요), SPF나 DKIM이 From 도메인과 정렬되어야 해요.

Microsoft가 내 IP를 차단하면 새 IP 주소를 받아야 하나요?

아니요. Microsoft는 새 IP는 평판이 없어서 문제가 생길 가능성이 더 크다고 해요. 원인을 고치고, 등재 해제를 요청한 다음, 지금 쓰는 IP에서 다시 발송량을 늘리세요.

Microsoft의 발송 지연도 반송으로 집계되나요?

아니요. M3AAWG는 발신자가 4xx를 영구적 실패로 취급해서는 안 된다고 해요. 재시도 기간이 끝나거나 서버가 5xx를 돌려줄 때만 반송이 돼요. Brew에서 발송 지연은 ‘전달 지연’ 이벤트로 표시되고, 연락처는 일시 반송이 반복된 뒤에만 발송 제외돼요.