Microsoft Email Woes

Day 1

Dear Diary,

A long while back, probably some time in the fall or early winter of 2020, email from my server started to be rejected by any service run by Microsoft. Mail to users, rejected. Mail to users, rejected. And so on.

The first few rejections were from one Microsoft server notifying me that it had rejected mail from another Microsoft server. My interpretation of this was that mail I was sending was being forwarded internally but rather than trust the edge server to do all the checks the internal server rechecked the SPF record for my domain.

My SPF and DMARC DNS policy records say that any mail from my domain must be from my server. And my DMARC record says that everything I send is digitally signed by my server using DKIM.

If an internal server enforces my rule (mail claiming to be from me must come from my server) but the email is from edge server run by the destination’s domain then it will be rejected. And I can believe that a number of rejections could result in the original sender’s domain being added to a block list.

Clearly a system design or configuration error on the part of the recipient system.

After a short time the rejects changed to say that my server IP address was on a block list.

Since this started I have taken several tries to resolve the situation but each time given up in frustration.

There are only a few people we know that are using Outlook or Hotmail and we have alternative ways of communicating with them. So I let this issue languish for a very long time. Literally years.

Recently a relative has insisted on getting an Outlook account and I thought I would try to address the problem once again.

This effort has reminded me why I gave up in frustration on my earlier attempts.

Duplicating The Problem

Duplicating the problem is easy for me. Just send and email to one of the few people I know using Hotmail or Outlook. An immediate reject is received with, among other things the following:

Diagnostic-Code: smtp; 550 5.7.1 Unfortunately, messages from [nn.nn.nn.nn]
    weren't sent. Please contact your Internet service provider since part of
    their network is on our block list (S3140). You can also refer your
    provider to

Microsoft’s Troubleshooting Instructions

So off we go to the given troubleshooting page. Note, by the way that all the links I receive from Microsoft are “http://” and not “https://” though the all seem to be redirected to HTTPS versions.

  • Nowhere on that page can I find mention of S3140.
  • Nowhere on that page is a contact information, email or web form for more help.
  • There is mention of IP addresses being blocked by their “Junk Email Reporting Program” but no link to it or how to enroll in it as a email server administrator.
  • There is a mention of possibly being blocked by spamhaus.

Junk Mail Reporting Program

Poking around, I eventually found an address for signing up for Microsoft’s junk mail reporting program. But the address,, gets you to a login page. You can’t get there without a Microsoft account. So much for a program directed toward managers of other email servers.

Checking Blocklists

I don’t know how many email real-time block lists there are. My server uses spamhaus but there are lots more. So I used a site that claims to check a bunch of lists and came up clean on all of them. I also checked directly with spamhaus as it was mentioned on Microsoft’s page and am clean (i.e. not listed) there too.

Well, the message did say “our block list” so it is probably an internal Microsoft block list not a public one which means I need to contact a human at Microsoft.


Via Email

Time to try to contact Microsoft. Not seeing an appropriate “contact us” link or email address, the first try was to contact The email standards say that every domain that supports email needs to have a postmaster account. And mail to it should not be blocked.

But the same block that exists for sending to one of their users also exists for their postmaster account and I got an immediate reject. This is a violation of the Internet email RFCs.

I tried again using a dormant gmail account and got the following immediate reply:

This email address is not monitored. Please visit for information about sending email to, including troubleshooting information. If you are an user please visit to learn more about our services, find answers to your questions, and share your feedback.

Sincerely, Team
One Microsoft Way. Redmond, WA 98052, USA.

Microsoft respects your privacy. To learn more, please read our online Privacy Statement at

Via the Web

They said to “visit for information about sending email to, including troubleshooting information.”

Guess what? It takes you to either a “access denied” page or the same unhelpful web page the original reject sent you to. Why the different page depending on when you attempt to follow that link? I don’t know.

How Have Others Dealt With This?

In the Microsoft Communities a user complained that they were not receiving email from some people. The error message was identical to what I am getting. The support reply was to request that the sender be added to a white list by going to Guess what? That needs a Microsoft account to log in.

Desperate Measures

Apparently the only way to contact Microsoft about an email issue is to have a Microsoft account.

A New Email Address

If you cannot beat them, join them: I have created a Hotmail account and sent, or at least attempted to send, test messages. As expected email from Hotmail to my server works and email from my server to Hotmail fails.

I submitted my issue to the Microsoft support, using my newly created Hotmail account for logging in to their issue reporting page.

Day 2

Within a day got back a message that, translated to English was basically “pound sand”. Just a reject and a bunch of boilerplate, nothing that indicates specifically why my server is being blocked that is actionable on my part:

We have completed reviewing the IP(s) you submitted. The following table contains the results of our investigation.

Not qualified for mitigation
Our investigation has determined that the above IP(s) do not qualify for mitigation.

Please ensure your emails comply with the policies, practices and guidelines found here:

To have Deliverability Support investigate further, please reply to this email with a detailed description of the problem you are having, including specific error messages, and an agent will contact you.

Regardless of the deliverability status, recommends that all senders join two free programs that provide visibility into the traffic on your sending IP(s), the sending IP reputation with and the user complaint rates.

Junk Email Reporting program (JMRP) When an user marks an email as “junk”, senders enrolled in this program get a copy of the mail forwarded to the email address of their choice. It allows senders to see which mails are being marked as junk and to identify mail traffic you did not intend to send. To join, please visit

Smart Network Data Services program (SNDS). This program allows you to monitor the ‘health’ and reputation of your registered IPs by providing data about traffic such as mail volume and complaint rates seen originating from your IPs. To register, please visit

There is no silver bullet to maintaining or improving good IP reputation, but these programs help you proactively manage your email eco-system to help better ensure deliverability to users.

