Emails are constantly marked by Outlook.com as SPAM

Question

One of our domains is constantly marked by Outlook as SPAM, despite the adequate setup that is reported as properly configured and validated by many on-line tools, among those, the mxtoolbox.

Please note that in any other platform or server, emails are received correctly into the inbox, without any user intervention.

To help you understand and/or provide an answer to the problem at hand:

This domain exists for over a year.
The IP address is within a range of IPs managed by us for over an year (IP and range are clean).
This domain has an SSL certificate and sends emails thru SSL/TLS.

Attaching sample email headers, reflecting the authentication results, of a message dispatched from the domain in question, and received by an email account @outlook.com:

Received: from SN1NAM02HT119.eop-nam02.prod.protection.outlook.com (2603:10a6:6:14::16) by DB6PR08MB2805.eurprd08.prod.outlook.com with HTTPS via DB6PR05CA0003.EURPRD05.PROD.OUTLOOK.COM; Wed, 7 Feb 2018 12:37:27 +0000

Received: from SN1NAM02FT033.eop-nam02.prod.protection.outlook.com (10.152.72.56) by SN1NAM02HT119.eop-nam02.prod.protection.outlook.com (10.152.72.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Wed, 7 Feb 2018 12:37:26 +0000

Authentication-Results:
spf=pass (sender IP is XXX.XXX.XXX.XXX)
smtp.mailfrom=EXAMPLE.COM; outlook.com;
dkim=pass (signature was verified) header.d=EXAMPLE.COM;outlook.com;
dmarc=pass action=none header.from=EXAMPLE.COM;

Received-SPF: Pass (protection.outlook.com: domain of EXAMPLE.COM designates XXX.XXX.XXX.XXX as permitted sender) receiver=protection.outlook.com; client-ip=XXX.XXX.XXX.XXX; helo=SRV-HOSTNAME.COM;

Received: from SRV-HOSTNAME.COM (XXX.XXX.XXX.XXX) by SN1NAM02FT033.mail.protection.outlook.com (10.152.72.133) with Microsoft SMTP Server id 15.20.464.11 via Frontend Transport; Wed, 7 Feb 2018 12:37:25 +0000

┌────────────────────┬───────────────────────────────────────────────────┐
│ Data               │ Refers to                                         │
├────────────────────┼───────────────────────────────────────────────────┤
│ XXX.XXX.XXX.XXX    │ The correct server IP address                     │
│                    | Proper Reverse DNS setup                          |
├────────────────────┼───────────────────────────────────────────────────┤
│ EXAMPLE.COM        │ The domain name in question                       │
│                    | Proper DNS setup                                  |
├────────────────────┼───────────────────────────────────────────────────┤
│ SRV-HOSTNAME.COM   | The server hostname                               |
|                    | (hosts multiple domains)                          |
└────────────────────┴───────────────────────────────────────────────────┘

---

Related with this issue:

How/where can we query Outlook technical support about this issue ?
or
How can we obtain technical detail about their classification of our messages so we can understand the issue and deal with it ?

Answer 1

Microsoft does more DNS/MX processing than other providers, which might explain your problem. See this SO answer for pointers which might be helpful.

Beyond this, you just have to accept that if you're trying to deliver anything to users with MS webmail then you'll have problems. I'm lucky enough to have some control over my recipients, and I ask them not to use MS accounts, with some success. I have to provide detailed instructions on whitelisting for the ones who won't change.

Having said that, MS will actually whitelist you if you ask them nicely. Google "microsoft deliverability support team" and fill in the webform, which is currently here. The problem is that this only lasts a year or so, so you have to repeat frequently and, worse, you have to wait until someone notifies you that they're no longer getting your mails. Good luck.

Answer 2

I've been looking into this as I had the same issue and below is a description of what I've been able to determine.

Firstly, you should be doing all the things you should be doing anyway as a mail sender.

1. Make sure the IP address you're sending from has a PTR ("reverse DNS") record which maps to a hostname you own, and that hostname lists that IP address as one of its A records. This is forward-confirmed reverse DNS as defined by returnpath.com (I've seen FCrDNS defined differently elsewhere so watch out for inaccurate information about this - in reality, FCrDNS is less restrictive than some people think).

2. Make sure your server is sending a real hostname in its HELO/EHLO command and not something generic like "localhost" or just a subdomain with no domain. It's a good idea for this to be the actual host that's sending the mail.

3. Check your sending IP address isn't on any major blacklists. The check on mxtoolbox.com should return zero blacklist hits - the check on multirbl.valli.org might return one or two, because some of the blacklists on that site are "questionable".

But in addition to this there's some things specific to know about Microsoft servers (outlook.com, hotmail.com, live.com):

1. Spam filtering isn't black and white - a message Microsoft thinks is spammy can override doing everything else right, and a mail that doesn't look spammy might get through correctly even if you are making some mistakes in your server setup. What they think looks like spam is anyone's guess, but the types of URLs in the message may be one factor.

2. Microsoft themselves admit that a new or low volume IP address may have mail classified as spam until it gets a better reputation - that is, until enough non-spam is received from that address. I like to think that people going to their spam folder and marking your mail as "this is not spam" should help accelerate this process, but I can't confirm. Logically, it would make sense for this to only help deliverability to that person.

3. DKIM, SPF and DMARC are a good idea but I've seen a lot of mail get through to outlook.com that has no DKIM (and therefore no DMARC either) or that fails one of those two latter tests. Make sure SPF information is correct and try using "?all" at the end so that a negative result is indeterminate rather than representing a fail. Remember that changes to the SPF entry in your DNS take time to propagate and Microsoft may even cache it up to 48 hours even if that's longer than DNS would otherwise.

4. Microsoft advise that certification with returnpath.com should help deliverability as they partner with that service. Unfortunately that seems like it costs a bunch of money, and I'm also not convinced it has much benefit to regular mail servers, being aimed more at people with large mailing lists with a high volume of mail sent to mailing list subscribers.

5. Microsoft have a Junk Email Reporting Program which can let you view information about your sending IP address' reputation. I haven't so far been able to enrol with this service and I'm skeptical that it would go into much detail about why an email may be classified as spam, as it sounds like it's more about giving an idea of whether people are actually reporting your mails as spam.