Load Balancing Incoming Email in SharePoint 2007

After a recent bout of teaching and testing folks, it became obvious that we are somewhat lacking in our information about some of the finer points of configuring incoming email in SharePoint 2007.  So, below are some notes that I made around some of the SMTP and Exchange configuration steps that are necessary to get things working well.

Items 1 through 3 are applicable exclusively to routing incoming mail, and are all about configuring the IIS SMTP Service that you would typically run on one of your SharePoint web front end servers.  Remember you configure the SMTP Service in Windows Server 2003 by using the IIS Manager snap-in.  It also assumes that you have Exchange 2007 in your organization and a Send Connector already configured for an Address Space that a) includes the name of the server (like wfe1.foo.local) and the network smart host mapping in that connector is configured to send it to the same server.  For example, the Send Connector would have an Address Space of wfe1.foo.local and a smart host configured on the network tab of wfe1.foo.local.

1.  In the Access…Relay Restrictions settings you can restrict relay to ONLY the Exchange server that is going to route messages to the SharePoint farm, and deny all others.  You can do the same for Access…Connection Control.

2.  In Delivery…Advanced, if you DON’T have to use the same delivery name in Masquerade domain that is configured in the SharePoint Incoming Email Settings in Central Admin (like @wfe01.foo.local).  Masquerade domain just allows you to have a different domain name displayed on outgoing messages from the SMTP server (like non delivery messages).

3.  In Delivery…Advanced Smart host, you can leave that field blank and incoming messages are still delivered.

4.  If you are load balancing email between multiple SharePoint servers running the IIS SMTP service, it can be VERY difficult to get working.  Assume for example that you have two WFEs in the farm, and their server names are wfe1.foo.local and wfe2.foo.local.  You want to use both of them for routing incoming mail so you have some high availability for incoming email in the farm.  Also assuming you have Exchange 2007 SP1 in your organization and that’s what your users use for their email server.

To begin with, you need some load balancing mechanism in place in the farm.  You should already have this if you have multiple web front end servers.  For purposes of our conversation we’ll assume you have NLB on your web front ends and they use a Virtual IP (VIP) of

Next, you need an alias for those SMTP servers; that’s the first part of the name that will become part of the document library email address.  Lets assume you want to use “mossmail” as your SMTP servers email alias.  That means that the email addresses for your document libraries will be something like LibraryName@mossmail.foo.local (since in our example our local domain is called ‘foo.local’).  We now have all of the information we need to configure our servers.

Start with DNS – create a Host (A) record called mossmail in the foo.local zone; give it an address of  Now any requests for mossmail.foo.local will go to the VIP address of, and NLB will be responsible for passing the request to either wfe1 or wfe2.  NOTE:  for routing email internally only, you DO NOT need an MX record.

In Exchange, we need a Send Connector.  The Send Connector is where we configure a set of mail addresses that Exchange should look for, and the server(s) it should send those messages to.  In this case we’ll create a new Send Connector and in the Address Space we’ll add a new SMTP address space of mossmail.foo.local.  In the Network settings for the connector, we’ll configure it to route the mail to following smart hosts:  mossmail.foo.local.  So at this point if a user opens up Outlook and sends a message to LibraryName@mossmail.foo.local, that message is sent to Exchange.  Exchange looks at the Send Connector and sees that it should route messages for mossmail.foo.local to a “server” called mossmail.foo.local.  It looks up that address in DNS, gets the VIP of back and sends the SMTP message to that address.  NLB picks up the request and routes it to either wfe1 or wfe2.

The final piece of the configuration happens on the the web front end servers running the SMTP service – in our case, wfe1 and wfe2.  First, you need to make sure the SMTP service is configured to start automatically.  Next, you’ll open up the IIS Manager snap-in, expand it so you can see the Default SMTP Virtual Server, right-click on it and select Properties.  Click on the Access tab and then click on the Relay button.  In the dialog that opens up, enter the IP address of the Exchange server that is going to be routing SMTP messages to the web front end. It is a best practice to limit the ability to relay only to servers that you trust.  So, click the top radio button that says Only the list below, click the Add… button, and type in the IP address of the Exchange Server.  Click OK to close out the Relay dialogs and save those changes.  Note that you can also make the same change using the Connection button.  It will just further insulate you from exposure if you think you need it.  Next, click on the Delivery tab, and then the Advanced… button.  This next step is not strictly required, but it is a good practice in terms of keeping your naming schemes consistent from an SMTP perspective.  In the Fully-qualified domain name edit box, type mossmail.foo.local.  Click the OK button to save those changes, then click the OK button to close out the Properties dialog.  Finally, the last thing needed is a domain alias, so that the SMPT server knows that it is responsible for routing email for the mossmail.foo.local domain.  In the IIS Manager snap-in, expand the Default SMTP Virtual Server tree and click on the Domains object.  Right-click on it and select the New…Domain… menu.  A wizard will start up; click the Alias radio button and then the Next button.  Type mossmail.foo.local in the Name edit field then click the Finish button.  Finally, YOU MUST restart the SMTP service for these changes to take effect.

The rest of the configuration takes place in SharePoint’s Central Admin…Incoming Email Settings now.  While I won’t walk through that step-by-step, I will just say that in the E-mail server display address edit field, type in mossmail.foo.local when you are saving your changes.  Now, create a new or mail enable an existing document library, give it an email address, and send it a message with an attachment.  You should hopefully be good to go at this point.

5.  For outgoing mail, like when you create an alert and you receive the alert confirmation email, it doesn’t use any settings on the local SMTP servers.  Instead it relies entirely upon the SMTP server name that was configured in the Central Admin Outgoing email settings.

So the net is pretty simple:

For incoming emails, you can plug in the name of a single server (like img5.foo.local) or a load balanced name (like mossmail.foo.local).  Each one of those servers (either the single server or all of the servers in the load balanced name mossmail.foo.local) need to have their SMTP server configured and running.  The setup is extensive for a load balanced SMTP server scenario, but very quick and easy for a single server.