Microsoft Mishandling Example.com

Summary

TL;DR: Since at least February 2020, Microsoft's Autodiscover service has incorrectly routed the IANA-reserved example.com to Sumitomo Electric Industries' mail servers at sei.co.jp, potentially sending test credentials there. Problem While setting up email@example.com as a dummy account in Outlook (on both Windows and macOS), Outlook consistently auto-configured it to use imapgms.jnet.sei.co.jp (IMAP) and smtpgms.jnet.sei.co.jp (SMTP) despite example.com being an IANA-reserved domain that should not resolve to real services. The same behavior appeared on different machines, profiles, networks, and DNS resolvers, including a newly provisioned Windows 365 Cloud PC: Your web browser doesn't support embedded video. Confirmation DNS verification Confirm that example.com has no DNS records pointing to sei.co.jp: % dig MX example.com +short 0 . % dig CNAME autodiscover.example.com +short (no response) % dig SRV _autodiscover._tcp.example.com +short (no response) The domain has a null MX record (indicating it doesn't accept email) and no Autodiscover DNS entries, confirming the misconfiguration exists entirely within Microsoft's database. Microsoft autodiscover API response Microsoft's Autodiscover service misconfiguration can be confirmed via curl -v -u "email@example.com:password" "https://prod.autodetect.outlook.cloud.microsoft/autodetect/detect?app=outlookdesktopBasic": View full output * Host prod.autodetect.outlook.cloud.microsoft:443 was resolved. * IPv6: (none) * IPv4: 172.169.69.94 * Trying 172.169.69.94:443... * Connected to prod.autodetect.outlook.cloud.microsoft (172.169.69.94) port 443 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, F...