ISP Deliverability Guide: Microsoft OLC (Updated for 2023)

Successful inbox delivery to Microsoft consumer mailboxes (referred to as Outlook.com, Hotmail.com, or Microsoft "OLC") can be tricky. Any deliverability consultant will tell you that Microsoft is often the quickest to block or junk your mail, and that it is relatively common to have deliverability issues at Microsoft only, and nowhere else. You are not alone.

Not only can Microsoft often be "quicker on the trigger" when it comes to blocking, but also, resolution of deliverability issues can take longer here versus other mailbox providers. It's not always clear what triggers spam folder placement or blocking -- but like with so many other mailbox providers, the best thing you can do to minimize deliverability risk is to send truly wanted mail. No purchased lists, no email appends, no ten year old lists you found in the back of a filing cabinet. Sending engaging, wanted, recognized mail, is going to be your best chance for getting mail to the inbox.

Blocking at Microsoft usually results in a sender receiving a bounce message that looks something like this:

550 5.7.1 Unfortunately, messages from [x.x.x.x] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. [#.eop-nam02.prod.protection.outlook.com]

If you're experiencing blocking when sending to outlook.com / live.com / hotmail.com subscribers, here's where you need to go to request that your sending IP address be unblocked.

Learn more about Microsoft blocking here.

Here are my top five deliverability tips for Microsoft OLC:

1. Publish SPF records and sign mail with DKIM authentication. Sender Policy Framework (SPF) is a simple DNS record that conveys what IP addresses are allowed to transmit mail for your domain. It's easy to configure and there's absolutely no reason you shouldn’t have already implemented SPF. Domain Keys Identified Mail (DKIM) is a little bit trickier. Your (or your ESP’s) outbound mail server needs to support DKIM directly; it involves signing outbound mail with a cryptographic key. Microsoft’s Outlook.com webmail platform checks for DKIM and SPF, and you’ll want to have both in place, one to back up the other. I’ve been occasionally seeing odd DKIM failures when sending to Outlook.com. Very low numbers, but in that scenario, mail is still getting delivered fine, because SPF is in place and acting as a backup.
2. Be sure to warm-up your sending IP address. As Microsoft often says: “IPs not previously used to send email typically don't have any reputation built up in our systems. As a result, emails from new IPs are more likely to experience deliverability issues. Once the IP has built a reputation for not sending spam, Outlook.com will typically allow for a better email delivery experience.” Meaning: Don't expect to send to 30 million Hotmail subscribers on day one. Build up that volume over time on a new IP address. Assuming it's wanted mail, it'll probably take three to four weeks until you can get up to full speed. If you're sending unwanted mail, life probably isn't going to get easier. You'll want to reach out to Microsoft and request "pre-emptive accommodation" when preparing to start IP warming. Learn more here.
3. Sign up for SNDS. Microsoft’s Smart Network Data Service (SNDS) is a reputation portal that helps you to understand deliverability-related reputation issues. After you’ve signed up, and requested access to view data about your sending IP address(es) you can get some idea if you’re hitting spamtraps, and whether or not your reputation is red, yellow or green. If you’re seeing a consistently “red” (bad) sending reputation, it could be that you’re getting too many complaints (if you see numbers suggesting an elevated spam complaint rate) or it could be related to Windows “SRD” (Sender Reputation Data, originally called "the Outlook.com Spam Fighters program"). How SRD works is that Microsoft queries a small sampling of your subscribers, allowing them to provide more direct feedback regarding your email messages. Does the recipient feel the message is spam? If enough of those people say “yes” then your deliverability reputation is really likely to suffer. To avoid that, don’t spam, don’t buy lists and be very transparent to subscribers. If need be, cut back to mailing only engaged subscribers, after dumping any questionable data that may not be opt-in.
4. Don’t get "tagged for Namespace Mining." Microsoft explains: “This is the practice of verifying email addresses without sending (or attempting to send) emails to those addresses. This method is commonly used by malicious senders to generate lists of valid e-mail addresses that they can send spam, phishing emails or malware. Microsoft does not allow this behavior and takes action on IPs that engage in it.” I’ve seen this happen to senders where I’m fairly certain they’re not engaged in such a practice, and I think in that scenario, the sender has such a horribly dirty list, with so many invalid addresses, that they’ve tripped this trigger at the ISP. Solution: Don’t mail really, really old lists that you found in the back of some filing cabinet. Attempt to mail enough invalid addresses, and you’ll run into this issue. Whether or not this is the exact same thing as "dictionary attacking" is unclear to me, but it seems effectively the same. Engage in that, get blocked like this, I think.
5. If you consistently suffer from inbox placement (and requesting mitigation from Microsoft has led nowhere), then it's time to implement an engagement-boosting segmentation strategy, specific only to Microsoft domains (you can find a list of Microsoft domains here). Learn more about focusing on engagement here.

More Information

Microsoft operates a feedback loop, called the Junk Mail Reporting Program (JMRP). If you're working with an email service provider (ESP), they've likely already signed up for the JMRP and you're benefitting from it directly without having to take any action. If you're sending from your own server, and not using an ESP, then you'll likely want to enroll your sending IP addresses in JMRP. You'll need to specify an email address that Microsoft can send complaints to, and you are expected to unsubscribe people who complain. Also note that if you send lots of mail, you're going to get lots of complaints. Even if everything is on the up-and-up. Point being, don't send the complaints to some personal mailbox where the receptionist has to check it and manually process things. It'll fill up quick and possibly crash your mail server. Feedback loops (FBLs) typically need automation and a technically-minded process review.

Microsoft has an additional, voting-based subscriber feedback mechanism called "Sender Reputation Data" (SRD) where they invite a sampling of subscribers to vote whether or on the subscriber finds a particular send (or sender) to be spammy. If enough subscribers polled vote your mail to be spam, you're much more likely to find your mail blocked or relegated to the junk folder.

Keep in mind that you don't need to bother with Sender ID. Dated deliverability guidance abounds out on the Internet; you'll still find reference guides that talk about Sender ID. Ignore these. SPF has since taken its place.

Microsoft's Office 365 platform operates its own unblocking request form.

Click here to view the whole series of Spam Resource ISP Deliverability Guides.