How to Deal With the Microsoft Outlook IP Blacklist

In previous tutorials, I explained how you can easily set up your own mail server using iRedMail or Modoboa, and I shared some tips on getting your IP address removed from blacklists. However, some folks have a hard time getting off the Microsoft Outlook IP blacklist, which is used by outlook.com, hotmail.com, live.com, and msn.com mail servers.

Microsoft Outlook typically sends back the following message if your IP address is blocked.

host eur.olc.protection.outlook.com[104.47.22.161] said:
550 5.7.1 Unfortunately, messages from [xx.xx.xx.xx] 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.
[DB8EUR06FT013.eop-eur06.prod.protection.outlook.com] (in reply to MAIL
FROM command)

As you can see, the whole IP range is blocked. Personally, I don’t think this anti-spam technique should be used due to the collateral damage done to legitimate senders. In contrast, Gmail is much more intelligent in handling IP reputation. You can submit the sender information form to solve this problem. Sometimes Microsoft would unblock your IP address, sometimes your request would be refused.

A surefire way to get your IP address off the Outlook blacklist is to get your mail server certified by Return Path. However, it’s very expensive. You need to pay a one-time $200 application fee and at least $1,375 license fee per year. I will show you a free way to bypass the Outlook IP blacklist.

Using SMTP Relay Service to Bypass Microsoft Outlook IP Blacklist

You can configure your mail server to relay emails via SMTP relay services. They maintain a good IP reputation, so your emails can get through IP blacklists. There are many SMTP relay services. Some charge a little fee, some offer free quotas every month.

You don’t have to configure your mail server to relay all of your emails. I will show you how to configure your Postfix SMTP server to relay emails that are sent to outlook.com, hotmail.com, live.com and msn.com email addresses only, so you won’t use up free quota quickly. There are not many people using Microsoft mailboxes these days. Only 6.5% of my subscribers are using hotmail, outlook, live, and msn email addresses.

Here I recommend the SendinBlue SMTP relay service, which allows you to send 9,000 emails/month for free. No credit card required.

Configure SendinBlue SMTP Relay

Create a free account at SendinBlue. Once you complete your user profile, click the transactional tab, you will get your SMTP settings.

sendinblue SMTP relay settings

Note that you might need to contact Sendinblue customer service in order to activate the transactional email service.

SSH into your mail server and open the Postfix main configuration file with a command-line text editor like Nano.

sudo nano /etc/postfix/main.cf

Add the following line at the end of this file.

transport_maps = regexp:/etc/postfix/transport.microsoft

Hint

If you use iRedMail, you can find the transport_maps parameter and add the regexp line.

transport_maps =
    regexp:/etc/postfix/transport.microsoft
    proxy:mysql:/etc/postfix/mysql/transport_maps_user.cf
    proxy:mysql:/etc/postfix/mysql/transport_maps_maillist.cf
    proxy:mysql:/etc/postfix/mysql/transport_maps_domain.cf

If you use Modoboa, you can find the tranport_maps parameter and add the regexp line.

transport_maps =
        regexp:/etc/postfix/transport.microsoft
        proxy:mysql:/etc/postfix/sql-transport.cf
        proxy:mysql:/etc/postfix/sql-spliteddomains-transport.cf

Then add the following lines to the end of this file.

# outbound relay configurations
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = may
header_size_limit = 4096000

Save and close the file. Next, create the /etc/postfix/transport.microsoft file.

sudo nano /etc/postfix/transport.microsoft

Add the following line in this file. This tells Postfix to use Sendinblue SMTP relay if the recipient is a microsoft mailbox user.

/.*@hotmail.*/i             relay:[smtp-relay.sendinblue.com]:587
/.*@outlook.*/i             relay:[smtp-relay.sendinblue.com]:587
/.*@live.*/i                relay:[smtp-relay.sendinblue.com]:587
/.*@msn.*/i                 relay:[smtp-relay.sendinblue.com]:587

Save and close the file. The create the .db file.

sudo postmap /etc/postfix/transport.microsoft

Next, create the /etc/postfix/sasl_passwd file.

sudo nano /etc/postfix/sasl_passwd

Add the SMTP relay host and SMTP credentials to this file like below. Replace smtp_username and smtp_password with your own username and password that are given by SendinBlue. Note there’s a colon between the username and password.

[smtp-relay.sendinblue.com]:587            smtp_username:smtp_password

Save and close the file. Then create the corresponding hash db file with postmap.

sudo postmap /etc/postfix/sasl_passwd

Now you should have a file /etc/postfix/sasl_passwd.db. Restart Postfix for the changes to take effect.

sudo systemctl restart postfix

