I'm setting up a new dedicated server using Windows Server 2019. It's replacing an old one based on Windows Server 2008 R2. I have had the built-in SMTP server running on the old server with no issues. I have set up the new server to act as an SMTP server as well, using my own notes from setting up the old one, as well as double checking intructions online. Basically according to the instructions here:


The problem I'm having is that e-mail will not leave C:\inetpub\mailroot\Queue and will never reach the recipients. The Windows event log contains the following warning(s):

Event 4006, smtpsvc
"Message delivery to the host '' failed while delivering to the remote domain 'hotmail.com' for the following reason: The remote server did not respond to a connection attempt."

The above is just an example using a Hotmail destination address. The same kind of message is received when trying to send to addresses on other domains.

What I've tried:

  1. I have sent e-mail manually by using Telnet. The e-mail is created and received by the local SMTP server without issues, but doesn't leave the queue folder.
  2. I have run SmtpDiag against both a Hotmail and a Gmail address. No issues. The MX records are listed as expected.
  3. I have used Nslookup and confirmed that the MX records are resolved.
  4. I have successfully connected to the Hotmail and Gmail SMTP servers using Telnet.
  5. I have used Wireshark and been able to see that my server only tries to access the IP address of the destination e-mail address domain, at port 25. So, for Hotmail, it simply resolves the IP address of hotmail.com (which is and tries to open a connection to this address at port 25. This obviously fails, as there's no SMTP server there. My server never even attempts to access the SMTP server at the address specified in the MX record.

That last item above also ties into an interesting thing that I noticed, which is that the IP address listed in the event 4006 message is not one of the IP addresses listed in the MX records. It is the IP address of the actual hotmail.com domain. So, why is it attempting to contact hotmail.com and not one of the addresses listed in the MX records?

To futher investigate, I used Telnet to send to an e-mail in one of my own domains. Sure enough, I find a 4006 event in the log saying:

"Message delivery to the host '[my domain's IP]' failed while delivering to the remote domain '[my domain]' for the following reason: The connection was dropped by the remote host."

It again appears that the SMTP server is trying to connect to my domain's IP and port 25 and not to the address specified in the MX record.

This is as far as I've come. Maybe I'm misinterpreting something here, but it certainly looks like Windows' SMTP server is trying to connect to the e-mail address' domain directly at port 25 (ignoring MX records)... Any ideas on what I might be doing wrong or perhaps how I should proceed in troubleshooting this?

EDIT: Found a work-around as well as what triggers the issue. See my answer below.

  • Have you conformed with nslookup on the server itself that it can resolve the MX record of the target domains? – joeqwerty Feb 15 '19 at 15:27
  • Yes, the server has no problems resolving the MX records. I should also add that I've confirmed with Wireshark that my SMTP server calls the domain in the e-mail address at port 25. So, if it's a Hotmail address, it simply resolves hotmail.com to and tries to communicate with port 25 at that address... No other attempts are made, so it appears my SMTP server skips checking the MX records. I'll update the initial post with this info. – MrFika Feb 15 '19 at 21:07
  • You didn't accidentally put something in the 'smarthost' field in the advanced configuration did you? A smarthost would override the default MX lookup. – duct_tape_coder Feb 15 '19 at 22:21
  • 1
    I've added additional important info from further troubleshooting this. I now believe it may be a Windows bug and I think I have a work-around. – MrFika Feb 21 '19 at 15:21
  • 1
    I suggest moving the "important new info" section to an answer for this question. It's ok to answer your own question, and it looks like that's what you've done here. – Todd Wilcox Feb 21 '19 at 15:25

I have continued investigating this issue and now believe it's a bug in Windows Server 2019. I have in fact found a work-around and also how to reproduce this issue with 100% certainty.

Mail will not be sent correctly if the SMTP service start-up type is set to "Automatic" (i.e. start immediately on boot). However, if the SMTP service is set to manual start and then started manually from either services.msc or from IIS6 manager, e-mail will leave the queue and get delivered to the recipients.

If "Automatic" start-up is used for the service, any attempts to send e-mail will always result in the e-mail getting stuck in the queue and the event 4006 (see initial post for details) getting written to the event log.This is 100% reproducible in my testing.

A work-around is to set the start-up type to "Automatic (Delayed Start)". This will, if I am correctly informed, result in the SMTP service getting started 2 minutes after the last "Automatic" service has been started. This is not an optimal solution, but it'll do for the time being.

For completeness, here's a step-by-step to reproduce the issue:

  1. Install SMTP server feature
  2. Go to IIS6 manager, right-click SMTP virtual server and click "Properties"
  3. Go to the "Access" tab
  4. Click "Connection...", select "Only the list below" and add Click "OK".
  5. Click "Relay...", select "Only the list below" and add Uncheck the checkbox at the bottom of the window. Click "OK".
  6. Click "OK" again to exit the SMTP virtual server properties.
  7. Open services.msc and set the "Simple Mail Transfer Protocol (SMTP)" service startup type to "Automatic"
  8. Reboot the computer and attempt to send e-mail

Note: Steps 2 to 6 are probably not needed to reproduce the issue, but it's the basic setup I've been using.

| improve this answer | |
  • Could be a service dependecy issue, maybe the SMTP service needs something else, and won't work correctly if started before it. Although I really can't understand what could make it try to deliver messages to a domain's IP address instead of its MX record... – Massimo Feb 21 '19 at 22:31
  • May also affect Windows Server 2016, I've got a newly set up server that exhibited this exact issue, and the delay startup solution worked on it as well. – Ginji Oct 6 '19 at 13:23
  • I have 2 machines running Windows Server 2019. They both have "Simple Mail Transfer Protocol (SMTP)" startup type set to "Automatic" - one releases all emails with no problems, the other has all emails stuck in the Queue folder. All other settings are identical. I'm am trying the "Automatic (Delayed Start)" option now to see if that will allow the 2nd server to start sending emails. – brendo234 Nov 5 '19 at 18:35
  • Setting the service to "Automatic (Delayed Start)" did not seem to resolve the problem in my case. After restarting the machine, all emails remained in the Queue folder. I removed them and restarted again, still no luck. Oddly, I was able to send an email from PowerShell, but any emails generated from a webform / IIS app seem to get stuck in the Queue folder. – brendo234 Nov 5 '19 at 19:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.