Microsoft 사용자에게 이메일이 전달되지 않을 때의 문제 해결

2026년 2월 24일부터 Hotmail, Live, MSN, Outlook 수신자에게만 메일이 Deferred 되기 시작했고, Sendgrid 로그에는 451 4.7.650 오류와 함께 IP reputation 기반의 일시적 rate limit 메시지가 남았다.

처음에는 Microsoft 쪽 문제로 보였고, Gmail Postmaster Tools와 SPF/DKIM/DMARC, Sendgrid reputation, Microsoft의 SNDS까지 확인했지만 이상 징후는 없었다. Microsoft 지원 포털에 로그와 증거를 넣어 문의한 뒤에도 초기 답변은 “IP는 정상”이라는 식이었다.

원인을 다시 살피던 중, 단순한 reputation 문제가 아니라 짧은 시간에 몰린 트래픽(spiky traffic) 이 원인일 수 있다고 가정했다. 실제로 주간 뉴스레터 발송 직전 1분당 53건의 Microsoft 수신자 발송이 있었고, 이전 몇 달의 패턴과 비교하면 이 시점이 가장 의심스러웠다.

대응으로는 Redis 기반의 rate limiter를 직접 구현했다.

• RedisRateLimiter로 슬라이딩 윈도우 방식의 허용/대기 판단
• IPPoolRateLimiter를 만들어 IP 풀별 제한을 적용
• Microsoft 계열 주소는 IP당 분당 10건으로 throttling
• 제한에 걸리면 retry_after만큼 대기하도록 처리

이 조치와 병행해 Microsoft에 재차 이의 제기를 보냈고, 이후 사람 응답으로 “your IP throttling limitation has been set to a more appropriate level” 라는 회신을 받았다. 그 뒤 몇 시간 내에 Sendgrid의 Microsoft 수신자 발송이 정상화되었다.

결과적으로 약 72시간 동안 일부 메일만 지연되었을 뿐 유실은 없었고, 이후에도 Microsoft 수신자 발송은 IP당 분당 10건을 넘지 않도록 유지하고 있다.

핵심 결론은 다음과 같다.

• Microsoft는 일부 발송 IP를 임시적으로 강하게 throttling 할 수 있다.
• reputation 수치가 정상처럼 보여도, 트래픽의 급격한 증가 자체가 문제를 유발할 수 있다.
• 대량 발송 시스템에서는 수신사별 rate limiting이 사실상 필요하다.
• Sendgrid 같은 ESP가 Microsoft 대상 발송을 더 보수적으로 조절해 주면 이런 장애를 줄일 수 있다.