How to Bypass the Microsoft Outlook IP Blacklist & Other Blacklists
In previous tutorials, I explained how you can easily set up your own mail server using iRedMail or Modoboa, and you can also build an email server from scratch. However, sometimes your outgoing emails might be rejected due to IP address blacklisting. 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.
I will show you how to bypass Microsoft Outlook IP Blacklist. If your mail server IP address is also blocked by other blacklists, I will show you how to get around it at the end of this article. Please note that you need to follow the entire tutorial even if your IP address is not blacklisted by Microsoft.
Microsoft Outlook Blacklist
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.
Note that you might need to contact Sendinblue customer service in order to activate the transactional email service.
SSH into your mail server and install the libsasl2-modules package, which is required for SASL authentication.
sudo apt install libsasl2-modules
If you use CentOS/Rocky Linux/Alma Linux, then install the following packages instead.
sudo dnf install cyrus-sasl-plain cyrus-sasl-md5
Next, 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 existing 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 existing 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 = noplaintext, 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.
/.*@(outlook|hotmail|live|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.
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.
A popup appears. You need to add the first 3 records for your domain.
Troubleshooting Tip
If your Postfix SMTP server failed to send the email via SMTP relay, and you see the following error in the mail log (/var/log/mail.log).
sasl authentication failed cannot authenticate to server no mechanism available
it’s probably because your system is missing the libsasl2-modules package, which can be installed with the following command.
sudo apt install libsasl2-modules
Then restart Postfix.
sudo systemctl restart postfix
Note: Sometimes the above error could be caused by an invalid TLS certificate (self-signed or expired) on the SMTP relay server. However, this rarely happens when you use Sendinblue.
How to Bypass Third-Party Email Blacklists
Now you can send emails to Microsoft mailboxes, but there are also other third-party blacklists such as the Proofpoint blacklist, which is used by icloud.com and also many other domain names. You can’t list all possible domain names that use the Proofpoint blacklist in the Postfix transport file, so how can you tell Postfix to bypass third-party blacklists?
In this case, you need to tell Postfix to fall back to Sendinblue SMTP relay if email delivery fails. Open the main.cf file.
sudo nano /etc/postfix/main.cf
Add the following line at the end of this file.
smtp_fallback_relay = [smtp-relay.sendinblue.com]:587
In this way, Postfix will try delivering the email by itself, and if the delivery failed, Postfix will use the Sendinblue SMTP relay.
smtp_fallback_relay is not perfect, because it only works when the email is soft bounced (code 4xx). If your outgoing email is hard bounced (code 5xx), then Postfix won’t use the fallback relay.
Fortunately, you can change the SMTP relay code from 5xx to 4xx, so Postfix will think all bounced emails are soft bounce and it will fall back to Sendinblue SMTP relay. To make this work, add the following line at the bottom of the /etc/postfix/main.cf file.
smtp_reply_filter = pcre:/etc/postfix/smtp_reply_filter
Save and close the file. Then create the /etc/postfix/smtp_reply_filter file.
sudo nano /etc/postfix/smtp_reply_filter
Add the following line in this file. Please don’t add any whitespace at the beginning of this line.
/^5(.*)$/ 4$1
Save and close the file. Next, build this lookup table.
sudo postmap /etc/postfix/smtp_reply_filter
Install the PCRE map support for Postfix.
- Debian/Ubuntu:
sudo apt install postfix-pcre - CentOS/RHEL/Rocky Linux:
sudo dnf install postfix-pcre
Restart Postfix for the changes to take effect.
sudo systemctl restart postfix
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.
Wrapping Up
I hope this tutorial helped you bypass the Microsoft Outlook IP blacklist and third-party blacklists. As always, if you found this post useful, then subscribe to our free newsletter for more useful tutorials 🙂
Owesome tutorial. Thanks !
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
If your VPS has multiple IP addresses, you can set up Postfix SMTP Multiple Instances with IP Rotation
Also use the smtp_fallback_relay mechanism to relay only failed emails.
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.
Totally agree.
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:
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.
And Gmail thinks my IP reputation is high.
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;
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.
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.
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. 🙂
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_passwordThank you for the amazing instructions!
You are a true asset to the Linux Community!
Thank you LinuxBabe!
A+
The Best tutorial.
Thank you so much for your time.
Quality: A+++
OS: Centos 8 Stream
Postfix
Dovecot
Spamm Assasin
My problem:
host: hotmail-com.olc.protection.outlook.com[104.47.73.33] said: 550 5.7.1 Unfortunately, messages from [IP ADDRESS] weren’t sent. Please contact your Internet service provider since part of their network is on our block list (S3150).
Very nice tutorial, thank you!
I would actually go farther. In fact, a lot of domains now use outsourced email on Azure/Microsoft/outlook. So you need to check the MX record of the domain first and determine if it points to an address ending in outlook.com (most corporate emails have an MX ending in *.eo.outlook.com or *.protection.outlook.com). Even @hotmail and @live addresses now point MX to *.outlook.com
Then you need to tell postfix to use the relay for those MXes with this command:
And make a /etc/postfix/mxtransport file with the same regex as usual:
Other instructions remain the same (setting up relay username/password for example).
Hi Xiao, thank you very much for that tutorial. I needed to implement that for destinations at T-Online/Telekom. Unfortunately they check the blacklist from UCEPROTECT where the IP of my mailserver is listed. Glad it is the only one according to MXTools. As UCEPROTECT is only willing to remove IPs if you pay a monthly fee, I think that is blackmailing. So again, thanks for that tutorial to save some money 🙂 Btw: The guys at SendInBlue are very nice and allowed me as a private person to use their relay.
Hello,
All your tutorials are super useful, thank you.
I installed my email server using all your e-mail tutorials and it worked fine. But unfortunately, after completing this section no Outlook client can receive e-mails.
I reversed the installation removed the Brevo DNS entries and get no errors but my Outlook client still doesn’t receive e-mails.
Can you please guide me to restore the Outlook problem? Many of our email contacts use Outlook.
Thank you in advance.
Dana
Hello again,
For those that consider taking the risk of installing this step. I took a lot of time to install your mail server. It is outdated now and while a good idea the steps here are not up to date and will cause your Microsft mail clients not to receive e-mails from your domain.
Reversing the steps doesn’t work either and unless you are an expert on email config you will have to start all over again.
Until it is updated please don’t waste your time.
Dana