Microsoft (Outlook.com and Hotmail) troubleshooting support information

This article provides troubleshooting information for senders having trouble getting email delivered to Outlook.com users' inboxes. Always follow Microsoft's bulk sender policies and guidelines to help improve your chances to make it to the inbox.

Microsoft troubleshooting tools and support

When troubleshooting blocks at Microsoft, you can open a support ticket directly with Microsoft to help determine a cause. Prior to opening a support ticket, do your best to troubleshoot and fix the cause and refrain from opening multiple tickets for the same issue or IP address. If you are being blocked, be sure to include a copy of the entire error message as it will help Microsoft troubleshoot the issue and may help towards a faster resolution.

• Microsoft (Outlook.com) Postmaster
• Microsoft (Outlook.com) Support Ticket Form 
• Junk Mail Reporting Program (JMRP)
• Smart Network Data Services (SNDS)
• Microsoft's Bulk Sender Policies and Guidelines 
• Microsoft Header Analyzer (Message Analyzer tab)

Anti-spam message headers

Microsoft provides some guidance related to the email message headers that can help you troubleshoot possible causes of delivery issues. View the Microsoft message headers for any campaign sent to Everest by navigating to In-Flight>Inbox Placement, clicking the campaign subject line on a recent test, clicking the Hotmail details arrow button on the right, and clicking the Headers arrow button for any seed address.

• Anti-spam message headers
• Spam confidence level (SCL)
• Bulk complaint level (BCL)

Spam folder placement

Microsoft uses their proprietary Exchange Online Protection® and SmartScreen® spam filter to help protect their users from spam. Exchange Online Protection® has more of a focus on IP and domain reputation, authentication and spammer infrastructure, and less of a focus on content filtering. The SmartScreen® filter is influenced by a number of factors related to the sender, including the sending IP address, domain, authentication, list quality, complaint rates, content and engagement. 

Common causes of spam folder placement

• Poor sending reputation: Your sending reputation is a direct reflection of your commitment to following sending best practices. Microsoft is more likely to deliver your email to your subscribers' inboxes if they see a low rate of users marking your email as spam or phishing.
• Standard complaints
  • One of the principal factors that affects your sending reputation and deliverability is your email complaint rate. Achieving and maintaining a low complaint rate can help you reach the inbox.
    • To maintain your low complaint rates, sign up with Microsoft's Junk Mail Reporting Program (JMRP) and make sure all complainers are added to your suppression list.
    • The JMRP is a free service that provides reports to senders on users that mark email as spam. New enrollees usually start to receive feedback in as little as 72 hours.
    • Microsoft records a complaint when the subscriber clicks on the 'this is spam' button or if the subscriber moves the email directly to the junk folder. In both cases, an ARF notification message of the complaint is sent to you via the JMRP.
  • Microsoft generally expects you to be able to audit your participation in the JMRP by checking your ARF messages. Queries to Microsoft asking them for audit information may or may not be returned. If there is some doubt about which IPs are included in JMRP, it may be faster just to reapply.
  • Should you have any issues with receiving data through the JMRP, please contact Microsoft via email at: msn-snds@microsoft.com.
• Sender Reputation Data (SRD) complaints
  • Additional information on SRD.
    • What is Sender Reputation Data (SRD)?
    • How can I lower my Sender Reputation Data (SRD) rates?
  • Validity Certification clients can access SRD data, including problematic campaigns in Everest for Certified IPs. In Everest, navigate to In-Flight>Certification.
    • View SRD performance in Compliance Trends.
    • View SRD details and problematic campaigns in IP Performance by clicking the details arrow on the right next to each Certified IP.
  • SRD data is not provided to senders with an ARF message like a standard spam complaint.
• Not employing Email Authentication: Authenticating your email is used to identify you and helps prevent fraudulent use of your IPs and domains.
  • Everest clients can monitor SPF, DKIM, and DMARC by navigating to In-Flight>Inbox Placement, clicking the campaign subject line on a recent test and viewing the SPF, DKIM, and DMARC columns for Hotmail.
  • Sender Policy Framework (SPF): Ensure your sending domain has an SPF record with all of your sending IP addresses.
  • Domainkeys Identified Mail (DKIM): Ensure there are no errors when signing your email messages with DKIM.
    • Microsoft sometimes makes slight modifications to content which can break DKIM. Ensure the c= tag in the DKIM signature is set to relaxed/relaxed. It allows for a little more tolerance for minor modifications to both the header and body of the message so the DKIM verification process is less likely to fail.
  • Domain-based Message Authentication, Reporting and Conformance (DMARC): Microsoft may not accept email from senders who fail DMARC. Work towards publishing a DMARC record for your sending domain with a p=reject policy to help block unauthorized senders using your domain to send spam.
    • Microsoft will reject email with p=reject and a DMARC failure. Be sure all authentication methods are up to date, configured correctly, and passing DMARC.
    • Everest clients can monitor DMARC compliance and identify compliant, non-compliant, and unauthenticated domains by navigating to Monitoring>Infrastructure.
