Outlook/Office365/Microsoft365 and junk mails

[patschi]

This issue is more to document and make people aware experiencing similar issues. Discussion, experiences or any tips to come to a solution might be helpful for everyone.

---

Office 365 / Outlook is quite special when it comes to get mails from your own mailserver delivered to said providers. In a negative aspect, unfortunately.

The problem
There are many reports from users having issues to get serious legit mails delivered to Microsofts' mailing service correctly, even with state-of-the-art non-blacklisted mailservers using latest techniques like DKIM, ARC and strict SPF and being part of their JMRP and SNDS program. In most cases delivered mails are always moved into Junk/Spam folder for absolutely no reason.

Important to notice: This is not limited to mailcow instances overall and is an ongoing issue since a quite long time.

If you have customers at Office 365 or even worse: Outlook.com you should tell them about this issue and migrate them to another service, as they will not be able to receive legit mail from clean mail servers. Business critical mail may never reach their mailbox. This is not the senders problem, this is a serious problem for the recipient and therefore the Microsoft customer.
Microsoft seems not to be able to handle their spam filters and tries to mitigate this problem by blocking whole foreign networks.

Solution
Unfortunately there is no solution available yet. Several users (including me) tried to get more information and support from Microsoft, but without any noticable improvement nor helpful reply. Apparently Microsoft has no interests at all that their users and companies - relying on Office 365 - gets legit mails of any relevance delivered.

Even analysing all headers on the Microsofts' end after delivering just gives you cryptic headers without any sort of explanation why their considered mails as spam. There are several docs around explaining a few details, but so far they are all either outdated or useless.

Following GitHub issues at Microsofts' docs repository are still pending since a longer period of time to hopefully get some more information:

1. https://github.com/MicrosoftDocs/OfficeDocs-o365seccomp/issues/743
2. https://github.com/MicrosoftDocs/OfficeDocs-o365seccomp/issues/442
3. https://github.com/MicrosoftDocs/OfficeDocs-o365seccomp/issues/409

What can you do?
Basically nothing. This might be a workaround.

However you are greatly welcomed to push mentioned GitHub threads above to make Microsoft more aware about this serious issues on their end. If you have more direct connections, use them.

This is going to be continuously updated...

[Adorfer]

Been there, done that, since 10+ years...
If your are stuck in this limbo at M$ (office365/live.com etc) for no obvious rasons:
get new IP/IPv4 addresses for your mailserver.

My take on this is:

• If you have a users forwarding from their account at your server to their (other) M$ accounts,
• and they are subscribed to legitimate mailinglists
• then they receive via your server spam through this list (and subsequently via your mailserver, forwarded to M$):
• If those users hit the "report spam" button on their webmail/outlook more than 2-3 times: you will be in deep trouble with your mailserver.

Invite users never to flag spam in their M$-boxes which had been forwarded through your server, especially if it's coming from 3rd party mailingslists: It helps nobody and causes a lot of frustration (especially for your users at M$ services)

[patschi]

This is indeed frustrating, and so far the only provider causing that amount of issues.

In my case, this happened during an ongoing mail conversation. In my opinion that is ridiculous and shouldn't happen at all. I was communicating with my new employer - which are hosting their mail-stuff on Office 365: We wrote about 20 serious, legit mails in both ways.

At some point their mail systems suddenly dropped my mails in the junk folders for absolutely no reason. I mean, I was writing with many different mail addresses on their end, which were replying as well. I don't get it, why their systems believe that this must be spam or something harmful. During an ongoing mail conversation. Beside the fact that mails were (detectable) replies, and not entirely new mails.

You might imagine how much confusion this has caused in the end... This can't be in the sense of Microsofts' customers.

[JustAB0x]

My current employer uses Office365 and we have issues like this all the time with smaller companies we work with. The craziest thing is: if i try to see why the email gets flagged (mail flow report via the secruity and compliance center), i just get "Flagged as Spam: No further information available".

