MS 이메일 수신 차단 원인과 해결 과정

← back 2026-04-12 Troubleshooting Email Delivery to Microsoft Users On Feb 24, 2026 we started to see a rise in user complaints saying they're not receiving our emails. They all had one in thing in common: Microsoft as their email provider. Since I'd never encountered this before, my first reaction was to check my Sendgrid logs for details. According to the logs, emails to Hotmail, Live, MSN, and Outlook email addresses were being Deferred . Emails to other email addresses were flowing normally. Digging deeper, Sendgrid showed this reason for the deferral: 451 4.7.650 The mail server [redacted] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see https://aka.ms/postmaster (S775) [Name=Protocol Filter Agent][AGT=PFA][MxId=redacted] This raised even more questions. First, no emails were being delivered to Microsoft users at all . It wasn't a 'temporary rate limit'. It was more like a temporary ban. For how long? Unclear. And due to IP reputation? Sendgrid showed a 99% sending reputation. I opened Gmail Postmaster Tools and the spam rate looked normal. I was following all the best practices with SPF, SKIM, and DMARC. I also hadn't made any changes to my email setup recently. A quick Google search for this error code led me to this: https://learn.microsoft.com/en-us/answers/questions/5786144/all-sending-ips-temporarily-rate-limited-451-4-7 . Interestingly, this was posted less than 24 hours ago. Seems like I wasn't alone. This led me to believe that the problem lay with Microsoft and not me; either an outage or a misconfiguration on their end was penalizing legitimate senders. Surely, it would resolve itself... Email deliverability is crucial for the smooth running of our business. We send ~350k emails per month of which ~39k emails are transactional in nature (login, billing, password reset, etc...). Currently, all these emails are sent from two dedicated IPs irrespective of whether the email is transactional or not. Both IPs were being rate limited. Complaints were flowing in on Helpscout. I first instructed my CX reps to create a saved reply to calm users down. Lucky for us, emails sent via Helpscout don't go through our Sendgrid IPs. Hi {%customer.firstName,fallback=there%}, It appears Microsoft is throttling some of our emails which is preventing the email from reaching your inbox in a timely manner. We recommend waiting for 24 hours. If you still haven't received the email, please reply back. We apologize for the inconvenience. Even though I firmly believed this was a Microsoft problem which would eventually fix itself, I couldn't rest easy knowing this was happening. So I busied myself with research about email deliverability to Microsoft users. I've picked up many email deliverability quirks during times of crisis like this. This time, I learned that Microsoft has a reputation for being hypersensitive compared to other email providers like Gmail. I also learned about SNDS , Microsoft's version of Gmail Postmaster Tools, and immediately created an account. This allowed me to confirm my IP reputation from Microsoft's perspective. As I expected, everything was normal. Complaint rate was < 0.1% and days leading up the incident showed all green boxes, no red flags. This further convinced me it was a Microsoft issue. Nevertheless, some mysterious inner drive prevented me from just resigning to Microsoft to fix the problem or lift the ban. It bothered me that loyal users of my site were being affected, and I couldn't remedy it immediately. As a next step, I emailed Microsoft via their support portal: https://olcsupport.office.com/ . I made sure to include as much relevant information as possible, including a subset of Sendgrid logs. This also forced me to clarify my understanding of the issue. I hit submit, not very optimistic that I'd hear back anytime soon. The process of gathering all the evidence and submitting that ticket brought my attention to something I had ignored earlier. The error said has been temporarily rate limited due to IP reputation . So far, I had been focused on the IP reputation part of that message. But during my research on Microsoft deliverability, I learned that senders can be rate limited for other reasons too, most notably spiky send traffic. Part of their motivation is to contain a potential threat before it does more harm. A temporary ban, like the one I was experiencing, fit into this theory. We send out a weekly personalized newsletter. We split the sends into four batches, Monday through Thursday, to spread out the traffic. Each batch is sent as fast as our system can call Sendgrid's Mail API. We don't throttle. And I confirmed with Sendgrid's support team that they don't throttle either. Is it possible Microsoft imposed a temporary ban on my IPs after it saw a sudden spike in emails originating from them? SELECT DATE_TRUNC('minute', created_at) AS minute_group, COUNT(*) FROM notifications WHERE email ~ 'hotmail|live|msn|outlook' AND DATE(created_at) <= '2026-02-25' GROUP BY 1 HAVING COUNT(*) > 0 ORDER BY 2 DESC This gave the number of emails we attempted to send to Microsoft users each minute leading up the incident. After filtering for counts < 50, here's the result: 2026-02-23 21:48:00,53 2025-11-26 15:36:00,66 2025-10-28 21:48:00,52 2025-08-05 21:51:00,54 The first row looked suspicious because it occurred right before the incident started. Before that, we hadn't sent that many emails to Microsoft users in a single minute since November 2025. By now, I had received a boilerplate response from Microsoft saying my sending IPs were fine. I responded saying things were not fine and tried my best to sound professional even though I was panicked. My CX reps were doing a great job handling the fallout on Helpscout. Sendgrid was periodically retrying deferred emails. It would continue to do so for up to 72 hours. I still had no clue how long this ban would last. The uncertainty was weighing on me. But the results of my SQL query and deliverability research convinced me that regardless of the cause, I needed a way to control my sending rate to Microsoft users. Coding is a great cure for uncertainty. It's predictable, controlled, and gives a sense of accomplishment. So I dived right into this task. I needed something simple and performant. Since Redis was already a part of my infrastructure, I decided to implement a simple Redis-backed throttler. class RedisRateLimiter(BaseRedisModel, ABC): def is_allowed(self, limit, window_seconds) -> Tuple[bool, int, float]: """ Check if action is allowed under rate limit. Returns: - allowed: bool - remaining: int - retry_after: float """ assert Redis is not None, 'Redis not configured' now = time.time() window_start = now - window_seconds # Use pipeline for atomic operations pipe = Redis.pipeline() # Remove old entries pipe.zremrangebyscore( self.cache_key, '-inf', window_start ) # Count current entries pipe.zcard(self.cache_key) # Get oldest entry timestamp pipe.zrange( self.cache_key, 0, 0, withscores=True ) results = pipe.execute() current_count = results[1] oldest_entry = results[2] if current_count < limit: # Allowed Redis.zadd( self.cache_key, {f"{now}:{id(now)}": now} ) Redis.expire( self.cache_key, window_seconds ) return True, limit - current_count - 1, 0 # Rate limited if oldest_entry: retry_after = \ (oldest_entry[0][1] + window_seconds) - now else: retry_after = window_seconds return False, 0, retry_after def count(self, window_seconds): """ Get current count. """ assert Redis is not None, 'Redis not configured' now = time.time() window_start = now - window_seconds count = Redis.zcount( self.cache_key, window_start, now ) return count I used it like follows: class IPPoolRateLimiter(RedisRateLimiter): name = 'ip-pool-rate-limiter' def send_email(recipient_email, ip_pool, ...): """ Sends email. """ def _rate_limit(name, limit, window_seconds=60): """ Rate limit helper method. """ limiter = IPPoolRateLimiter( f'{ip_pool.name}-{name}' ) whi