Thank you, Deliverability Support

Microsoft Mail Policies

The first link in the email is, again HTTP rather than HTTPS but does lead to a HTTPS page with some reading material that you don’t need to log into to see.

Items 1 through 4 (“General Microsoft Policies”, “Governmental Regulations”, “Technical Guidelines”, and “Authentication”) are all very standard things. Which, to the best of my ability I have configured my mail server to adhere to.

I am mildly amused that high on the list are recommendations that are over two decades old. Email and anti-spam has come a long way since then. But whatever.

Item 5 (“Reputation Management”) on that page, and also mentioned in the response email are their “Junk Email Reporting Program” (JMRP) and their “Smart Network Data Services” (SNDS). I decided to start with SNDS.

Smart Network Data Services (SNDS)

This is setup by having a Microsoft user requesting to be able to view data about email received from an IP address. To authorize this you need to be able to respond to Microsoft from a postmaster address (or equivalent) associated with that IP address. Which was no problem for me as I get mail addressed to postmaster on my domains.

But it gets me nowhere useful. “View Data” shows no activity. But there is a note: “Be aware that mail traffic and spam data may not be present for IPs which sent less than 100 messages on the given day.”

There is a “View IP Status” page too. It simply reports “All of the specified IPs have normal status.” No help there either.

Junk Email Reporting Program (JMRP)

JMRP seems to be a part of SNDS and, near as I can tell, simply sends reports to a postmaster responsible for a domain when a Microsoft user marks an email from that domain as being spam. This feels a bit like Microsoft poorly implementing the equivalent of the reporting mechanism built into the DMARC standard.

I guess that is harmless enough other than the annoyance of having to create a Microsoft account to set it up.

But, again, it does not solve my current problem: Email from my server is not getting to the recipient so the recipient can’t mark it as spam.

Additional Resources – Deliverability Support

Okay, I have read through their boilerplate. I have a properly configured email server. Their reputation management hasn’t helped. But this section sounds like it might be where they should have sent me to in the first place:

If you are adhering to the guidelines, practices and policies presented on this page and are still experiencing deliverability issues, please contact deliverability support. If you are not in compliance with the above policies and guidelines, it may not be possible for our support team to assist you. Deliverability Support

Except that it gets me back to the same support request page that I used previously and got the “Not qualified for mitigation” response.

Another Email

Well, the email response that said my server’s IP address “was not qualified for mitigation” also said “to have Deliverability Support investigate further, please reply to this email with a detailed description of the problem you are having, including specific error messages, and an agent will contact you.”

Off we go again. . . Lets see what this email reply to their rejection brings:

Regarding the email server at mydomain (IPv4 address nn.nn.nn.nn, IPv6 address 2600::nnnn).

Mail to Microsoft managed domains (,, etc.) is being rejected. A typical notification of the rejected email from the sending MTA is:

Diagnostic-Code: smtp; 550 5.7.1 Unfortunately, messages from [nn.nn.nn.nn] weren’t sent. Please contact your Internet service provider since part of their network is on our block list (S3140). You can also refer your provider to []

I have read through and believe that this server is compliant with your policies and applicable email RFCs. Specifically, the server in question:

Does not allow relay.

All mail is from either individual users (very few in number) or for email lists for members of a small volunteer organization.

Regarding mail lists, the organization allows individuals to select what email they wish to receive and one option is to receive no email at all.

The server is configured with reverse DNS for both IPv4 and IPv6.

There is a DNS SPF record that requires all mail from the domain to be from this one server.

All mail is signed using the DKIM protocol

There is a DNS DMARC record giving policy (quarantine for any email failing SPF or DKIM).

The rejection quoted above says the server is on a block list. The server is not on any public RBL that I am aware of. The policy page linked in your response mentions spamhaus (which my server also happens to use) and my server is not listed there. I suspect this is an internal Microsoft maintained block list.

I setup up and checked SNDS for the IPv4 address and it showed no activity for days that I know email was rejected. But volume is low, below the 100 email threshold mentioned for reporting.

I setup JMRP but I suspect nothing will be reported as email is not getting as far as the users to mark as spam.

How can I determine what specific issue has caused this server to be blocked?

Without knowing why Microsoft and, near as I can tell, only Microsoft is blocking email from this server I have nothing actionable to correct.

A Real Live Human Responds!

Several hours later I actually got a response that seems like it is from a real, live human:


My name is Xxxxxxx and I work with the Sender Support Team.

We will be looking into this issue along with the Escalations Team regarding IP: (nn.nn.nn.nn). We understand the urgency of this issue and will provide an update as soon as this is available. Rest assured that this ticket is being tracked and we will get back to you as soon as we have more information to offer.

Thank you for your patience.

Xxxxxxx Deliverability Support

Days 3, 4, 5, 6, 7 and 8

No response from Microsoft and test email still bounces. I guess I should be happy in the knowledge that they “understand the urgency of this issue”.

Day 9

No immediate bounce on test mail. But email client not connecting to Outlook properly. First thought was Outlook could be down but there was no mention on the service tracking websites. It finally occurred to me that I could access that new Outlook account through a web browser. The email got through!

Perhaps my server has been removed from their block list, but I have not been notified of that.

But a new minor problem: My email client is not able to access this new Outlook account.

Officially Mitigated!

After dropping and re-adding the Outlook account from my email client I was able to connect and found this waiting for me:


My name is Yyyyy and I work with the Deliverability Support Team.

We have implemented mitigation for your IP(s): nn.nn.nn.nn and this process may take 24 – 48 hours to replicate completely throughout our system.


Yaqub Deliverability Support.

1 comment

Comments are closed.