The Discovery
I recently needed to send a test message to a Microsoft account. While I still have access to an old school account that uses Office 365, I wanted to test using a consumer domain address. So, I turned to a Microsoft account using a non-Microsoft domain for OneDrive access. I uncovered something unexpected: Microsoft provides send-only email addresses to account holders who haven’t explicitly created an Outlook or Hotmail mailbox.
What I Did
I logged into my Microsoft account. I selected Outlook from the app picker, and the web version of Outlook loaded and presented me with an address setup for use: outlook_28CABF904928312D@outlook.com.
I then sent an email using that address to my Gmail account. The message arrived successfully. When I attempted to reply to that message, Microsoft’s system rejected it:
550 5.5.0 Requested action not taken: mailbox unavailable (S2017062302).The headers show that the test message passes SPF, DKIM, and DMARC checks.
I also sent a test message to a non-existent account on my mail server. That message bounced (as it should have):
NOQUEUE: reject: RCPT from mail-dm6nam10olkn2016.outbound.protection.outlook.com[40.92.41.16]: 550 5.1.1 <redacted@redacted.com>: Recipient address rejected: User unknown in virtual mailbox table; from=<outlook_28CABF904928312D@outlook.com> to=<redacted@redacted.com> proto=ESMTP helo=<NAM10-DM6-obe.outbound.protection.outlook.com>But no bounce message was ever received.
Why This Matters
A spammer or phisher could easily create Microsoft accounts to obtain these send-only addresses. Since messages from these addresses pass SPF, DKIM, and DMARC checks, they appear completely legitimate to receiving systems while offering two significant advantages to bad actors:
- Bounce handling evasion—Since the addresses cannot receive mail, bounces never reach the sender. This allows spammers to continue hitting invalid addresses without consequence.
- Unsubscribe request blocking—CAN-SPAM and similar laws require honoring unsubscribe requests, but these addresses make compliance technically impossible. Recipients cannot reply to opt-out, and any automated unsubscribe requests sent to the originating address would never arrive.
What We Have Here Is A Failure to Communicate
The inability to receive messages at these addresses contradicts a fundamental assumption of email communication: that dialog is possible. This breaks the expected social contract of email, where senders anticipate recipients can respond through the same channel. (And, yes, I’m aware that many senders use “do not reply” addresses, but those generally tend to be formatted as “noreply@somedomain.com,” so that you know this norm is being broken rather than a more general use of random addresses at outlook.com.)
Examining the Sent folder, the account appears to exist to allow sharing files with others. Other than my two test messages, the Sent folder is full of messages about sharing OneNote folders with a classmate (and all of those are OneDrive links, so I’m guessing OneDrive shares would show up there, too). But that doesn’t explain why Microsoft provides access to a working Outlook web interface, creating the impression of a complete email account.
Technical Implications
The provisioned address format follows a consistent pattern with a unique identifier string that appears to be account-specific. The sending functionality works through Microsoft’s standard mail infrastructure, passing all typical authentication checks.
When attempting to deliver a reply, the server responds with the 550 error code, indicating that the mailbox doesn’t exist for receiving purposes. This creates a technical asymmetry in the email channel—outbound delivery functions normally, but inbound delivery fails.
Authentication Considerations
Email security professionals should recognize that these phantom addresses will pass standard authentication checks. Since these addresses pass SPF, DKIM, and DMARC checks, they won’t trigger typical authentication failures despite their unusual behavior.
Authentication measures are not anti-spam measures, except in the broadest possible sense. SPF and DKIM are intended to say that messages are coming from an authorized source and have not been altered in transit. They do not say anything at all about the “goodness” or the “badness” of the message’s contents. Could I send a phishing message attempting to obtain access to an Outlook.com account from my pseudo-account and have it pass authentication? Absolutely. An authorized Outlook.com instance would have sent the message, resulting in a “pass” for both SPF and DKIM.
Practical Countermeasures
So, what can you do? The good news is that the address I tested looks like it should follow a set pattern. So, first, implement pattern detection for these addresses in your mail filtering rules. The telltale userpart pattern of “outlook_” followed by a hexadecimal string (mine was 16 characters long) is distinctive and easily identifiable. Mail gateways can tag messages from these addresses for additional scrutiny.
Second, adjust your risk scoring for these addresses. Since these addresses pass authentication but exhibit unusual characteristics, consider giving messages from this pattern a slightly elevated risk score. This doesn’t mean automatically blocking them (since you may want to allow OneDrive/OneNote sharing) but applying more thorough content analysis.
Third, talk to Microsoft. If you identify patterns suggesting abuse of these phantom addresses, report them through established abuse channels. Microsoft might not change the underlying behavior, but they should be aware of potential exploitation.
Fourth, implement logging specifically for these address patterns. Track sending patterns, message volume, and content characteristics from these addresses separately from regular Microsoft accounts. This data can help identify potential abuse trends over time.
What Organizations Should Think About
Security teams should understand that legitimate messages can originate from these addresses. This prevents false positives while still maintaining appropriate vigilance for potentially malicious activity.
Organizations using Microsoft services should update their acceptable use policies and user education to account for these special-purpose addresses. Ensuring your team understands what these addresses can and cannot do prevents inadvertent communication problems.
Without Microsoft addressing this issue directly, recipient domains will be forced to implement specialized detection techniques as part of their standard protection measures. The challenge is distinguishing legitimate use of these addresses from intentional abuse by spammers and others.