I myself don't have this problem. I use their SNDS which may help out a bit.

[patschi]

I use their SNDS which may help out a bit.

Did it? Did you ever received a notification from their JMRP/SNDS? I've been in their programs since basically ever, and never got any message. I'm already wondering if this works at all :D

[marrco]

Did you ever received a notification from their JMRP/SNDS?

yes to my SNDS registered abuse@mydomain, also a few weeks ago from staff (at) hotmail dot com w/ subJ "complaint about message from xx.xx.xx.xx" without text and containing as an attachment the original message that a Hotmail user manually marked as spam.

No links for followup nor to mark the issue as resolved,

[Adorfer]

an attachment the original message that a Hotmail user manually marked as spam.

this is what i stated above:
Some M$-Endcustmer (hotmail.com, live.com) flags messages coming through your system as spam:-> YOUR SERVERs IP IS GOING TO THE GULAG, NO APPEALS POSSIBLE.

[JustAB0x]

I use their SNDS which may help out a bit.

Did it? Did you ever received a notification from their JMRP/SNDS? I've been in their programs since basically ever, and never got any message. I'm already wondering if this works at all :D

"may help " i'm not sure.
You do get insights into your IP status etc. So you at least now if they block you because of your IP or the messages specifically.

[SomeGeek]

My personal experience is that this problem is mainly on the free tier: outlook.com, hotmail.com, etc. Had this kind of problem a while ago, my mails where not allowed at all (blacklisted, for no reason, new server/ip). However, mails to the Office 365 paid subscription (someone with a own domain) received my mails just fine.

After multiple emails asking to at least say why I was blocked, they decided to 'mitigate' my ip for no reason. I never knew exactly it was blocked.

My take on this (and this might be a unpopular opinion, but regardless) is...

Punishing people who run their own server.

By making this thing a PITA, they can subtle convince people that it's not a good idea to run their own server at all (which I totally don't agree with, the more decentralized, the better), and switch to their service instead. Off course, there are other mail companies with a large customer base (and they can't afford to block them), but hey, every customer bringing their mails to them (including the data) is one right?

I don't see another good reason why they would do this.

[patschi]

There might be a possible workaround for some people: Routing all mails to *.outlook.com over a different mailserver, e.g. AWS SES, Sendgrid, Mailjet, etc. Somehow sad that this is the only way of getting mails over to Microsoft in a reliable way.

For some unimaginable reason (sarcasm!) there's even a Stackoverflow question with a good reply how to configure this sort of workaround using postfix's check_recipient_mx_access: https://serverfault.com/questions/663418/relay-host-based-on-destination-mx-record/663611#663611 (This can't be configured through mailcow UI, must be done manually)

[mkuron]

@patschi, I‘ve been using transport maps to deliver to {outlook,hotmail,live}.{com,de} via sendgrid and that works nicely. Sendgrid has a free tier if you send less than 100 messages per day.

Perhaps we could implement check_recipient_mx_access in Mailcow UI similar to how we deal with transport maps and add the workaround to the documentation. It‘s disappointing that we need to resort to solutions like this, but Microsoft seems to even blacklist "good" IP addresses if they don’t deliver a certain minimum number of messages per month.

[patschi]

I‘ve been using transport maps to deliver [...]

Yes, that's possible too, however this doesn't work on custom domains or Office365-hosted domains, therefore I personally like the check_recipient_mx_access-way a bit more.

Perhaps we could implement check_recipient_mx_access in Mailcow UI similar to how we deal with transport maps

Yes, I also think that this is a good idea to offer users at least a workaround for this mess. I've already told @andryyy about the idea - it's up to him to decide if and how exactly this should be integrated like.

[andryyy]

How is authentication handled? How does it interfere with transport maps?
It is not as easy as setting up a second map.

[andryyy]

Something like "asd.com FILTER smtp:bla" can also lead to funny behaviors when you bcc an address. It will probably end up duplicated.