Microsoft's 5-Year Routing Mystery Sent example.com Traffic to Japanese Cable Company
Microsoft's Outlook autodiscover service has been quietly routing traffic for example.com—a domain that should never exist in production—to a Japanese cable manufacturer for five years. And their response? A classic Microsoft band-aid that creates more problems than it solves.
Here's what happened: When you tried to add [email protected] to Outlook, Microsoft's autodiscover API cheerfully suggested IMAP and SMTP servers under sei.co.jp subdomains. That domain belongs to Sumitomo Electric Industries, a major Japanese electronics company that has absolutely nothing to do with email services.
<> Dan Tentler of Phobos Group nailed Microsoft's response: they "simply removed the problematic endpoint" instead of fixing the routing issue, leading to "not found" errors in JSON responses./>
The Real Story
This isn't just a quirky configuration error. It's a fundamental violation of RFC 2606, published in 1999, which explicitly reserves example.com for testing and documentation. The domain should only resolve to IP addresses controlled by the Internet Assigned Names Authority (IANA)—specifically ranges like 192.0.2.0/24.
For five years, anyone testing Outlook integration with example.com potentially leaked their test credentials to Sumitomo's servers. Not because Sumitomo did anything wrong—they're innocent bystanders in this mess—but because Microsoft's autodiscover service decided their domain was somehow the right place to route email traffic.
The timing is brutal. This comes right after Microsoft's 2024 security disaster where a forgotten admin test account let Russia-linked hackers access executive emails for two months. Now we discover they can't even handle a basic test domain correctly.
Band-Aid Solutions Are Worse Than No Solutions
Microsoft's January 27, 2026 "fix" is peak enterprise software development:
- Remove the broken endpoint
- Pretend the problem is solved
- Ignore the root cause entirely
Now developers querying the autodiscover API get "not found" errors instead of useful responses. Congratulations, Microsoft—you've transformed a security issue into a functionality issue.
The real questions remain unanswered:
1. How did sei.co.jp get into Microsoft's configuration in the first place?
2. What other domains might be similarly misconfigured?
3. Why did this persist for five years without detection?
Developer Reality Check
If you're building email integration:
- Stop using example.com for testing immediately
- Switch to example.test (RFC 6761) or local domains
- Audit any existing autodiscover implementations
- Never trust Microsoft's server suggestions without manual verification
tinyapps.org first spotted this anomaly and verified it through command-line tests. It took independent security researchers to catch what Microsoft's internal monitoring missed for half a decade.
Trust, But Verify Everything
This incident perfectly encapsulates why you can't blindly trust cloud provider APIs, even for something as basic as domain resolution. Microsoft operates critical infrastructure for millions of organizations, yet they can't properly handle a reserved test domain.
The regulatory implications are murky but real. If any of those leaked test credentials contained sensitive information, GDPR and other data protection laws could come into play. Sumitomo Electric had no idea they were receiving this traffic and have remained silent throughout the controversy.
The pattern is clear: Microsoft commits to better security hygiene after each incident, then promptly demonstrates they haven't learned the lesson. This time, instead of transparency and root cause analysis, we get endpoint removal and corporate silence.
For developers, the message is simple: verify everything, trust nothing, and always have a backup plan when Microsoft inevitably breaks something else.
