Test DNS and TCP connectivity from the failing Linux App Service itself, then compare its SMTP configuration and outbound IP set with the working API; one app succeeding does not prove that another app uses the same network path or source IP.
1. Test from the failing app
- Open the failing app in Azure portal.
- Select Development Tools → Advanced Tools → Go → Tools → Debug Console → CMD.
- Run:
nslookup smtpout.secureserver.net
curl -v smtpout.secureserver.net:587
Replace the hostname and port with the exact GoDaddy SMTP endpoint configured in the application. For Linux App Service, nslookup tests DNS and curl hostname:[port] tests connectivity from the app sandbox.^1^
Interpret the result:
- DNS lookup fails: compare the apps’ Networking → Virtual network integration and DNS-related configuration.
- Connection times out or is refused: continue with outbound-IP and port checks below.
- TCP connects: networking is working. Compare the application’s SMTP hostname, port, credentials, encryption mode, and logs for TLS or authentication errors.
Run the same commands from the working API so the results are directly comparable.
2. Compare outbound IP addresses
Each App Service app has a set of outbound addresses, and an outbound connection can use any address in its current set. GoDaddy or an intervening firewall might allow the working API’s addresses but not the failing API’s addresses.^2^
For each API:
- Open App Service → Properties.
- Compare:
- Outbound IP Addresses
- Additional Outbound IP Addresses
- If GoDaddy uses an IP allowlist, add all current outbound IP addresses for the failing app—not just one.
The same comparison can be made in Cloud Shell:
az webapp show \
--resource-group <resource-group> \
--name <app-name> \
--query "{current:outboundIpAddresses,possible:possibleOutboundIpAddresses}" \
--output json
If GoDaddy requires one predictable source address, use App Service virtual network integration with Azure NAT Gateway. Virtual network integration is available on the Basic tier, including B1.^2^
3. Check the SMTP port
If the failing API is configured for port 25, change it to GoDaddy’s authenticated submission endpoint and port 587, provided that endpoint supports it. Microsoft recommends authenticated SMTP relay over TCP 587 for App Service; port 587 is not subject to Azure’s SMTP restriction.^3^
For port 587, compare the failing API against the working one for:
- Exact SMTP hostname
- Port
587
- Authentication enabled
- Username and secret source
- STARTTLS/TLS enabled
- App settings and deployment-slot settings
Do not assume the values are identical merely because both applications target GoDaddy.
Port 25 should not be the default design. App Service port-25 scenarios depend on network architecture such as virtual network integration or App Service Environment v3, while authenticated relay on port 587 is the supported general approach.^3^
4. If failures are intermittent
If connections sometimes succeed and later time out, inspect App Service → Diagnose and solve problems → Outbound connections from my app are failing. Rapidly creating SMTP connections to the same host and port can exhaust SNAT ports; App Service initially allocates 128 SNAT ports per instance, and closed connections are reclaimed after a delay.^4^
In that case:
- Reuse SMTP connections where the client supports it.
- Dispose connections correctly.
- Avoid opening many parallel SMTP sessions.
- Correlate timeouts with request volume and the App Service SNAT diagnostics.
If TCP connectivity succeeds but SMTP still fails, capture the exact SMTP exception and server response. That distinguishes TLS negotiation, authentication, sender-policy, and recipient-policy failures from Azure outbound networking.
References
- Troubleshoot virtual network integration with Azure App Service
- Inbound and outbound IP addresses in Azure App Service
- Troubleshoot outbound SMTP connectivity problems in Azure
- Troubleshoot intermittent outbound connection errors in Azure App Service