Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I want a document library to recieve email and store it so followed the steps outlined here: http://sharepointgeorge.com/2010/configuring-incoming-email-sharepoint-2010/

I seem to be a bit stuck. The mail's being delivered to the machine and it's appearing as .eml files in the drop folder, so SMTP and delivery is OK.

I assume Sharepoint's supposed to pick up the file, stick it in a library and delete it, but it doesn't, the mail file just sits there.

Nothing in the logs, obviously.

I haven't set this up before, how often does the timer service come about and pick up the mail?

share|improve this question
I had this same issue. Im not sure why but it is a security issue. the timer was using moss service account. We changed it to use moss admin account and it started working. Hope this helps –  user4048 Jul 8 '11 at 20:46
No!!! The Timer Jobs run under the Farm account, sharepoint is counting on this in a lot of places (i.e. data access to the config db etc.). Pretty much all off sharepoint's automated actions use this account / service/ You should change the account back to the original value! Just grant access to the drop folder / smtp server forthe original account! –  Colin Jul 8 '11 at 22:28
We did grant access to the drop folder but still no luck. this wasn't the first time we changed the account to admin. There were issues all over with basic functionality that should work out of the box but for some reason the service account just wouldnt behave. Im an intern still learning sharepoint, I understand that by changing the account to admin you may be opening yourself up to hackers. If I change the account back to service, how would you recommend getting this to work? Is it permission levels or something? again we tried granting access to the drop folder but no go. Thanks –  user4048 Jul 8 '11 at 23:28
See this hope it helps combined-knowledge.com/Downloads/2007/… –  naijacoder Oct 5 '11 at 6:44
I have the same problem, Did you resolve it anyone ? Thanks, Martin –  user7679 Apr 3 '12 at 14:42

11 Answers 11

The guide mentions there being a delay between sending your email and seeing the document show up. I assume it is a timer job that performs the email pickup tasks. Is the SharePoint timer service running? It is called SharePoint 2010 Timer

If the service IS running, are you able to see your job running in central admin? No jobs should be running right now if the Timer service is stopped.

share|improve this answer
Yes, timer service is running and the mail pickup is scheduled to run each 5 minutes. I can trigger the job manually as well. However, there's no history of the job ever being run, which makes me think that it's failing somewhere along the line. But I can't find a record in ULS or the Windows logs. –  Dan Jun 8 '11 at 2:49

I had same problem, after all I changed in Configure Incoming E-Mail Settings->Settings mode to -> ADVANCED and specified E-mail drop folder Path :c:\inetpub\mailroot\drop. I hope this answer will help somebody :) .

share|improve this answer
This setting did the trick for me. Appreciate it. –  Ken Oct 18 '12 at 17:30

On a multi-server farm, be sure the "Microsoft SharePoint Foundation Incoming E-Mail" service is running on the same server you're using for the SMTP service, presumably one of your front end servers. Check this in Central Admin-System Settings-Manage Services on Server and cycle through your servers on the top-right. In my case the above mentioned service was running by default on my APP server and I had to stop it and switch it on on my FE server.

share|improve this answer
Yes, yes yes. Checked that. In this case it was a single app-server farm, and all services were running. –  Dan Nov 16 '12 at 18:45
Hats off, by the way, that this question still draws responses. Love the stack! –  Dan Nov 16 '12 at 18:46
For multi-servers restart the "Micrsoft SharePoint Foundation Incoming E-mail" service on all WFE servers. I couldnt figure this issue out for a few hours before I simply restarted the services and IT WORKED! –  sharepointaaron Apr 9 '14 at 12:26

The timer job that picks up mail runs about every 5 minutes or so, so you should not see the email sit there for long. If it does just sit there, and the Timer service is running, then the problem may be that SharePoint does not recognize the TO address as an email-enabled document library.

Make sure that you have configured the incoming email domain to correctly match the mail domain of the SMTP service, and that you don't have any typos in the email address compared with the incoming email address name on the target library.

share|improve this answer
Email is being delivered fine and the address of the list is correct. The Timer Service is running but when I checked the job definition (Microsoft SharePoint Foundation Incoming E-mail) there's no history of the job being run. What's up with that? –  Dan May 25 '11 at 3:56
Try running the timer job manually with the "Run Now". Has the timer job been disabled? –  Chris Beckett May 25 '11 at 22:29
Tried that, it still doesn't pick up the mail and it doesn't leave a record in the history. Can't find anything in the logs either. –  Dan May 30 '11 at 6:43

This worked for me after spending countless hours searching!! http://blogs.msdn.com/b/george_bethanis/archive/2012/05/25/sps2010-cannot-send-incoming-emails-to-lists-libraries.aspx?CommentPosted=true#commentmessage

share|improve this answer
Welcome to SharePoint.SE! While this post may answer the question, we prefer more details such as "why". Please edit your post with additional details. See How to Answer for general guidelines. –  Kit Menke Jul 31 '12 at 20:53

Check if there're an X-Sender and X-Receiver headers in your emails - they are required. These headers is automatically added if you use the SMTP service in Windows. Anyway there must be a error in the SharePoint log regarding your emails - what does it say?

share|improve this answer

In addition to other solutions provided here, this solution may fix your issue. Specially if you send an email to the document library and receive a delivery failure message similar to below

Delivery has failed to these recipients or groups:

Your message was not delivered due to a permission or security issue. It may have been rejected by a moderator, the address may only accept e-mail from certain senders, or another restriction may be preventing delivery.

Diagnostic information for administrators:

Generating server: smtp1.contoso.com

#< #5.7.1 smtp;550 5.7.1 Unable to relay for documentlibrary@sharepoint.contoso.com> #SMTP#

Original message headers:

By default when you install the SMTP service on the SharePoint server, the domain is the fully qualified named of the server. ex: SPSrv01.contoso.com

enter image description here

Rename this domain name to the Incoming E-Mail Server Display Address (this can be found in the Central Administration website, under Configure Incoming E-Mail Settings.

enter image description here

enter image description here

share|improve this answer

I had the exact same problem of some incoming mails for a list A being stuck in the drop folder while incoming mails for another particular list B were delivered just fine.

The following article helped me: This worked for me after spending countless hours searching!! http://blogs.msdn.com/b/george_bethanis/archive/2012/05/25/sps2010-cannot-send-incoming-emails-to-lists-libraries.aspx?CommentPosted=true#commentmessage

And indeed, both A and B were in different site collections. While B had a limit site storage defined, A had not. Upon specifying a limit storage under Current quota template, for the site collection of A, it started working immediatly. As described in the above article.

share|improve this answer

FYI Just finished debugging this with MS Tech Support. Turned out that if you have Sandbox quotas turned on for a site collection that contains email enabled lists/libraries, the quota needs to be at least 600. Note: having the quota set to 0 doesn't work. We're not even using sandbox solutions, but this still needs to be set...

This is a known bug in SP2013 (recently introduced I think) and between us we confirmed that it's also a bug in SP2010, introduced by one of last years patches.

share|improve this answer

I came across the same issue on SharePoint 2013. As strange as it sounds, but solution was to change the value of Sandboxed Solutions resource Quota from 0 to something else. enter image description here

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.