Troubleshooting SMTP issues/Sending emails from Azure Web Apps

In the past year I’ve come across a number of issues related to sending emails from web apps that work locally but when a customer is developing or deploying to an Azure Web App, the connection fails. Here are some straightforward step by step troubleshooting steps to isolate platform vs your code.

1. Are you using a Relay Service or are you trying to send email directly from the web application?

If you are not using a relay service to send email, you are in an unsupported scenario within all of Azure (including running an application in a VM or cloud service). To reduce the possibility of customers using Azure resources to send SPAM emails we do not allow sending email directly from any service in Azure. See the blog below. Relay services include SendGrid, O365, other third-party relay services, and customer’s own on-premises relay services. So first verify if the customer is using a relay service. If they do not have a relay service they must configure their application to use one, there is no other workaround.

2. Can you make a TCP connection over the correct port to Email Relay Service?

Before we look at the application code, let’s isolate platform/basic network issue vs application code issue. The easiest way to do this is to use the command tcpping *ip or hostname*:port . Technically you should only be using 587 or 443. Connecting to the relay over port 25 may work but the recommendation is 587 or 443.

example: tcpping

a. If it the tcpping test fails?

If the tcpping test fails, then its most likely an issue connecting to that external service. Make sure there isn’t a firewall or network device blocking connections. This is a basic TCP test where we send a Ack TCP packet and are looking for a Syn packet acknowledging the connection. This is not a complex call so a timeout typically means an issue on the customer’s side. If the you need to whitelist IPs, they can do so with the outbound IPs for the web app

b. If it works?
If/once this works move on to step 3.

3. Can you connect to the relay service as a test using curl smtp://….?

The next step is using the curl smtp command to make a call to the relay service to make sure we can connect successfully and authenticate to the service. If you get any SMTP specific errors, they are usually pretty self explanatory such as a user being unauthenticated, SSL/TLS errors, or the inability to send email from that user account.

1. Navigate to console via the Platform features under the Function app or under Kudu.
2. Type touch temp.txt under the D:/home/site/wwwroot or whatever you want to call the file (touch creates a new file)
3. Run the command below with the values changed to your respective endpoints, email and password ect. Since you are only testing the authentication piece you can leave the txt file blank and just have dummy values for the -from and -to address. The -v switch will output verbose logging to better pinpoint what the issues is.
curl --connect-timeout 15 -v --insecure "smtp://" -u "email:password" --mail-from "emailFrom" --mail-rcpt "emailTo" --ssl --upload-file temp.txt

4. If all of the above troubleshooting steps worked and its still failing from your application, we’ve most-likely isolated it to your code so the my recommendation is to review your code further. As a recommendation you can see if you can try to use another method temporarily to unblock your development.

Office 365 :