# IIS/SMTP - emails are stuck in mailroot/Queue

I'm trying to send e-mails via SMTP within the IIS pickup directory. Unfortunately the e-mails are just going into the mailroot/queue folder and stay there. They never actually get sent.

Does anyone know why this would happen and a potential fix for the problem?

-
I've been having the same problem, but it turned out that this was only occurring for a specific target domain/server, i.e. I was emailing myself/colleagues using work addresses (Exchange server) and the mail just sits in the queue. I accidentally sent one to my personal gmail account and it sent without issue. Subsequently tested with hotmail and another Exchange server as the target and mail sent fine. Yet to work out what the issue is but if anyone is still having a similar problem it might be with checking this! – Matthew Swain Nov 26 '14 at 11:05

Had a similar problem with Files stuck in the queue. In IIS manager, SMTP Virtual Server > Properties > Delievery > Outbound Connections. The option for Limit number of connections to was checked and the value was 0. So it was configured to never make any outbound connections, causing the emails to never leave the server. I unchecked the option and restarted the SMTP server and all was well.

-

After restarting the 'Simple Mail Transfer Protocol (SMTP)' service, it started to work again.

-

Just for the record: we had a case where the server could not resolve names anymore due to an erraneous DNS settings. The resulting behaviour was exactly the one that you described.

-

In my experience, this is usually due to IIS SMTP trying to send and encountering a temporary (4xx response code) error. Have you turned on logging for the IIS SMTP service and reviewed the log? Sorry if that's all obvious, but it's hard to know the cause or the fix without knowing what the log shows.

-
Not obvious at all. I don't know much about IIS etc.. [i should] but i mainly focus on code, not system admin stuff. Not even sure how to setup the log. – Jack Marchetti Jan 15 '10 at 16:42
The only thing I've seen is this: Action: failed Status: 5.3.5 – Jack Marchetti Jan 15 '10 at 16:45
To enable the log, open the IIS 6 Administrator (even if you're using IIS 7, the SMTP service is still part of IIS 6), right-click on the SMTP service's properties, and go to the logging tab. You should be able to enable the log and/or find the location of the log there. – jlupolt Jan 15 '10 at 17:10

I think the issue might be that there is a confusion between IPv4 and IPv6 on the system, so when you specify localhost, the default IPv6 protocol is chosen. I had the same issue today and it was fixed after localhost reference to IPv6 address in hosts was hashed out, although that might have been a coincidence (I am also setting up SVN). So here is my setup just in case:

1. In IIS7 I have "Deliver to SMTP server" option enabled with localhost as my chosen server.
2. In IIS6 I have access set to only 127.0.0.1, no authentication for incoming or outgoing.

I fiddled with the settings all day, so, to be honest, not sure what else could have influenced the fact that it's working now. Hope this helps at least a little bit though.

-

The first place to look is the server log files. This will tell you if your server is having problems sending to specific hosts. The majority of the time this happens (in my experiences) it's usually DNS (either on your end or remotely) that is the culprit.

-

The SMTP server is looking for a SMTP host/gateway to send the mail to.

If you are trying to send to localhost, then the localhost IP would be the gateway. If you are trying to send to an external email address like gmail or hotmail, you will need to add your ISP's mail gateway as the smart host.

To set up a smart host:

1. In IIS Manager, right-click the SMTP virtual server, and then click Properties.
2. Click the Delivery tab, and click Advanced.
3. In the Smart host box, type the name of the smart host server. You can type a string to represent a name or enter an IP address.
4. If you want the SMTP service to attempt to deliver remote messages directly before forwarding them to the smart host server, select the Attempt direct delivery before sending to smart host check box. The default is to send all remote messages to the smart host, not to attempt direct delivery.
-

I had the same issue after switching email service from one host to another (new one is Office 365). After lots of trial and error, it finally started working by doing this:

1. Add my email domain to IIS 6 as a "remote" domain. (This is the domain that is hosted in O365 and all user accounts use.)
2. In IIS 6, double-click that domain; under "Route domain" select "Forward all mail to smart host" and enter your server(in my case, "smtp.office365.com"). Also check the box to "Allow incoming mail to be relayed to this domain."
3. In IIS 6, right-click the SMTP virtual server > Properties.
• Access tab: ensure "Require TLS encryption" is checked. I had to create a domain cert in IIS 7 with the name of my email domain.
• Access tab: Add your local server IP to the "Connection" and "Relay" lists.
• Delivery tab: Outbound Security: select basic authentication, enter credentials of a valid licensed user; check the box for "TLS encryption"
• Delivery tab: Outbound Connections: Enter 587 for TCP Port
• Delivery tab: Advanced: Enter your email domain as the "Fully-qualified domain name" and your email server as the "Smart host" (again in my case smtp.office365.com).

Firewall: I've read that you need to open port 587 for outbound. (I didn't because this is a VOIP server that needs its firewall off.)

Office 365: Add a "connector" under Admin > Exchange to allow your local static IP. Microsoft provides those instructions online.

-

IISRESET fixed this for me. I believe it is similar to the solution of resetting the SMTP service since this service depends on IIS. After it restarted the mail inside C:\inetpub\mailroot\Queue started to disappear!

-

Ran into this issue recently. Somebody had installed MalwareBytes onto the smtp server and the smtp mailroot folders were not whitelisted. The software treated everything in the queue as a potential spam campaign and let it time out enough times that it moved to badmail. All domains were affected. Had me puzzled (flawless operation for years now..) until I looked at running processes and noticed mbam's exe.

-

I had the same issue. As others stated it was DNS related. I have a forward lookup zone on our internal DNS servers for our public domain name (which is different than our internal domain name). I had to add the MX records on this internal forward lookup zone to match the MX records on our public domain DNS records. This resolved the issue.

-

## protected by ceejayozJul 14 at 15:03

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.