Fix: “Transport Failed to Connect” SMTP Error in Desktop Apps

Microsoft Exchange logo

A dealership’s operations team contacted us because their CRM software, which they used for sending marketing emails and customer communications, had suddenly stopped sending emails. The error message said the transport failed to connect to the server. The CRM vendor confirmed the issue was on the IT side, not their software. We found the SMTP relay service had recently started enforcing authentication, which the CRM did not support. Adding the office’s public IP address to the relay service’s allowed senders list resolved the issue immediately.

Symptoms

When a line-of-business (LOB) desktop application (CRM, accounting software, ERP system, or similar) tries to send emails via SMTP, the application displays one of the following errors:

The transport failed to connect to the server.

You may also see variations such as:

Unable to connect to the remote server

SMTP connection failed: Authentication required

Common characteristics of this issue:

  • The application was sending emails successfully before, and nothing changed on the application side
  • The error appears for all users of the application, not just one person
  • The application is configured to send via SMTP on port 25 without authentication credentials
  • Other email services (Outlook, webmail) continue to work normally
  • The application vendor confirms their software is working correctly and the issue is on the IT/network side

Affected Software

  • LOB Applications: Any desktop application that sends email via SMTP, including CRM systems (e.g. Tune, Method, Act!), accounting software (e.g. MYOB, Xero desktop), ERP tools, and industry-specific software
  • SMTP Relay Services: SMTP2Go, SendGrid, Mailgun, Amazon SES, Microsoft 365 Direct Send, Postmark
  • Protocols: SMTP on port 25 (unauthenticated), port 587 (authenticated with STARTTLS), port 465 (SSL/TLS)

Cause

Modern SMTP relay services require authentication (username and password, API key, or OAuth) for all connections. This is a security measure to prevent unauthorised use of the relay for spam.

Many older LOB desktop applications only support basic unauthenticated SMTP sending on port 25. They have no fields for entering SMTP credentials, or their SMTP implementation does not support modern authentication methods like STARTTLS or OAuth.

When the SMTP relay service starts enforcing authentication (either through a policy change, a security update, or a migration to a new relay provider), the LOB application can no longer connect. The relay rejects the unauthenticated connection attempt, and the application reports a “transport failed” error.

This typically happens when:

  • The SMTP relay provider tightens their security requirements
  • Your organisation migrates to a new relay service that enforces authentication by default
  • A previously configured IP whitelist entry expires or is removed
  • The office’s public IP address changes (e.g. after an ISP change or router replacement) and the relay no longer recognises the source

Resolution

Step 1: Identify Your SMTP Relay Service

Check the SMTP server address configured in your LOB application. This tells you which relay service is in use. Common examples:

  • mail.smtp2go.com - SMTP2Go
  • smtp.sendgrid.net - SendGrid
  • smtp.mailgun.org - Mailgun
  • email-smtp.[region].amazonaws.com - Amazon SES
  • [tenant].mail.protection.outlook.com - Microsoft 365 Direct Send

If you are not sure which service your organisation uses, check with your IT provider or look at previous email headers for the relay hostname.

Step 2: Find Your Office’s Public IP Address

From any computer on the office network, visit whatismyipaddress.com or search “what is my IP” in Google. Note down the public (WAN) IP address shown.

If your organisation has multiple offices or remote workers who need to send from the LOB application, you will need the public IP address for each location.

Step 3: Add the IP to Your Relay’s Allowed Senders List

Log in to your SMTP relay service’s admin portal and add your office’s public IP address to the allowed senders or IP whitelist. This tells the relay to accept unauthenticated connections from that IP address.

Where to find the IP whitelist setting by provider:

SMTP Service Where to Add Allowed IPs
SMTP2Go Settings > Allowed IPs > Add IP Address
SendGrid Settings > IP Access Management > Add IP Addresses
Mailgun Sending > IP Pools > Authorized Recipients (or API-based IP whitelisting)
Amazon SES IAM policy with IP condition, or use SMTP credentials instead
Microsoft 365 (Direct Send) Exchange Admin Centre > Mail flow > Connectors > configure connector to accept from your IP

Step 4: Test Sending from the LOB Application

  1. After adding the IP, wait a few minutes for the change to take effect
  2. Open the LOB application and send a test email
  3. Confirm the email is received by the recipient
  4. If the email still fails, double-check the IP address is correct, verify the SMTP port (usually 25 for unauthenticated relay), and check that no firewall is blocking outbound traffic on that port

Important Notes

  • Static IP recommended. If your office internet connection uses a dynamic IP address, the IP can change without notice, which will break the whitelist. Contact your ISP to request a static IP, or set up a monitoring alert so you know when it changes
  • Port 25 may be blocked by your ISP. Some Australian ISPs block outbound traffic on port 25 by default. If adding the IP whitelist does not fix the issue, ask your ISP whether port 25 is open on your connection. You may need to request an unblock or use an alternative port
  • Prefer authenticated SMTP where possible. IP whitelisting is a workaround for applications that cannot authenticate. If the LOB vendor releases an update that supports authenticated SMTP (port 587 with STARTTLS), switch to that method as it is more secure and works from any network location
  • VPN and remote workers. IP whitelisting only works when the application sends from the whitelisted IP. If staff use the LOB application from home or via VPN, the traffic may come from a different IP. In that case, you may need to route SMTP traffic through the office network via VPN, or whitelist additional IPs
  • Document the configuration. Record which IP addresses are whitelisted, which relay service is in use, and which applications depend on it. This saves troubleshooting time if the issue recurs after an IP change or provider migration

If you need help configuring email sending for your business applications, get in touch with our team.

Was this article helpful?
Ready to secure and simplify your IT? Talk to a GCIT expert today.