IIS SMTP folders and domains explained

I created this post to explain the purpose of each SMTP folder. Understanding their various functions can assist in the troubleshooting process, if you encounter issues with mail delivery. There are numerous resources online that describe the SMTP folder structure however, I felt that they weren’t descriptive enough. So here’s my attempt at making this easier to understand.

SMTP Folders

When you install the SMTP service it creates the following default folder structure in order to process mail:


As you can see from the screenshot above, the folder C:\inetpub\mailroot\ contains 4 folders; Badmail, Drop, Pickup & Queue. They are explained below in the order that messages are processed:


The SMTP service will process messages in the Pickup folder as outbound messages and will attempt to deliver them. To demonstrate what happens when a message is placed in the Pickup folder, perform the following:

1. Create a text file on your desktop called email.txt and paste the following into it, remembering to change the email address information to reflect your own details:

From: blog@yourdomain.com
To: email@yourdomain.com
Subject: Email test

This is the test body of the email


2. Save the changes to email.txt and then copy the file to C:\inetpub\mailroot\Pickup. The SMTP server monitors this folder and when it detects the email.txt file, it will read the contents and send the email to the address in the To: section. This should happen almost immediately.

3. Check the email address the email was sent to and it should arrive shortly – the email was sent to my Gmail account:


A quicker way and easier was of emulating the creation of messages in the Pickup folder is to run a PowerShell command that generates an email. Enter the command below, changing where appropriate the -To and -From addresses:

PS C:\Users\admin> Send-MailMessage -SMTPServer localhost -To xxxxx@gmail.com -From xxxxx@yourdomain.com -Subject "This is a test email" -Body "Hi, this is a test email sent via PowerShell"

Messages generally don’t build up in the Pickup folder, once detected the SMTP server will try to deliver them. If the intended recipient is a member of the local domain, the SMTP service will move the message to the Drop folder.


Incoming messages intended for the local domain are placed in the Drop folder. It is very unlikely that you will require the use of the Drop folder in a real-world scenario. Messages in the Drop folder must be retrieved using an email client such as Outlook but also require POP3 server software to be installed in order to enable end-users to connect to and retrieve those messages in the Drop folder. Server 2003 had the option to install the POP3 service but this has since been deprecated on versions of Windows Server since then.

If you are seeing that messages that your applications generate are building up in the Drop folder then this will be most likely be caused by configuring the default local domain to use your DNS domain namespace. The best way to illustrate this is to show you an example.

1. Currently my default local domain is configured with the name of my server, WEB1:


2. I use the PowerShell command below to send an email to blog@vsysad.com:

PS C:\Users\admin> Send-MailMessage -SMTPServer localhost -To blog@vsysad.com -From admin@vsysad.com -Subject "This is a test email" -Body "Hi, this is a test email sent via PowerShell"

The message is subsequently placed in the Pickup folder and processed and routed through to the mail server that handles mail for the vsysad.com domain. This message is delivered successfully.

3. However, lets change the default local domain to be vsysad.com per the below:

The vsysad.com DNS domain is now considered to be a local domain. If I were to use the same PowerShell command from step 2 above, the message will be processed per the usual method but will be placed the Drop folder:


The message will remain there until I use an email client to connect to the server via POP3 to download it. This will require 3rd party POP3 mail server software to enable this.


Messages that cannot be delivered  immediately are moved  from the Pickup folder to the Queue folder. The SMTP service will attempt repeatedly to deliver messages in the Queue folder. The number of times it will attempt to deliver the message is configured in the delivery tab, see below:

I have noticed that when delivering emails to domains such as Gmail and Yahoo for the first time, messages will remain in the Queue folder for some time while the SMTP server tries to re-deliver them.


Emails that could not be delivered to the intended recipient are left in the Badmail folder. After the number of attempts configured in the Delivery tab (see screenshot above) to deliver the message have not been successful, the message will be moved to the Badmail folder. Messages in the Badmail folder will remain there until administrators diagnose the cause and implement a fix.

Common causes of messages ending up in the Badmail folder are incorrect or invalid email addresses and DNS issues. Follow instructions in these posts to verify DNS and successful mail routing respectively.

Once messages are in the Badmail folder, they can be opened up in notepad and examined. Open up the corresponding .BAD file(s) which will reveal the reason for the message delivery failure. An example is below, whereby the message failed because the recipient’s email address was invalid:


SMTP Domains

It is very important to clarify the distinction between a local domain and a remote domain within the SMTP settings. Choosing the wrong SMTP domain type will result in unintended results.

Local Domains

As stated in the Drop folder section above, a local domain is a DNS domain that is serviced by the local SMTP server. In my example, vsysad.com was the local default domain.

Messages that are received by an SMTP server that are destined for email addresses within the local domain will not be looked up in DNS, they will be dumped straight to the Drop folder. In the case of most environments the SMTP server is used simply to send mail and not to handle incoming mail for that domain. If this is the case for you, do NOT enable your DNS domain as a local domain within the SMTP server.

You can specify local domains as either default or alias. There can only be one default domain. An alias domain is an alias of the default domain. If you add a new domain and configure it as the new default, the previous default changes to an alias domain.

Remote Domains

Domains that are not designated as local are remote domains. The SMTP service looks up remote domains in DNS and will process the mail according to the settings configured for that specific remote domain. For example, you can add a remote domain and require that the SMTP service always use Transport Layer Security (TLS) encryption in sessions with that domain, which is the case for Gmail.

I hope this post demystifies the various SMTP folders and explains how mis-configuring the domain type can lead to unwanted messages in the Drop folder.

SMTP Domains
How the SMTP Service works

Testing SMTP Server using SMTPDIAG tool

I have been using a Microsoft diagnostic tool to test mail flow called SMTPDIAG. I used it on my cloud server to confirm that all the conditions required for successful mail delivery were met. The tool tests SMTP and DNS. Click here to download the tool.

Once downloaded run SmtpDiag.EXE and extract the files to a location of your choice. Then open a command prompt, go to that location and run the following command:

smtpdiag from@yourdomain.com recipient@theirdomain.com

The first parameter from@yourdomain.com is the email address that the tool is sending the email from and the second parameter recipient@theirdomain.com is the receiving email address. The tool will run through a basic set of tests and will flag any issues it encounters. To view more diagnostic information run the same command with a /v switch at the end.

smtpdiag from@yourdomain.com recipient@theirdomain.com

A sample test I ran can be seen below:


You can see that the recipient has a Gmail address so the tool will test name resolution for the domain gmail.com and comfirm it has the relevant MX records. You will notice that the first test result shows this failure:

Failed to connect to the domain controller. Error: 8007054b

This error can be ignored as the server is not an Exchange server and it not part of an Active Directory domain.

The results confirm that SMTP and DNS resolution is working fine!

You can also use telnet and Powershell to test mail sending/routing via SMTP Server. Please refer to this link to see how to do this.