- 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.
- Be sure to ramp-up your sending IP address. Microsoft explains: “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.
- 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). 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.
- 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. It also goes without saying that Microsoft is explicitly saying that SMTP-based address validation is not allowed.
- Get Certified. Return Path runs a paid Certification whitelist, and Microsoft is listed (by both Microsoft and Return Path) as a user of this whitelist. If you pass the vetting process and your sending IP address gets certified, you’ll be able to bypass some filtering at Microsoft's Outlook.com and other ISPs. Do note that this isn’t a free pass to spam; if you garner too many spam complaints (or negative SRD votes) you could find your certification suspended.
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 you be unblocked.
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.
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. SPF has since taken its place.
Microsoft's Office 365 platform operates its own unblocking request form. It has been suggested that at some point in the future these platforms may merge, and thus some of these support / request mechanisms may merge, but that does not seem to be the case as of April, 2016.
(Special thanks to Luke Martinez and Laura Atkins for helping to clarify the proper place to go to request unblocking.)