By default, sasl_passwd and sasl_passwd.db file can be read by any user on the server.  Change the permission to 600 so only root can read and write to these two files.

sudo chmod 0600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

From now on, Postfix will use Sendinblue SMTP relay to send emails to Microsoft mailbox users. You can send a test email to a hotmail.com, outlook.com, live.com or msn.com email address.
Note that you need to click the Senders & IPs tab in your account dashboard to add your domain.

sendinblue add senders and domains

Set Up SPF/DKIM Authentication in SendinBlue

In your SendinBlue dashboard, click your account name on the upper-right corner, then click Senders & IP. Select the Domains tab -> Manage -> Authenticate this domain.

sendinblue authenticate domain

A popup appears. You need to add the first 3 records for your domain.

sendinblue spf and DKIM authentication

Getting Out of the Spam Folder

SMTP relay services can get you around IP blacklists, but that doesn’t mean your emails will be land into the inbox 100%. Your emails might be placed into the spam folder. If you comply with email-sending best practices, your emails will eventually be placed into the inbox folder.

I created a new hotmail.com mailbox as a test. The first 3 newsletters sent from my domain were placed in the spam folder, but all remaining emails were placed into the inbox folder. I didn’t do anything in my Hotmail account. I didn’t open my newsletter or click any links in the newsletter. I simply use best practices to send emails, so Microsoft knows my emails are not spam.

Tips for Staying out of the Microsoft Blacklist

Microsoft may remove your IP address from the blacklist if it found no spam activity from your mail server for a period of time. Here are some tips to prevent your IP address from getting blacklisted again.

  • Don’t send newsletters right away with this IP address to Microsoft mailbox users. You should first send transactional emails to improve your IP reputation with Microsoft.
  • If you send newsletters, be sure to warm up your IP address.

You can log into the Outlook.com Smart Network Data Services to check your IP reputation with Microsoft. If your IP address sends more than 100 messages on a given day, you can click the view data link to see the mail traffic and spam data for your IP address.

Microsoft uses 3 colors to distinguish spam rate for your IP address:

  • Red: Spam > 90%
  • Yellow: 10% < spam < 90%
  • Green: Spam < 10%

As you can see from the two screenshots, my IP reputation has improved.

microsoft outlook hotmail mail traffic and spam data

microsoft outlook email IP reputation

Wrapping Up

I hope this tutorial helped you bypass the Microsoft Outlook IP blacklist. As always, if you found this post useful, then subscribe to our free newsletter for more useful tutorials 🙂

Rate this tutorial
[Total: 2 Average: 5]

