29

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?

Improve this question
2
  • 1
    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!
    – Matt
    Nov 26, 2014 at 11:05
  • @MatthewSwain I'm seeing the same thing here. Hundreds, if not thousands, of mails sent out successfully, but 53 mails are currently stuck in the queue. They seems to all be for specific receivers/domains.
    – Zero3
    Feb 21, 2017 at 18:28

12 Answers 12

Reset to default
20

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.

Improve this answer
3
  • Good catch of this one.. however I don't recall even going on that window in the first place to check that option.. not sure how it ended with with a 0 in the first place!!
    – krilovich
    Jan 23, 2017 at 16:12
  • This occurred for us today. I went in to change a setting and "limit number of connections to" on the "General" tab got checked and has "0" also. Evidently this also changed the "Outbound Connections" setting.
    – Travis
    Apr 13, 2017 at 13:52
  • Had this multiple times where the "Limit number of connections to" option gets selected somehow and is defaulted to 0. This happens via Remote Desktop, I'm not sure why the option is being selected because it's not me doing it.
    – Jacques
    Jun 16, 2020 at 9:52
8

I had this problem today.

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

Improve this answer
4

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.

Improve this answer
2
  • 1
    What was the DNS problem?
    – MBender
    Apr 12, 2016 at 13:11
  • In my case, I had to restart our domain controllers. for whatever reason, emails to one specific client were not getting through. We host a box which has the domain setting same as the clients if that give anyone a clue to why this happens and it happens periodically...no rhyme or reason..HTH
    – Dave
    Jun 30, 2016 at 17:24
1

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!

Improve this answer
1

I ran into this issue recently. In my case, it turned out to be a problem with the DNS server definition in a network adapter (this has two for some reason unbeknownst to me). The designated DNS server was set to "127.0.0.1" instead of the normal "8.8.8.8" that is normally used on this network. I changed this to the correct value, restarted my SMTP server, and the queued emails were immediately distributed.

How I figured out that to look into the DNS definition issue:

  • Used nslookup to find an mx server to test (tested 5 or 6 different ones)
  • Tried to telnet to the server (every time met with a "couldn't connect" message that made me initially think of firewall problems)
  • Tried to ping the value for the tested mx server (every time met with a "couldn't connect to host" message)

Hopefully this will help someone else, wasn't something I'd have thought to look at initially.

Improve this answer
0

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.

Improve this answer
3
  • 2
    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, 2010 at 16:42
  • The only thing I've seen is this: Action: failed Status: 5.3.5
    – Jack Marchetti
    Jan 15, 2010 at 16:45
  • 1
    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, 2010 at 17:10
0

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.

Improve this answer
0

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.

Improve this answer
0

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.
Improve this answer
0

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.
    • General tab: Click Advanced and add your local server's IP and port 587
    • 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.

Improve this answer
0

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.

Improve this answer
-2

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .