A Practical Guide to Implementing Incoming Email using the SharePoint Directory Management Service

SharePoint 2010 and 2013 include functionality to implement Incoming Email into Libraries and enable SharePoint Groups to leverage an email address in Active Directory.  For Libraries, SharePoint allows users to submit items to the Library without having to visit SharePoint.  For SharePoint Groups, a Distribution Group is created with the SharePoint group’s members.  This implementation guide covers a specific way of implementing SharePoint Incoming Email.  Various parts of this guide can be done differently, but this is my personal preferred way of implementing SharePoint Incoming Email.

Implementation

In order to leverage SharePoint incoming email and the Directory Management Service, at a minimum the Exchange Server 2003 schema extensions are required.  Note that an Exchange server is not required.  You can leverage a 3rd party Active Directory-integrated product as the mail server.

The first step to leveraging the DMS would be to extend the Active Directory schema.  These schema extensions are on the Exchange 2003, 2007, 2010, or 2013 media.  In general, to perform the extension, a user that is an Enterprise and Schema Administrator would run:

There are various articles revolving other requirements surrounding each of the versions of Exchange’s requirements for extending the schema, such as forest and domain level, etc.  For the purposes of this article, an Exchange 2010 SP2 server has been installed in the domain.

The next step is to identify one or more SharePoint Servers in the farm to handle Incoming Email as well as how to weight the SharePoint Servers within DNS using MX records.  If you want to use DNS to round-robin, each SharePoint Server will receive the same weight in the MX records.  If you want a primary and a fallback Incoming Mail setup, then weight one SharePoint Server with a lower value for MX (e.g. 10) and another one higher (e.g. 20).  The server with a lower value will always handle the Incoming Email unless it is unavailable.

First, create a new MX record in your domain.  For the purposes of this example, I used “sharepoint”, so my FQDN would be “sharepoint.nauplius.local”.  While there is only a single Incoming Email server in this example, the steps to set up each server are the same.  In this example, I’m routing “sharepoint.nauplius.local” (MX record) to “sharepoint.nauplius.local” (A record).  In a production environment, you might route “sharepoint.mycompany.com” (MX record) to “spserver01.mycompany.com” (A record).

SharePointMXRecord

Once the MX record has been established, the next step is to install the IIS6 SMTP Service on your target SharePoint Server(s).  To do this, run the following PowerShell command or install the Simple Mail Transport Protocol Feature in Server Manager.

