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 outlook.com:587
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://smtp.office365.com:587" -u "email:password" --mail-from "emailFrom" --mail-rcpt "emailTo" --ssl --upload-file temp.txt
https://stackoverflow.com/questions/14722556/using-curl-to-send-email
https://social.msdn.microsoft.com/Forums/en-US/b18ffb03-0efb-4775-8216-d3fab9ed13a1/azure-function-smtp-error?forum=AzureFunctions
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.
References
Sendgrid: https://docs.microsoft.com/en-us/azure/sendgrid-dotnet-how-to-send-email
Office 365 : https://blogs.msdn.microsoft.com/benjaminperkins/2017/01/11/sending-email-from-an-azure-web-app-using-an-o365-smtp-server/
Amazing troubleshooting steps
[…] Información tomada del blog de Jeremy Brooks: https://blog.brooksjc.com/2018/09/18/troubleshooting-smtp-issues-sending-emails-from-azure-web-apps/ […]
[…] Isolate app vs something elseThe cool thing about Kudu is that you essentially can test the connectivity completely outside the context of your application code. This is a helpful step as you may not own the code, there could be a potential bug or misconfiguration, or the app is just not behaving as expected. The next step is possible is to test the protocol you’re trying to connect with using curl or SQL cmd. As mentioned above CURL supports a wide variety of protocols and I’ve used it to debug FTP, SMTP, and most of the time HTTP related issues.Ways this is helpful:– You can specify TLS versions to identify if the reason your app is failing to connect due to it using an older TLS version such TLS 1.0 or 1.1 by specifying –tlsv1.0 in the curl request– You can run some operation like downloading a file to confirm if potential download speeds are related to your code or the platform using curl to call something like blob storage– You could build an HTTP Put, Post, Patch or Delete with a specific body to full understand how authentication is working without potential ambiguity in your code. You can also see response headers that could showcase if some appliance or proxy in the middle is actually the service returning the 403 or 503.– Test SMTP connectivity as described in my blog here: https://blog.brooksjc.com/2018/09/18/troubleshooting-smtp-issues-sending-emails-from-azure-web-apps/ […]