Verifying Outlook.com addresses

• Microsoft throttles by connecting IP far more aggressively than Google. A burst of probes earns 421-4.7.500 and the connection closes.
• Addresses that do not exist usually return 550-5.5.0 with a Requested action not taken message, but the same address can return 550 once and a temporary error the next time.
• The service sometimes answers 250 at RCPT TO and rejects the message later at DATA, which a verifier never reaches because the connection closes before that step.
• Retry timing matters more here than with any other large provider. A single-shot probe against Microsoft is close to a coin flip on a throttled connection.

• Microsoft's Smart Network Data Services is the equivalent of Google Postmaster Tools, and it needs IP ownership rather than a domain to enroll.
• Complaint rates matter more than bounce rates on Outlook.com. Their junk filter reacts to the Report as junk button almost immediately.
• The four domain families behave the same at the protocol level, and the older brands tend to skew older. A hotmail.com address on a list bought in 2024 is often a decade-old account, though the domain alone doesn't prove it.

Say you merge two lists and your cleanup script strips periods from every local part before comparing, because someone read that Gmail ignores them. That's correct for the Gmail rows, and on outlook.com it's a bug. Microsoft treats j.smith@outlook.com and jsmith@outlook.com as two separate accounts that can belong to two different people. Your script just deleted a real subscriber and kept a stranger's preferences on the surviving row.

Plus addressing is a separate question, and here the answer matches Gmail: Outlook.com supports it, so jsmith+news@outlook.com reaches the same inbox as jsmith@outlook.com. The safe rule for Microsoft consumer domains is to fold the plus tag and leave the periods alone. Users can also attach extra aliases to one account. Nothing in an SMTP reply links an alias to its owner, so two valid rows may still be one person.

Microsoft followed Google and Yahoo with its own rules for high-volume mail. From May 5, 2025, domains sending more than 5,000 messages a day to Microsoft's consumer addresses need SPF, DKIM and a DMARC record of at least p=none that aligns with one of them. Mail that fails gets rejected with a 550 5.7.515 error saying the sending domain doesn't meet the required authentication level.

That code matters when you read a bounce log. A 5.7.515 is about your domain's setup and tells you nothing about the mailbox. Don't let an automation rule treat it as a hard bounce and suppress the address. Fix the DNS records first, then resend to the same people. Verification can't help with this one, because the address was fine the whole time. If you send fewer than 5,000 a day you're under the threshold, but Microsoft recommends the same records for smaller senders too, so there's little reason to wait.