• Phishing
  • In addition to complaints, Microsoft (Outlook.com) users have the option of marking emails as phishing. Microsoft's JMRP also returns reports about emails marked as phishing. Ensure that subscribers marking your email as phishing are added to your suppression list.
  • To help prevent your messages being perceived as a phishing message, ensure that your email is easily recognized with clear branding in the friendly-from address and within the content. Always use valid, reputable URLs and domains in your headers and content. Do not link to known phishing websites.
  • Authenticate your email using Domainkeys Identified Mail (DKIM), Sender Policy Framework (SPF) and Domain-based Message Authentication, Reporting and Conformance (DMARC).
• Sending from new IP addresses and domains: New IP addresses and domains do not have a sending history, so email sent from new IPs and domains often encounter deliverability issues. Over time as a sending reputation is built and you send engaging content with low complaint rates, deliverability improves.
  • Ensure you warm up new IP addresses and domains over several weeks. Sending high volumes of email from a new IP address or domain will likely be perceived as spam and cause deliverability problems.
  • Ensure all new IP addresses are added to the JMRP.
• Namespace mining: Trying to connect to Microsoft's servers in an attempt to verify email addresses without sending email may result in your email getting blocked. If you are not involved with namespace mining, check your servers to ensure they were not compromised by a hacker who is using them to attack Microsoft's servers.
• Excessive new Microsoft subscribers: Ensure that new Microsoft subscribers on any given send do not exceed 5% of the total Microsoft subscribers. So, if you are sending to 100,000 Microsoft subscribers for a single campaign, make sure that new Microsoft subscribers do not exceed 5,000. New subscribers are people that have recently opted-in to receive your email and have not received previous marketing email from you. Split up your campaigns if your new Microsoft subscribers exceed 5%.
• Blocklisting: Microsoft uses the Spamhaus blocklist in it's filtering decisions.
  • If experiencing deliverability problems at Microsoft, lookup your IP address at Spamhaus to see if you are listed.
  • You can also check your SMTP error codes for further verification of a Spamhaus listing.
  • For example: 5.7.1 Client host [##.##.##.##] blocked using Spamhaus. To request removal from this list see http://www.spamhaus.org/lookup.lasso (S3130).
• Connection issues: A mis-configured DNS may cause problems connecting to Microsoft email servers or may cause Microsoft to perceive email from that server to be spam.
  • Ensure all resource records such as A records and TXT records are properly configured for the domain.
  • Ensure reverse DNS (PTR) records are properly configured for the IP address. Microsoft may not accept your email if the reverse DNS lookup fails.
  • Try manually connecting to Microsoft's MX servers over port 25 from your sending system to ensure a connection is being made.
    • Hotmail.com MX record: hotmail-com.olc.protection.outlook.com
    • Outlook.com MX record: outlook-com.olc.protection.outlook.com
    • Use MX Toolbox to lookup the MX records for other Microsoft related domains.
  • Most connection issues are temporary. However, if you continually experience problems connecting to Microsoft's servers, it is likely an issue with your sending software or configuration.

Error codes

In order to help senders troubleshoot sending problems, Microsoft returns SMTP error codes to senders for undelivered email. Gain access to your email log reports and look for these codes for every campaign encountering deliverability problems. Common error codes returned involve throttling and blocks due to poor sending reputation.

A less common error code involves problems related to the SMTP conversation:

• 4.7.0 (other or undefined security status);smtp;421 4.7.0 Too many protocol errors (6) on this connection, closing transmission channel. [HXXXX01XX044.eop-XXX01.prod.protection.outlook.com]”  

Seeing this error code suggests there are multiple errors with the sending and receiving of SMTP information. It usually means that there are errors being communicated back to the sending server during the SMTP conversation which should cause the transmission of the email to stop, but the sending server continues to send SMTP commands.

If you see this error, investigate that entire SMTP conversation starting with the HELO/EHLO command.

Deferrals/Throttling

Most deferrals are due to sending too much email from a new IP address or due to an IP or domain reputation issue.

• If you start to see 4xx deferral messages from Microsoft, Microsoft recommends that you stop all sending from that IP address for at least one hour and resume sending at a slower rate. If the deferral messages continue after you resume sending, stop sending from that IP for at least 24 hours.
  • Refer to Microsoft's SMTP error codes for additional information related to the deferral messages.
  • Investigate and fix the cause of the deferral messages. You especially want to be sure they are not caused by unauthorized access to your IP address.
  • If you continue to send at a high rate when seeing the deferral messages, it can negatively impact your sending reputation, which may lead to a decrease in inbox placement.

Delivery delays

If your email campaign is taking longer than expected to reach its destination, Microsoft's Header Analyzer can help you identify a possible cause. It may indicate a traffic jam in your sending system or if Microsoft's servers may be experiencing some processing issues.

Everest clients can identify potential delivery delays by viewing Minutes to Receive (MTR). Navigate to In-Flight>Inbox Placement, click a subject line for a recent test, and view the MTR column on the right for Hotmail.

Microsoft Smart Network Data Services (SNDS)

Microsoft Smart Network Data Services (SNDS) is a program Microsoft offers to senders which can help you troubleshoot delivery problems. SNDS provides data based on actual email sent to Outlook.com subscribers. The metrics include:

• Spam complaints
• SmartScreen filter results
• Spam trap hits