This part of the alert troubleshooting guide will talk you through the steps necessary to verify that emails can be successfully routed from your SharePoint server to the users mailbox.

You should have first read the introduction so you know the difference between the confirmation Emails and Alert emails and understand why :-

• Even if you get one of those you may still need to verify how your email setup is configured.
• You need to check each WFE and your index server

You may also want to read this short SMTP primer if you are new to SMTP and related email technologies.

Sending test emails

First check the email settings in SharePoint central administration are correct (SharePoint Central Administration > Operations > Outgoing Emails Settings) – note the Outbound SMTP server, From and Reply To addresses.

Use these settings to send some test emails using a tool like the SMTP Test Tool or Telnet on your SharePoint servers to send some test emails.

If you don’t receive the emails you expect verify.

• Does the SMTP server permit connections (relay’s) from your SharePoint servers?

• This post shows how you can configure Microsoft Exchange to accept connections from SharePoint

• Is the destination SMTP server configured to deliver emails or relay them to another SMTP server and if so is it working?

• Is there anything that may block SMTP transmissions on port 25 (common to stop mass mailing worms/viruses). For example :-
  • A firewall running on or in between the SharePoint server and the SMTP server
  • Antivirus software
  • Remember that if your security blocks SMTP transmissions based on process or account then test tools such as Telnet or SMTP Test tool will be a different process and will often be running under a different account to SharePoint and the timer service.
    

• Does your SMTP server require a username/password or SSL?
  • In which case you will have to install something like Windows IIS SMTP server (locally on or another server), set SharePoint to deliver emails to this and then deliver emails directly or relay those emails onto your main SMTP server. This guide shows how you would set IIS SMTP server to relay messages from SharePoint to smtp.google.com as an example.

If you do get the emails you expect from these test tools

• Verify that you haven’t got any anti-virus or other security in place that could allow these test messages through but still block the ones from SharePoint – see “Is there anything that may block SMTP transmissions…” above
• Go back to the flowchart and continue onto the next step

You are able to send test emails to some users, but not others

(Note – this section does not apply to emails sent by SharePoint but only to test emails sent using a tool like SMTP Test tool or telnet – see above)

The good news is that you know in this case that its not a problem with SharePoint – its time to bring in whomever is an expert on your email infrastructure but a few tips to get you started :-

• Is this user’s email is being delivered successfully from other sources, what about external email addresses such as hotmail / gmail?
  • This can help narrow down the problem between problems on the sending side an receiving side.

• Do emails to users on the internal domain get delivered and external email addresses fail (or vice versa) – in which case you need to look in detail at your email infrastructure to determine where the problem lies. 
  • If internal emails are getting through but external ones are not then use the SMTPDiag utility to verify DNS configuration on your SMTP server are not stopping external delivery.

As always the wildcards are SPAM filters and email auto processing rules – always suspect these first!