19 Responses to “How to Deal With the Microsoft Outlook IP Blacklist

  • Owesome tutorial. Thanks !

  • Stenfrank
    11 months ago

    Excellent tutorial, at this moment my IP has just been blocked for no reason.

    I wanted to ask you if I have several IPs, could it be redirected from another IP only emails to hotmail?

    Thank you

  • OwN-3m-All
    9 months ago

    Thanks a ton! Microsoft is a tyrannical organization. They suck so much. They don’t give you a reason for why your IP range is on their blocklist, and when you try to get them to remove your range, they give you no information and deny your request despite the fact that your server is NOT sending spam. My servers adhere to good email policies, and they do NOT send spam.

    Screw Microsoft. They’re worse than Google at this point.

    I guess they’ll just blacklist IP addresses for over 100 years… only hurts them in the end. No one should use a Microsoft email account.

  • Actually, Microsoft, and specifically outlook.com is currently the number one source of SPAM second only to google currently, contrast this with only December where Google was of course the number one spammer, and outlook.com was number 6. I suspect that google has made some changes that make it harder for spam accounts to be setup quickly, hence the transfer to outlook.com but I don’t know for sure. If you’re considering sending bulk email via outlook.com then I wouldn’t bother, we’ve already added penalties just for the domain outlook.com to bias the spam flag and if it continues at this rate we’ll have to increase this.

    Unfortunately, due to the epic levels of spam, sending legitimate bulk email is becoming increasingly hard to do, and I suspect it won’t get any easier.

    • It’s very important to have clean IP addresses for sending legitimate bulk email. Unfortunately, big well-known VPS providers are abused by spammers. They will abuse every VPS provider they can find.

      I think using a managed VPS might be better because the VPS is configured by the technical support staff of the hosting company and if the customer sends spam, it will be stopped very quickly.

      • Actually, IP address is only really applicable for the first hop in the route. That is, if you’re sending through sendgrid for example, they may have IPs blacklisted, but once you’re email is accepted and in transit, it will come to us from sendgrid’s IP’s. I quote sendgrid here because we block any header with sendgrid in it by default, but we also block many others based on headers, not IP. The problem everyone has is that rampant abuse of email bulk senders means that ISP’s (like us) who offer mail filtering and protection, are forced to use recipient reports, content, compliance, reputation, return-path, attachments, pattern, headers, IP’s, DKIM, SPF, DMARC and blacklists, which will unavoidably block legitimate bulk senders who happen to be using the same bulk sending platform.

        The best advice I can give is bulk send from your own domain, on your own IP block, with SPF, DKIM and DMARC, to validated legitimate receipients, and bulk SLOWLY. Sending 10k emails at once sets off alarms all over the place and will not only get your IP flagged but probably contents and headers.

    • If you block every email with Sendgrid headers in it, you are effectively blocking every Sendgrid IP address, right?

      • Yes, sendgrid is a bulk email sender and is one of the bad ones with high levels of spam so its blocked entirely using header checks. This ensures that no email sent through sendgrid reaches any of our customers.

        When we analyse email traffic, we look at a breakdown of the headers, originating IP’s, relay count and various detection flags, as an example; for any one period we may see 10k email’s flagged as spammy either by users, honeypots, or content/ip/reputation blacklists that originate via a_bulk_sender vs a total of 20k from the same sender. That would give them a 50% spam rate and we would probably take the decision to simply block them via headers. We make these decisions daily or sometimes hourly based on trends from many sources.

        Off the top of my head, currently completely blocked are sendgrid, markethub, cloudapp, instillerhq, sparkpost, e-broadcaster, thunder server, emarksman, e-merge, global messenger, mailcast, mailking, massemail, powermailer, quickshot, worldmerge and more, and these change all the time.

        So back to my original point, if you’re going to use a bulk sender, then your email volume is lumped in with everyone else’s, a fair % of which will be spam and if that spam % breaks thresholds, the entire sender is penalised along with all the traffic they relay, and that’s out of your control.

        Use your own domain, own static, own rDNS, setup DKIM, SPF, DMARC and you’re totally in control and can blame no one else for delivery issues.

    • Thanks for your detailed answer. I thought ESPs (Email Service Provider) like Sendgrid is good at controlling spam on their servers, but you changed my view. I have used sendpulse, sendinblue and mailjet, the email deliverability of which is pretty good in my experience. I have never used Sendgrid.

      Back to my original point, if a sender uses VPS (Virtual Private Server) to run a self-hosted mail server, he/she has a dedicated IP address. There are two types of VPS:

      • self-managed VPS: The hosting company only ensure your VPS is online and provides no extra technical help. You are responsible for software installation, setup, optimization, updates, backup, uptime monitoring, and malware scanning.
      • managed VPS: The hosting company ensures your VPS is online and takes care of server management for you. You don’t need to worry about software installation, setup, optimization, updates, backup, uptime monitoring, and malware scanning.

      Instead of using a self-managed VPS, it better to use a managed VPS to run your mail server. This is because managed VPS is configured by the technical support staff of the hosting company and if the customer sends spam, it will be stopped very quickly, so the IP address of managed VPS won’t get blacklisted.

      I run my mail server on ScalaHosting. As you can see from the screenshot below, my mail server’s IP address (130.51.180.110) isn’t on any blacklist.

      mxtoolbox-email-blacklist-check

      And Gmail thinks my IP reputation is high.

      gmail-postmaster-tools-check-IP-reputation

      • I agree, managed is a better option for anyone not intimately familiar with postfix (or sendmail) and DNS all of which can be time consuming to setup correctly and pass all the tests, but once its all setup you can bulk knowing that its your reputation on the line and you won’t be tarnished by other spammers. This should provide the best possible delivery performance to all marketers.

        Final points that you’ve probably already covered;

        • Wash your lists often, deal with bounces automatically and swiftly.
        • rate limit delivery by domain. That is, if you have 10k emails to send to gmail, don’t send them all at once but spread them over time. All good email list handlers offer this setting.
        • setup [email protected] [email protected] mailboxes and handle complaints. If you don’t have these, you’ll soon be on an RFC non-compliant list and will work against you.
        • ALWAYS send from an address that both exists and accepts mail.
        • Format your email’s well. Ensure you have both text and html sections, stay away from linking web resources (they’ll be blocked by most good clients anyway) and don’t get clever with scripting, it’ll mark you down.
        • Check reputation daily, once you start being impacted its hard to recover quickly.
        • Check your server logs daily, secure, audit, httpd, maillog, and update often. linux is great, but a single incorrect setting can result in compromise and all the bad things that happen after.

        I hope this helps, I’ve been as open as I can be, and hope this helps people who are legitimate. For spammers, no matter how smart you think you are, we’re always watching, always adjusting and are very effective at screening it.

  • Zubair Ahmad
    5 months ago

    Thank you so much dear.
    I followed the procedure and it’s working perfectly.
    Thanks once again with love.

  • Thanks so much for this. It’s great to be able to email the few people I know with @outlook.com addresses again. Microsoft has no data for my mail server’s IP address, but it still insists on blocking it.

    Just a word of caution, though. The instructions include adding a DKIM record from sendinblue to your domain’s DNS. That’s probably a terrible idea unless all of your domain’s email is to be sent via sendinblue. That might be sendinblue’s default assumption, but it doesn’t apply to this particular use of their service. Any other email that is sent (i.e. email to any domain other than one of Microsoft’s) would need to be sent via a DKIM-capable mail server that has access to the private key that sendinblue seems to set up. I would skip that part, and just add “include:spf.sendinblue.com” to your SPF record.

    • Only emails sent through Sendinblue would need to be signed by Sendinblue DKIM private key.
      Emails sent from your mail server directly to recipients are signed by your own DKIM private key, which is stored on your own mail server.

      The DKIM records are used by the recipient’s SMTP server to verify the DKIM signature found in the email.

      If the email is signed by your own DKIM private key, then it will use your existing DKIM record.
      If the email is signed by Sendinblue DKIM private key, then it will use the Sendinblue DKIM record.
      If there’s no DKIM signature in the email, then your domain’s DKIM records won’t be used.

      It doesn’t matter how many DKIM records your domain has. As long as each DKIM private key has a corresponding DKIM record, then your emails will be fine.

      Just because you publish a DKIM record, doesn’t mean you have to DKIM sign the email. It’s the opposite. If your email has a DKIM signature, then you have to publish a correct DKIM record.

      • Thanks for explaining that. I suppose that must imply that you can have multiple mail._domainkey TXT records, one for each sending mail server. However, if you use DMARC to specify that SPF and/or DKIM need to be used, then what I said is valid. And if you don’t use DMARC, then there’s probably not much point in using DKIM in the sense that it won’t prevent anyone forging mail apparently from your domain. They just need to not include DKIM headers.

    • No. You still can do this and should do this when you use DMARC. If you don’t DKIM sign the sendinblue emails, then DMARC verification will fail.

      DMARC doesn’t stipulate you must use your own DKIM signature. To pass DMARC verification, your emails need to meet one of the following requirements.

      1.) SPF pass and the Return-Path: domain name is the same as the From: header domain.
      2.) DKIM pass and the d= domain in DKIM signature is the same as the From: header domain.

  • An slightly improved version of the transport.microsoft file given above is:

    /.*@(outlook|hotmail|live|msn)\..*/i    relay:[smtp-relay.sendinblue.com]:587

    This version is more correct because it requires a dot after the domain.
    Unless it’s important to not require the dot(?).

    And it should be faster because there’s only one regex.

  • Some of the main.cf parameter settings given above are unnecessary or theoretically less secure.

    The following might be of use if you’d prefer a mininalist change to your postfix configuration and/or don’t want to reduce its security posture.

    The header_size_limit does not need to be changed to 4096000 (i.e. 4000KiB). The default value of 102400 (i.e. 100KiB) is more than enough for any reasonable individual logical header. I would be surprised if any individual logical header was larger than 4KiB, let alone 100KiB. If you are really sending emails with individual logical headers that exceed 100KiB, you might want to reconsider what you are sending. 🙂

    And sendinblue does not require you to change the more secure default value for smtp_sasl_security_options (i.e. “noplaintext, noanonymous”) to the less secure
    value of “noanonymous”. It probably doesn’t matter in practice, but changing that value is telling postfix that it’s OK to send your sendinblue credentials unencrypted (or any other outgoing SMTP credentials you might need). Connecting to sendinblue works perfectly well with the default value.

    So, my suggested version of the above configuration is:

    /etc/postfix/main.cf:
    smtp_tls_security_level = may
    smtp_sasl_auth_enable = yes
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    transport_maps = pcre:/etc/postfix/transport.microsoft

    /etc/postfix/transport.microsoft:
    /.*@(outlook|hotmail|live|msn)\..*/i relay:[smtp-relay.sendinblue.com]:587

    /etc/postfix/sasl_password:
    [smtp-relay.sendinblue.com]:587 smtp_username:smtp_password

Leave a Comment

  • Comments with links are moderated by admin before published.
  • Your email address will not be published.
  • Use <pre> ... </pre> HTML tag to quote the output from your terminal/console.
  • Please use the community (https://community.linuxbabe.com) for questions unrelated to this article.
  • I don't have time to answer every question. Making a donation would incentivize me to spend more time answering questions.

The maximum upload file size: 2 MB. You can upload: image. Links to YouTube, Facebook, Twitter and other services inserted in the comment text will be automatically embedded.