Next, configure the IIS6 SMTP service.  Under Administrative Tools, find Internet Information Services (IIS) 6.0 Manager.  Expand “[SMTP Virtual Server #1]” and “Domains”.  Rename the default domain from servername.mycompany.com to match the MX record previously created.  In this example, sharepoint.nauplius.local.

SMTPDomains

If you go to Properties on the domain, you can configure the Drop folder here if the default of C:\inetpub\mailroot\drop isn’t a desirable location.  However, this Drop folder must be consistent on all SharePoint Servers.

Go to Properties on the SMTP Virtual Server #1.  Under Access -> Authentication, validate that Anonymous is checked (note that SharePoint handles authorization for incoming email, so Anonymous, for most installations, should be okay).

SMTPAuthentication

 

Under Access -> Relay, place any Relay restrictions that are required, such as the Exchange Hub Transport server(s).

SMTPRelay

Other settings you may want to consider are under the Messages tab.  While SharePoint will enforce the Web Application’s maximum file size which has a default of 50MB, SMTP server’s default mail size is significantly smaller at 2MB.  Consider changing the “Limit message size” and “Limit session size” values, or removing the restriction entirely.  The session size will be slightly larger than all messages in the session.

SMTPMessages

For troubleshooting purposes and general logging, on the General tab click “Enable logging”.  IIS SMTP logs are stored, by default, in %windir%\system32\LogFiles\SMTPSVC1.

The next step is to configure the Drop folder security.  Again, by default, this folder is located at C:\inetpub\mailroot\drop.  On the drop folder, give WSS_WPG NTFS Read & Execute rights.  Give WSS_ADMIN_WPG NTFS Full Control rights.  Do this for each SharePoint Server handling Incoming Email.

Now we’re going to switch our attention to the Exchange Server to set up our Send Connector to cover the sharepoint.nauplius.local namespace.  Under Organization Configuration -> Hub Transport -> Send Connectors, create a new Send Connector.  Provide it a name, e.g. SharePoint. Leave the intended use as Custom.  In the Address Space screen, add an Address Space matching your SharePoint Incoming Email domain (in this example, sharepoint.nauplius.local).  All other settings can remain at their defaults.  For the Network Settings, we’ll leverage MX to route email.  Add an applicable Source Server, or just use the default.  Here is an example of my setup using Exchange PowerShell:

SendConnector

Mail sent to sharepoint.nauplius.local will now route to the SharePoint Server.

The next step is to switch focus to Active Directory.  SharePoint will need an Organization Unit that it can create Contacts and Distribution Groups in.  This means we will need to delegate the SharePoint Timer Service (Database Access/Farm Admin) account rights on the selected Organization Unit in order to create, modify, and delete these objects.

First, create a new OU in an appropriate place in Active Directory.  In this example, I will be using nauplius.local/SharePoint/IncomingEmail (or the LDAP path of CN=IncomingEmail,CN=SharePoint,DC=nauplius,DC=local).

OU

Next, run the Delegate Control wizard on the new OU.  Delegate the access to the Timer Service account and create a custom task to delegate.  Delegate control of “Only the following objects in the folder”.  Select “Contact objects” and “Group objects”.  Also check the boxes for “Create selected objects in this folder” and “Delete selected objects in this folder”.  Next, select Full Control.  This will give the Timer Service account Full Control over Contact and Group objects in this particular OU.  When looking at the Advanced Permissions on the OU after completing the delegation, it should look similar to:

OU-AdvancedPermissions

Back to Exchange, create a new Accepted Domain under Organization Configuration -> Hub Transport -> Accepted Domains.  Provide it with a name and the FQDN of the SharePoint domain (e.g. sharepoint.nauplius.local).  Set the type to Internal Relay as both Exchange and SharePoint will be handling email for this domain.

Create a new E-Mail Address Recipient Policy under Organization Configuration -> Hub Transport -> E-Mail Address Policies.  Provide the policy with a name that denotes that it is used with SharePoint.  Select the recipient container (Organization Unit) that contains the SharePoint-created Distribution Groups.  Include Mail-enabled groups only as the recipient type.  For the E-Mail Addresses, for the Local Part, use the alias, and for the domain, use the FQDN of the SharePoint domain (e.g. sharepoint.nauplius.local).  To create this in PowerShell, run:

Because SharePoint creates legacy Distribution Groups, create a PowerShell script on the Exchange server that runs the Update-EmailAddressPolicy command on a regular basis.  Distribution Groups that are not updated will not receive an email address and will be unable to be used by end users.

Let’s shift focus to SharePoint.  Navigate to Central Administration.  Go into System Settings -> Configure incoming e-mail settings.

Under Enable sites on this server to receive incoming e-mail, select Yes.  Under Settings mode, select Advanced.  For “Use the SharePoint Directory Management Service to create distribution groups and contacts”, select Yes.  Next, enter the LDAP path of the OU where the Timer Service has been delegated access to create Contact and Group objects.  Next, enter the SMTP namespace under “SMTP mail server for incoming mail”.  In this example, that would be “sharepoint.nauplius.local”.

If you only want users that are authenticated to be able to send email to SharePoint, select Yes on “Accept messages from authenticated users only”.  Otherwise, select No.  This is also controlled at the Library level, although if you answer Yes here, the Library level will not be able to accept anonymous e-mail regardless of the Library setting.  Consider other 3rd party systems that may need to e-mail into SharePoint that are not tied into Active Directory when taking into account this particular setting.

If you want SharePoint to be able to create Distribution Groups, select Yes on “Allow creation of distribution groups from SharePoint sites”.  If Yes is selected, the SharePoint Administrator can also require approval from a SharePoint Administrator prior to creating these Distribution Groups. Note that approving Distribution Groups must be done in a particular way.  Select any approvals that should be required in the following four checkboxes.

For the “Incoming E-Mail Server Display Address”, enter the SMTP namespace that is used for SharePoint.  Again, in this example, it is “sharepoint.nauplius.local”.

Finally, specify the E-Mail drop folder.  Again, by default it is “C:\inetpub\mailroot\drop”.  This folder must be consistent on all SharePoint Servers handling Incoming Email.

LibrarySettings

The last step to enabling Incoming Email is to start the Incoming Email service on all applicable SharePoint Servers in the farm.  Under Central Administration -> System Settings -> Manage services on server, start the “Microsoft SharePoint Foundation Incoming E-Mail” service.  This will kick off a timer job named “Microsoft SharePoint Foundation Incoming E-Mail” that runs once per minute that checks the Drop folder on the target server.  This timer job can either be monitored in the ULS logs, or in the Event Logs under Applications and Services Logs -> Microsoft -> SharePoint Products -> Shared -> Operational.  An Informational Event with an ID of 6871 with a Task Category of “E-Mail”.  The event will log the number of messages processed, the time it took to process them, and the Message IDs.  It will also create an event if no messages are processed.

EventLog

Next, we move onto a SharePoint Site.  Again, each Library and SharePoint Group can have an associated email address.  For Libraries, go into the Settings for the Library and select “Incoming e-mail settings”.  Here, you can enable Incoming Email into the Library. You can also configure the Local Part of the SMTP address, while Central Administration controls the Domain Part of the SMTP address.  If a Library attempts to leverage an already-in-use Local Part, it will indicate that there is a conflict and it that address cannot be used.  Other settings such as attachment handling, saving the original email, etc. can be configured here.  Lastly, you can configure whether or not incoming emails will be validated against the Library permissions (such as if a user emails a Library and does not have Contribute permission, their email will be rejected) or if it will accept email from any sender (this includes anonymous emails).

LibrarySettings

Emails that are able to be authenticated (for example, a user using their Exchange account in the same Exchange Organization that SharePoint is a domain member of) will show the email having been created by that user.  Otherwise, the email will be created by the System Account.

Moving onto SharePoint Groups, go into the Site Settings -> People and Groups.  Under a Group that should be assigned an e-mail address, go to Settings -> Group Settings.  Under “Create an e-mail distribution group for this group”, select Yes.  Provide a valid Local Part for the “Distribution list e-mail address”.  If the SharePoint Administrator has required approval to create, modify, or delete a DL, then the SharePoint Group will sit in a Pending status until the SharePoint Administrator has approved the DL creation, modification, or deletion.  Otherwise, the action is processed immediately.

GroupSettings

If the SharePoint Administrator has required approval for creation, modification, or deletion of a Distribution Group for a SharePoint Group, then the Administrator will need to visit Central Administration -> Site Settings -> View All Site Content -> Distribution Groups.  Here they can view all pending requests and approve them.  However, please see Incoming Email Distribution Group Approval for the correct way to approve Groups, otherwise Groups will remain in a Pending status.

Troubleshooting

If Incoming Email is not working, there are a few things to validate.  First, validate that email can be sent to the server using the specified SMTP namespace by using telnet.  See KB153119 for details.  Next, check the SMTP service logs, by default located at %windir%\System32\LogFIles\SMTPSVC1.  RFC1893 defines the common SMTP status codes.  In general, 2xx is good, 4xx and 5xx are bad.  There is also the Event Log pointed out previously along with the ULS log.  The ULS logging for Incoming Email can be adjusted under Central Administration -> Monitoring -> Configure diagnostic logging -> SharePoint Foundation -> E-Mail.  Other things to check would be the Badmail and Queue directories in C:\inetpub\mailroot.  Also check the Exchange Queue Viewer for any errors when routing messages to your SharePoint SMTP namespace.

Note that any email rejected by the SharePoint timer job, for example due to lack of permissions on a Document Library or an invalid address, are immediately deleted.

Fun Facts

The maximum alias length for a Distribution Group is 128 characters as is the maximum attachment file name length.

If a Distribution Group is in the Pending state, Microsoft calls it a “Dirty DL”.

Contacts and Distribution Groups are created as Legacy when in Exchange 2007 or higher environments.  This is due to SharePoint not assigning an Exchange Version higher than “0”.  See SharePoint Creates Legacy Contacts in Active Directory.

Related Content

Setting Message Size Limits

Configure incoming e-mail (SharePoint Server 2010)

Exchange Server 2010 Email Address Policies

How to Create and Manage Exchange Server 2010 E-Mail Address Policies

Incoming Email Distribution Group Approval

SharePoint Creates Legacy Contacts in Active Directory

14 Comments

  1. Thanks – this is really good information. I have a question: I have a doc lib setup to receive emails, but I am having a challenge with domain groups sending mails in – is this possible? I have granted contribute permissions to not only the domain group, but to all those who are a member of the group. Despite having done this, though the individuals can mail into SharePoint, the domain group cannot.
    Any thoughts you can share will be greatly appreciated – thanks!

    • I haven’t tried that particular scenario, but my assumption would be that SharePoint needs to either associate the incoming email with the System account (for anonymous emails) or with a particular User.

  2. thanks for very informative article,

    I have a question relating to setting up Incoming email. Do i need to configure SMTP server feature on a SharePoint server even if a dedicated SMTP server has been setup? Please advise best way I can configure this?

    When I configured outgoing email I used SMTP dns name.

    Thank you
    Regards
    Vimz

  3. Amazing! I was stumped for a week before finding this article. Thanks for such an informative, thorough, and easy to follow process!!

  4. is there anyway to enable incoming email for a farm, but hide the option in a library or list? We’d like to enable incoming email but somehow keep control of which lists or libraries are email-enabled. It seems like incoming email can get out of control quickly if it’s not properly controlled and managed, especially since it’s a global farm level option, and can’t be restricted by web app or site collection.

    • Unfortunately once the service is on, it is on farm-wide and cannot be disabled on a per-List/Library basis. The only way to control this is via permissions, by disallowing management of Lists/Libraries, which I realize isn’t practical.

  5. Trevor, does this guide hold good if SharePoint farm and Exchange environment are in two different domains and also if two-way trust relationship exist between these two domains?

  6. Excelent guide!
    One question, is there a way to avoid installing the SMTP Servicer on the Sharepoint Server? I’d like to maintain Exchange as the only SMTP. Maybe telling Sharepoint to use a remote drop folder…
    Thanks!

    • You must have an SMTP server that provides a Drop folder. Exchange won’t be useful for that. I believe you can use a UNC path as the drop folder within SharePoint, though. You wouldn’t want this on Exchange anyhow as you must permission the Drop folder for the SharePoint service accounts.

  7. Is it sufficient to create this MX record on public DNS servers (plus some firewall rule) if I want to extend this feature to outside users such as Yahoo mail or Gmail or Hotmail users?

    • Yes, that’s what you’d want to do. What I typically do is set that MX to route to my mail gateway (e.g. anti-spam service or Exchange CAS, etc.) and from there, create a connector to route it to SharePoint (again using MX usually, or A record).

      • Hi Trevor
        How would one go about setting this up to allow external users the ability to email the lists?
        The smtp server that is created is set on the local domain, and thus the email addresses the lists obtain are also local.
        We need the ability for external users (i.e. from other organisations) to be able to email the lists. (We have Sp2013 and Exchange 2010) – a step by step would be absolutely amazing if possible.
        Thanks in advance

        • It must be a valid, resolvable domain on the Internet. I would suggest simply configuring Incoming Email to use that domain, or look up address header rewriting in Exchange. There are a few examples to rewrite messages from one address to another. This will still require a valid, resolvable domain on the Internet routed to your Exchange server for relay to SharePoint.

Leave a Reply