From time to time Microsoft decides to block or even silently drop emails that are sent by my selfhosted email server. It’s always a pain and takes a lot of effort to deal with it. This time I decided to document the whole process and how I dealt with it.
Thursday, September 24th, 2020
A customer of mine informed me that he got a strange email and asked me what is was. It was saying:
This is the mail system at host ***.******.***. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <*********@hotmail.de>: host eur.olc.protection.outlook.com[104.47.18.97] said: 550 5.7.1 Unfortunately, messages from [***.***.***.***] 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. [AM6EUR05FT010.eop-eur05.prod.protection.outlook.com] (in reply to MAIL FROM command)
*Sigh* Here we go again… I already now this. It happened to me many times. And I am sure it happened to many admins around the globe that are hosting an own email environment.
First aid to restore reliable delivery
But this time I am prepared to avoid a long outage time of email services for my customers and just turn on my email relay solution I described in this article: https://www.nerd-quickies.net/2020/07/10/solve-microsoft-email-block-list-errors-instantly/ I prepared this workaround especially for Microsoft related email delivery problems as this is the only company giving me trouble in this regard.
Open a ticket with Microsoft
After doing this I can take my time to fill out the Microsoft support form. It isn’t easy to find, so here is the link: https://support.microsoft.com/en-us/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75
I filled out the form, submitted it and prepared to wait. There just isn’t more you can do. The answer can take hours or days. You just don’t know. Therefore it is important to have a workaround in place (like setting up a relay as mentioned before).
Saturday, September 26th, 2020
Microsoft answered to my ticket:
Dear ***** *******
Please note that your ticket number is in the subject line of this mail.
***.***.***.***/32
Note: Errors are unlikely, however, if an error is indicated, please resubmit the specific IP or IP range.
Thank you,
Outlook.com Deliverability Support
Please do not reply to this message as it is from an unattended mailbox. Any replies to this email will not be responded to or forwarded. This service is used for outgoing emails only and cannot respond to inquiries.
Well. I already know this email from my previous cases but it puts a smile to my face whenever I get it again. “Errors are unlikely”? Really? I spent a lot of time filling out a form describing the “unlinkely error” I got and all the details.
Fortunately I got another email from Microsoft the same day that sounds a lot better:
Dear ***** ******
We have completed reviewing the IP(s) you submitted. The following table contains the results of our investigation.
Conditionally mitigated
***.***.***.***/32
Our investigation has determined that the above IP(s) qualify for conditional mitigation. These IP(s) have been unblocked, but may be subject to low daily email limits until they have established a good reputation.
Please note that mitigating this issue does not guarantee that your email will be delivered to a user’s inbox.
Ongoing complaints from users will result in removal of the mitigation.
Mitigation may take 24 – 48 hours to replicate completely throughout our system.
If you feel your issue is not yet resolved, please reply to this email and one of our support team members will contact you for further investigation.
Regardless of the deliverability status, Outlook.com recommends that all senders join two free programs that provide visibility into the Outlook.com traffic on your sending IP(s), the sending IP reputation with Outlook.com and the Outlook.com user complaint rates.
Junk Email Reporting program (JMRP) When an Outlook.com 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 http://support.msn.com/eform.aspx?productKey=edfsjmrpp&page=support_home_options_form_byemail&ct=eformts.
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 http://postmaster.live.com/snds/.
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 Outlook.com users.
Thank you,
Outlook.com Deliverability Support
That sound promising. As I have my working relay workaround in place I decide to wait the “24 – 48 hours” to give Microsoft the time to “replicate mitigation completely throughout their system”.
Wednsday, September 30th, 2020
Today is the day! Time to check if email delivery is working again.
I turned off my relay workaround and sent an email from one of my domains to one of my outlook email addresses to test email delivery.
Good news: I don’t get error messages anymore, no bounce errors, nothing. Very good.
Bad news: my email isn’t delivered. It isn’t in my Outlook inbox, not in my spam folder. It just disappeared.
Maybe it is a problem on my side? I checked my email server log. It is saying:
Sep 30 14:46:55 name_of_my_server postfix/smtp[14421]: E60F6276921: to=<********@outlook.de>, relay=eur.olc.protection.outlook.com[104.47.10.33]:25, delay=2.8, delays=0.01/0.04/0.78/2, dsn=2.6.0, status=sent (250 2.6.0 <691a0697-6a0c-99e8-89d1-5f59bd4d7968@******.***> [InternalId=60133837151113, Hostname=DB5EUR03HT193.eop-EUR03.prod.protection.outlook.com] 9424 bytes in 0.087, 105.555 KB/sec Queued mail for delivery -> 250 2.1.5)
“Queued mail for delivery” sounds good. Unfortunately the email was never delivered.
So, Microsoft’s “mitigation” made a bad problem (block of legitimate emails with an error message) even worse (drop legitimate emails without notice).
In fact, in my eyes this is the worst case: Accepting an email for delivery, then just delete it without telling anyone. I still wonder why a big company like Microsoft behaves this way and gets their own customers in such serious trouble.
But it is not the first time this happens to me. So I know what I have to do.
First: turn back on my Microsoft email relay workaround to restore reliable email service for my customers.
Second: Beg Microsoft to throw me a bone.
So I answered to their last email:
Dear Support,
unfortunately things got even worse.
Now my emails aren’t even rejected with an error message anymore but dropped silently without notice to the sender or postmaster!
I just tried to send an email from sample@mydomain.tld to *******@outlook.com. It is accepted by one of your servers for delivery:
Sep 30 14:46:55 name_of_my_server postfix/smtp[14421]: E60F6276921: to=<*******@outlook.de>, relay=eur.olc.protection.outlook.com[104.47.10.33]:25, delay=2.8, delays=0.01/0.04/0.78/2, dsn=2.6.0, status=sent (250 2.6.0 <691a0697-6a0c-99e8-89d1-5f59bd4d7968@*******.***> [InternalId=60133837151113, Hostname=DB5EUR03HT193.eop-EUR03.prod.protection.outlook.com] 9424 bytes in 0.087, 105.555 KB/sec Queued mail for delivery -> 250 2.1.5)
But it never gets delivered nor does anyone get a notice about any problem. The email just disappears!
This is not the first time this strange behaviour occurs. Can you please tell me concretely what the problem is so I can solve it?
Regards,
****** *******
Commendably, I received an answer in less than two hours:
Hello,
My name is ******** ****** and I work with the Outlook.com Sender Support Team.
I do not see anything offhand with the IP: (***.***.***.***/32) that would be preventing your mail from reaching our customers.
You may be able to find additional information on common delivery questions at the Outlook.com Postmaster Site found at https://ift.tt/2AI61Kp I would like to highlight some key areas that I believe are appropriate to your company.
· Outlook.com has created the Smart Network Data Services (SNDS) program. This is a service that helps legitimate email senders work with their customers and partners to reduce spam originating from their IP. To register, please go to https://ift.tt/3l1PfOX This program allows a sender to monitor the ‘health’ of their IPs.
· Monitor user complaints. Outlook.com also has a sender complaint feedback loop program called the Junk Email Reporting Program (JMRP). Enrollment in this free program will benefit you as a sender as it will keep your email lists updated and populated with interested Outlook.com customers. This program will help you to remove those Outlook.com customers who do not want to receive emails from your company. If you are interested in joining this program, please visit https://ift.tt/3BP3pc3.
While using the SNDS tool and enrollment in the JMRP will not allow emails from your mail servers to bypass our filters, these are in place to help legitimate companies deliver their emails to Outlook.com customers.
Apply for the Sender Score Certified Mail program.
If you are doing all the above and you continue to have deliverability issues, you may wish to consider joining the Sender Score Certified Mail Program, a third party program administered by Return Path, Inc. Many legitimate mailers and marketers have qualified and joined this program to improve mail deliverability and decrease email from being filtered to the Junk E-mail Folder. Sender Score (https://ift.tt/3iUOqER) is the only service to which we subscribeThe troubleshooting steps in this email are recommendations only. Microsoft makes no guarantees that following these steps will guarantee deliverability to MSN, Outlook.com, or Live.com customers.
For more detailed information about best sending practices to Outlook.com users, please review the following white paper: https://ift.tt/2UNyLPR
Sincerely,
******* ********
Outlook.com Deliverability Support
*Sigh* I know this canned email already. Whenever I have delivery problems with Microsoft they send it to me at some stage. First time when I received it I spent many hours in studying all the links, documents, best practices. I registered for their SNDS and JMRP programs.
Therefore I can say that I follow all their rules as good as I can. There must be a very specific problem that they identified on their side. It can’t be a general problem because only Microsoft complains about it.
I decided that this was enough frustration for one day and to answer it the next day.
Thursday, October 1st, 2020
What a nice day! Time to spend some more time with Microsoft related email delivery problems…
I answered the following to their last email:
Hello ********,
I already know all of this. I don’t have delivery problems with you for the first time. Last time was in July. In the meantime I can recite all your related documents as I spent so many hours reading through all of them. But none of them gives me a hint what the specific problem could be.
- As you could easily see (as I am registered with the email address we are communicating through right now) I already am member of your SNDS program. But it’s not helping me at all. It’s just saying “All of the specified IPs have normal status.” even though it is obviously not true.
- I also registered with with JMRP a long time ago but never got a single complaint
- I am not willing to spend time and money to a third party to just get a handful of legit emails to Microsoft clients’ inboxes.
I just tried to send an email from sample@mydomain.tld to *******@outlook.com again. It is accepted by one of your servers and then just disappears.
It is a problem on your side that I can’t investigate by myself. This is the last trace of it from my server logs:
Oct 1 12:18:10 name_of_my_server postfix/smtp[29834]: E1CDF270C17: to=<*********@outlook.de>, relay=eur.olc.protection.outlook.com[104.47.18.161]:25, delay=2, delays=0.21/0.01/0.12/1.7, dsn=2.6.0, status=sent (25
0 2.6.0 <ecc59e4a-c4ee-b792-dfc1-081c8b322bfe@*******.***> [InternalId=20877836063158, Hostname=AM7EUR06HT239.eop-eur06.prod.protection.outlook.com] 9716 bytes in 0.192, 49.240 KB/sec Queued mail for delivery
-> 250 2.1.5)
Please, have a look at it on your side. I can’t even guess what happened after you “queued it for delivery”.
Regards,
*******
About 2 hours later I got this answer from Microsoft:
Hello,
My name is ******** and I work with the Outlook.com Sender Support Team.
As stated previously, I do not see anything offhand that would be preventing your mail from reaching our customers for the following IP :***.***.***.***
For more detailed information about best sending practices to Outlook.com users, please review the following white paper: http://download.microsoft.com/download/e/3/3/e3397e7c-17a6-497d-9693-78f80be272fb/enhance_deliver.pdf
Sincerely,
********
Outlook.com Deliverability Support
Thank you, Microsoft. That was really helpful. Instead of just looking at the specific case I get the same general information over and over again.
So i answered this:
Hello ********,
I don’t see anything offhand that prevents delivery, too.
But what I see, is that one of your email servers accepts my emails for delivery but doesn’t deliver. I just tried again to send an email from sample@mydomain.tld to my personal Outlook email address *********@outlook.de. Your server accepts it for delivery:
Oct 1 16:42:45 name_of_my_server postfix/smtp[19190]: 5B6B5270AC7: to=<**********@outlook.de>, relay=eur.olc.protection.outlook.com[104.47.10.33]:25, delay=0.63, delays=0.02/0.01/0.27/0.33, dsn=2.6.0, status=sent (250 2.6.0 <0ccc460b-baab-7d55-856b-75e8016ab6de@*******.***> [InternalId=101722005476327, Hostname=DB5EUR03HT015.eop-EUR03.prod.protection.outlook.com] 9745 bytes in 0.129, 73.293 KB/sec Queued mail for delivery -> 250 2.1.5)
But it does not appear in my inbox or spam folder. Please have a look at your logs. You can easily see it yourself!
I am not exactly sure if your read my last email because your are just telling me the exact same things that your colleague already told me and that I already know because I already had that exact same problem in July. E.g. I know your “enhance_deliver.pdf”. But I already do all the things that are mentioned there and applicable in my case.
I can’t do anything on my side. Please throw me a bone!
Regards,
*******
Monday, October 19th, 2020
Didn’t hear anything from Microsoft for 18 days. Maybe the problem was solved and emails from my customers are getting to Microsoft customers’ inboxes now?
I turned off my relay workaround and again sent an email from one of my domains to an Outlook email address. Microsoft servers still accept my emails for delivery:
Oct 19 13:50:40 name_of_my_server postfix/smtp[2976]: 3535826181E: to=********@outlook.de, relay=eur.olc.protection.outlook.com[104.47.18.161]:25, delay=0.62, delays=0.1/0.07/0.13/0.33, dsn=2.6.0, status=sent (250 2.6.0 e68c995a-aa92-8ff0-b364-a2f79ff54d2a@******.*** [InternalId=22728967015364, Hostname=AM7EUR06HT223.eop-eur06.prod.protection.outlook.com] 9784 bytes in 0.178, 53.526 KB/sec Queued mail for delivery -> 250 2.1.5)
But you already guessed it: All emails are still dropped without any notice to sender, recipient or email server operator.
As my relay workaround shouldn’t be a permanent solution I decided to kindly ask Microsoft what the current status is. So I answered to their last email:
Hello ******,
I am not sure if you received my last email of 2020-10-01 15:08 UTC. It was sent from anemailaddress@mydomain.tld so maybe it was silently dropped, too. Therefore I am writing from my Outlook account now.
The problem still persists! Emails that are sent from my server with ip address ***.***.***.*** are still dropped without any notice!
I just tried to send an email from sample@mydomain.tld to *******@outlook.com again and your server accepted the email for delivery:
Oct 19 13:50:40 name_of_my_server postfix/smtp[2976]: 3535826181E: to=<**********@outlook.de>, relay=eur.olc.protection.outlook.com[104.47.18.161]:25, delay=0.62, delays=0.1/0.07/0.13/0.33, dsn=2.6.0, status=sent (
250 2.6.0 <e68c995a-aa92-8ff0-b364-a2f79ff54d2a@******.***> [InternalId=22728967015364, Hostname=AM7EUR06HT223.eop-eur06.prod.protection.outlook.com] 9784 bytes in 0.178, 53.526 KB/sec Queued mail for deliver
y -> 250 2.1.5)
But it was neither delivered nor did I receive an error message.
Please help me! The problem exists on your servers and I don’t have the slightest chance to do anything about it. Again, I am willing to do what I can at my side but you have to tell me what the problem is. Otherwise all your customers will not be able to receive any legit emails from the domains that my server handles. Currently I advise all my customers to not use Microsoft email services and to ask recipients for alternative mail addresses as this is the only solution for the problem.
Additionally please note that I will document this issue in one of my blogs to help other people dealing with similar problems.
Regards,
*******
The answer took only a few minutes:
Thank you for contacting Microsoft Technical Support. The service request has been archived due to inactivity. If you still require assistance, please contact us via support.microsoft.com or 1-800-Microsoft.
REALLY? They closed my ticket without a warning? After everything we’ve been trough? “Due to inactivity”? Inactivity? Yes, they were inactive and didn’t solve the problem… No option to reopen the case? No help but the link on just the general support page?
To be honest: it took me some time to calm down.
As bad is it is. This problem is still open and has to be solved. So: Everything back to start!
First: Visit https://support.microsoft.com/en-us/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75 again, fill out the form an provide all details they need.
I’m quite used to it so it took me only 15 minutes or so.
Solved the captcha and hit “Submit”. This is what happened:
Noooooo. What is this? Microsoft? What are you doing to me?
Because I thought this could be one of those general error messages that could be caused by anything I spent about 2 hours using different browsers, cookie and blocking configurations. I even tried to adjust the content of the form fields. In the end I gave up. Maybe it really is a temporary problem on Microsoft’s side.
Tuesday, October 20th, 2020
New day, new luck.
Spent a little more time to get my “new” support case opened. But I get the exact same nonspecific error message.
What next? Wait a bit longer till the support page is fixed? Open a thread in the support forum?
All I want is to get a few legit, normal emails into the inboxes of Microsoft customers. Do I really have to spend half my life to achieve this?
Update
Seems, the support page is working again. I just submitted a new support request.
In the “Copy and paste any error messages:” sections I wrote the following:
There is no error message. Emails are just dropped without notice and don’t reach inboxes of your customers!
Sending from sample@mydomain.tld to *********@outlook.de results in this line in my log. Your server says “Queued mail for delivery” but it does not reach the inbox or even spam folder on your side. It just disappears somewhere in your infrastructure.
Oct 19 13:50:40 name_of_my_server postfix/smtp[2976]: 3535826181E: to=<********@outlook.de>, relay=eur.olc.protection.outlook.com[104.47.18.161]:25, delay=0.62, delays=0.1/0.07/0.13/0.33, dsn=2.6.0, status=sent (
250 2.6.0 <e68c995a-aa92-8ff0-b364-a2f79ff54d2a@*******.***> [InternalId=22728967015364, Hostname=AM7EUR06HT223.eop-eur06.prod.protection.outlook.com] 9784 bytes in 0.178, 53.526 KB/sec Queued mail for delivery -> 250 2.1.5)
The problem exists for over 3 weeks now. Last ticket SRX1509453967ID was closed by you without solving the problem.
Thursday, October 22nd, 2020
Got an email from Micrsoft support today:
Dear ****** *******
Please note that your ticket number is in the subject line of this mail.
***.***.***.***
Note: Errors are unlikely, however, if an error is indicated, please resubmit the specific IP or IP range.
Thank you,
Outlook.com Deliverability Support
Please do not reply to this message as it is from an unattended mailbox. Any replies to this email will not be responded to or forwarded. This service is used for outgoing emails only and cannot respond to inquiries.
Sounds familiar, doesn’t it? The fact that you reported a real error seems to be irrelevant if Microsoft thinks it is unlikely.
But as I am not supposed to answer I just waited a little longer and received this email 29 minutes later:
Dear ***** ******
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 Outlook.com policies, practices and guidelines found here: https://ift.tt/1Q15fu5.
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, Outlook.com recommends that all senders join two free programs that provide visibility into the Outlook.com traffic on your sending IP(s), the sending IP reputation with Outlook.com and the Outlook.com user complaint rates.Junk Email Reporting program (JMRP) When an Outlook.com 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 http://support.msn.com/eform.aspx?productKey=edfsjmrpp&page=support_home_options_form_byemail&ct=eformts.
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 http://postmaster.live.com/snds/.
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 Outlook.com users.
Thank you,
Outlook.com Deliverability Support
This time I am “not qualified for mitigation”. Unfortunately I don’t know why. Instead, just all the general information that I already know inside out and that I am already following as good as I can.
Even if I begin to loose hope, I answered the following:
Hello Outlook.com Deliverability Support,
in the online form that I filled out to open this ticket I already mentioned that this basically is a continuation of ticket ID SRX1509453967ID. I already talked to your colleagues ******** ****** and *********. Unfortunately the ticket was closed before the issue was solved. It would be best if you would just reopen the old ticket as it contains all the information you need and it would save us both time and money.
In a nutshell:
- I know all your guides and policies and follow them as good as I can
- I am already member of your JMRP program – never got a single complaint
- I am already member of your SNDS program – I can see nothing helpful there. “All of the specified IPs have normal status.”
- Microsoft is the only ESP I have problems with. So I am very, very interested in what the specific problem is
My last try to send an email from from sample@mydomain.tld to *******@outlook.com was just a few moments ago. As always your server accepted the email for delivery…
Oct 22 15:16:20 name_of_my_server postfix/smtp[16454]: DB1FE2619AE: to=<*********@outlook.de>, relay=eur.olc.protection.outlook.com[104.47.18.161]:25, delay=1, delays=0.04/0.05/0.26/0.67, dsn=2.6.0, status=sent (2
50 2.6.0 <c389660e-c1b8-7026-dd78-edd91a13650c@******.***> [InternalId=23171348599093, Hostname=AM7EUR06HT044.eop-eur06.prod.protection.outlook.com] 9792 bytes in 0.315, 30.353 KB/sec Queued mail for delivery
-> 250 2.1.5)
… then just throws it away without telling anyone. It doesn’t appear in my inbox or in my spam folder. The sender doesn’t get a message that his email wasn’t delivered. IMHO this should never happen in a professional environment.
All emails sent by my server with IP ***.***.***.*** are not only undeliverable but deleted without a message for over 3 weeks now! And all I can tell my customers is to ask their recipients to not use Microsoft hosted email services if they want to receive their emails reliably. This isn’t only a problem for my customers but also a serious problem for your customers as they have no chance to realize when an important is just deleted by Microsoft.
Please let us solve this problem together.
Regards,
******* *********
Answer comes very quick after about 1 hour:
Hello,
My name is ******** and I work with the Outlook.com Sender Support Team.
I do not see anything offhand with the IP: (***.***.***.***) that would be preventing your mail from reaching our customers.
You may be able to find additional information on common delivery questions at the Outlook.com Postmaster Site found at https://ift.tt/2AI61Kp I would like to highlight some key areas that I believe are appropriate to your company.
· Outlook.com has created the Smart Network Data Services (SNDS) program. This is a service that helps legitimate email senders work with their customers and partners to reduce spam originating from their IP. To register, please go to https://ift.tt/3l1PfOX This program allows a sender to monitor the ‘health’ of their IPs.
· Monitor user complaints. Outlook.com also has a sender complaint feedback loop program called the Junk Email Reporting Program (JMRP). Enrollment in this free program will benefit you as a sender as it will keep your email lists updated and populated with interested Outlook.com customers. This program will help you to remove those Outlook.com customers who do not want to receive emails from your company. If you are interested in joining this program, please visit https://ift.tt/3BP3pc3.
While using the SNDS tool and enrollment in the JMRP will not allow emails from your mail servers to bypass our filters, these are in place to help legitimate companies deliver their emails to Outlook.com customers.
Apply for the Sender Score Certified Mail program.
If you are doing all the above and you continue to have deliverability issues, you may wish to consider joining the Sender Score Certified Mail Program, a third party program administered by Return Path, Inc. Many legitimate mailers and marketers have qualified and joined this program to improve mail deliverability and decrease email from being filtered to the Junk E-mail Folder. Sender Score (https://ift.tt/3iUOqER) is the only service to which we subscribeThe troubleshooting steps in this email are recommendations only. Microsoft makes no guarantees that following these steps will guarantee deliverability to MSN, Outlook.com, or Live.com customers.
For more detailed information about best sending practices to Outlook.com users, please review the following white paper: https://ift.tt/2UNyLPR
Sincerely,
*******
Outlook.com Deliverability Support
Of course I was very disappointed because it was the exact same canned email I already know. Obviously nobody looked at the ticket I mentioned in my email. Apperently they didn’t read my email at all because they refer to all the “solutions” I already mentioned.
Unfortunately, I was busy with important things too. Fighting against windmills can’t be on my priority list anymore. Therefore I had to postpone my answer.
Wednesday, October 28th, 2020
Okay, time to deal with my personal never ending story again. The last thing I want is Microsoft closing the ticket “due to inactivity” again.
I just turned off my relay workaround and tried to send an email from one of my domains to my Outlook email address – just to be sure the problem persists. Of course it does.
So I turned the relay on again and wrote another email to Microsoft. Because there just is no new information on my side I sent kind of canned email too:
Hello *******,
I don’t see anything offhand that prevents delivery, too.
But what I see, is that one of your email servers accepts my emails for delivery but doesn’t deliver. I just tried again to send an email from sample@mydomain.tld to *******@outlook.com. Your server accepts it for delivery:
Oct 28 16:02:02 name_of_my_server postfix/smtp[10943]: 862CB27690C: to=<*******.********@outlook.de>, relay=eur.olc.protection.outlook.com[104.47.17.97]:25, delay=2, delays=0.02
/0.05/0.23/1.7, dsn=2.6.0, status=sent (250 2.6.0 <430dbb32-98b0-9291-4837-fc8a18de9225@********.***> [InternalId=40312563045273, Hostname=DB8EUR05HT218.eop-eur05.prod
.protection.outlook.com] 9784 bytes in 0.264, 36.132 KB/sec Queued mail for delivery -> 250 2.1.5)
But it does not appear in my inbox or spam folder. Please have a look at your logs. You can easily see it yourself!
I am not exactly sure if your read my last email because your are just telling me the exact same things that your colleague already told me and that I already know because I already had that exact same problem in July. E.g. I know your “enhance_deliver.pdf”. But I already do all the things that are mentioned there and applicable in my case.
I can’t do anything on my side. Please throw me a bone!
Regards,
*********
After 2 hours I got a pretty promising answer:
Hello,
My name is ******* and I work with the Outlook.com Deliverability Support Team.
We will be looking into this issue along with the Escalations Team. 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.
Sincerely,
********
Outlook.com Deliverability Support
Thursday, October 29th, 2020
Got an email from Microsoft today:
Hello,
We have completed our investigation of your sending IP (***.***.***.***/32) and determined that there are no active blocks against it. However, we found that some messages were being filtered based on the recommendations of the SmartScreen®. We have confirmed that your IP is eligible for temporary mitigation based on our mail policies. Please note: The mitigation process may take 24 – 48 hours to replicate completely throughout our system.
Email filtering is based on many factors, but primarily it’s due to mail content and recipient interaction with that mail. Because of the proprietary nature of SmartScreen® and because SmartScreen® Filter technology is always adapting and learning more about what is and isn’t unwanted mail, it is not possible for us to offer specific advice about improving your mail content. However, in general SmartScreen® Filter evaluates specific words or characteristics from each e-mail message and weights them, based on their likelihood to indicate that a message is unwanted or legitimate mail.
We have some specific recommendations for you to consider that can help you to improve deliverability over time and help you avoid the deliverability issues you’ve been experiencing:
Brand your mail
Ensure mails are cleanly formatted and clearly identifiable as originating from your service.
Follow content and formatting best practices
There are numerous Internet resources which offer advice and best practices, we recommend you refer to these resources for assistance creating well formatted and more deliverable email.
Highlight Opt In
Clearly mark your emails so that Outlook.com customers are able to identify that they requested or subscribed to emails from your service.
Ensure your email lists are up to date
Remove those who do not want to receive the emails and consider making the unsubscribe process more visible to ensure you are only delivering mail to interested recipients.
Join the Junk Mail Reporting Program (JMRP)
We believe that your recipients are the best indicator that the email you are sending is wanted. The JMRP program allows you to see which of your emails Outlook.com users have marked as junk or unwanted mail. Reviewing the results in JMRP will provide to the most direct information on what characteristics of your email, customers, and ultimately SmartScreen®, consider to be unwanted. This helpful feedback mechanism allows you to ensure that mails being sent from your IP are not resulting in negative feedback that could impact your sending reputation. Being vigilant about users who mark your e-mail as unwanted or the types of messages that are being marked as unwanted can help you keep mailing lists updated with only interested users and modify future campaigns. In addition, monitoring user complaints can help you identify unintended mail traffic or detect a potentially compromised account sending unwanted mail to your customers. Enroll at https://postmaster.live.com/snds/JMRP.aspx?wa=wsignin1.0.
Join the Smart Network Data Services program (SNDS)
The SNDS program provides data about traffic seen originating from your registered IP, such as mail volume and complaint rates. The data is built from the log files of the inbound mail machines and other servers at Outlook.com and Microsoft and represents factual information about the traffic from your mail servers to Outlook.com users. For more information about this free program refer to https://ift.tt/3y9F8LN. To register, please go to https://postmaster.msn.com/snds/. (Tip: As part of the enrollment process, you are asked to sign the JMRP program agreement and then send a response to Support indicating that it has been signed. It’s not uncommon for that step in the enrollment process to be missed.)
As a reminder, the mitigation for your issue is temporary. Failure to take action could cause further degradation of your IP’s reputation and lead to future deliverability issues. We encourage you to take an active role in managing your email practices and infrastructure using the recommended tips above so that you can improve deliverability over time and avoid similar issues. We also encourage you to download and apply the industry best practices found in our Outlook.com Enhanced Deliverability white paper.
Sincerely,
Outlook.com Deliverability Support
Okay. Seems like SmartScreen was blocking my emails for some reason. But my IP is is eligible for another temporary mitigation. Sounds promising! Because I don’t have the time to test it right away and it could take up to 48 hours to “replicate completely throughout Microsoft’s systems” I decide to do the test on Monday. Luckily I still have my working workaround in place. So there is no need to rush.
Monday, November 2nd, 2020
The problem was solved! Emails are being delivered again 🙂
Conclusion
Although I am very glad about the happy ending of a long story, this is not very satisfiying because I never figured out what the problem was. My emails were deleted by a proprietary “SmartScreen” without notice. Couldn’t learn a lesson this way. This was the 3rd time this exact same problem occured on the same server. And it will likely happen again because I have no idea what to improve.
Like many adminstrators I do my best to implement all recommendations as far as possible. I have SPF, DKIM, DMARC records and spam filters in place. I am member of JMRP and SNDS program (never got a complaint). As far as I know, emails from my business custmers are branded, formatted following best practices, have unsubscribe links and a valid contact footer.
I host many email domains on this server. Most are used by private persons, some are business related. Of course private users will not brand their emails, format them using best practices, add opt-out links or a contact footer. So unfortunately for an adminstrator options are limited.
Biggest problem is, that Microsoft always blacklists the whole server! If only one of my customers does something not in line with the secret rules of SmartScreen, emails of all other customers are blocked too. IMHO this is just unprofessional. Why not just block the domain under suspicion and send the adminstrator a message (maybe as part of the JMRP)?
For me the only way to deal with this topic is to sit and wait until it happens again.
Next time I can only do the same thing that I documented in this blog article: activate my relay workaround, open a ticket via https://support.microsoft.com/en-us/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75 and push it forward until it is solved.
Was this article helpful?
Consider buying me a coffee to keep my brain fueled 🙂
from Hacker News https://ift.tt/3BO7CwQ
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.