SMTP

An unknown error occurred connecting to the SMTP server

TCP/TLS failure (common in Sage 50) means the connection handshake never finished. Fix the host, port, and TLS mode, then use OAuth2 or an app password.

Updated Jul 1, 2026

The short answer

"An unknown error occurred connecting to the SMTP server" is an application catch-all (common in Sage 50 and desktop mail clients), not an RFC reply code. It means the program could not complete the TCP/TLS connection or login handshake. Fix it by correcting the host, port (587 for STARTTLS or 465 for implicit TLS), and TLS setting, allowing those ports through your firewall, and using modern authentication (OAuth2 or a Gmail app password), since Google disabled Basic Auth in 2022 and Microsoft is phasing it out.

"An unknown error occurred connecting to the SMTP server" is a generic, application-generated message — not a standard SMTP reply code. It is produced by the sending program (most commonly Sage 50, but also Outlook, Thunderbird, and other mail clients) when it tries to open a connection to an outgoing mail server and the attempt fails before a meaningful response can be read. Because the client cannot map the failure to a specific SMTP reply (e.g. RFC 5321's 421 or RFC 3463 enhanced codes), it falls back to "unknown error."

In practice this almost always means one of three things failed: the TCP socket to the server, the TLS/SSL handshake, or the authentication step.

What causes "An unknown error occurred connecting to the SMTP server"?

The label is a catch-all, so the real cause is usually one of these:

  • Authentication method no longer supported (or on its way out). This is the single biggest cause today. Google disabled legacy username/password (Basic) authentication for Gmail SMTP in 2022 — a plain username/password no longer connects there. Microsoft is on a slower timeline: per Microsoft's revised, January 2026 plan, Basic Auth for SMTP AUTH (Client Submission) still works today, moving to admin-reversible "disabled by default" at the end of December 2026, with a final permanent-removal date not yet announced (expected H2 2027). Sage's own KB attributes this exact error to "Microsoft's new changes to its basic authentication process" affecting webmail accounts, and recommends migrating to modern authentication now, ahead of that change.
  • Wrong port / TLS mismatch. The client is set to implicit TLS on a STARTTLS port (or vice versa), so the handshake fails. Per RFC 8314, both 587 (STARTTLS) and 465 (implicit/SMTPS TLS) remain valid during the ongoing transition, but the RFC actually recommends preferring Implicit TLS (465) over STARTTLS (587) for new or updated clients; 465 is not deprecated.
  • Port 25 (or 465/587) blocked. Many ISPs and firewalls block outbound port 25, and antivirus/VPN/proxy software frequently blocks 465/587 — often right after a client update.
  • Incorrect server host or unreachable server. A typo in the SMTP hostname, a DNS failure, or the server being down/refusing connections.
  • Bad or expired credentials, or an account that is disabled or locked.

How do I fix "An unknown error occurred connecting to the SMTP server"?

Work from the most common cause outward:

  1. Use a modern credential, not your normal password.
  2. Gmail / Google Workspace: enable 2-Step Verification, then create an App Password (a 16-character code) and use that as your SMTP password, or switch to OAuth2. Do not look for "Less Secure Apps" — it no longer exists.
  3. Outlook.com / Microsoft 365: app passwords and Basic Auth for SMTP AUTH still work today, but they're being retired — admin-reversible "disabled by default" lands at the end of 2026, with full removal to follow (date not yet set). Switch to OAuth2 / modern authentication proactively rather than waiting for the cutover. For Sage 50 specifically, Sage recommends switching from webmail to a default desktop email program (Classic Outlook — not New Outlook) via Setup > Settings > Company > Email.

  4. Verify host, port, and encryption match your provider's docs. Common correct combos:
  5. smtp.gmail.com — port 587 with STARTTLS, or port 465 with SSL/TLS.
  6. smtp-mail.outlook.com — port 587 with STARTTLS.
  7. Make sure the client's "SSL/TLS" vs "STARTTLS" setting matches the port; a mismatch breaks the handshake before login.

  8. Open the ports in your firewall/antivirus. Allow outbound 25, 465, and 587 and add the SMTP host to the trusted/allow list. As a test, briefly disable antivirus/VPN/proxy and resend; if it works, allowlist the client instead of leaving protection off. After a client update, remove and re-add the app to the trusted list.

  9. Confirm reachability. From the sending machine, test the connection directly — e.g. openssl s_client -connect smtp.gmail.com:465 (implicit TLS) or openssl s_client -starttls smtp -connect smtp.gmail.com:587. A clean TLS banner rules out network/DNS/firewall problems and points you back at credentials.

  10. Confirm the account is active and the password hasn't expired or been reset.

If you are sending through a notifications platform like Courier, you configure the SMTP host, port, encryption, and credentials once in the provider settings — the same checklist applies, but you only fix it in one place rather than per-client.

FAQ

Common questions

No. It is not an RFC 5321 reply code or an RFC 3463 enhanced status code. It is a generic message produced by the sending application (commonly Sage 50, Outlook, or Thunderbird) when the TCP, TLS, or authentication step fails before the server returns a specific code.

One API, every provider

Stop debugging raw provider errors

Courier connects to your email, SMS, and push providers, handles retries and failover, and surfaces delivery errors in plain language.

Last reviewed Jul 1, 2026. Courier is not affiliated with third-party providers; error behavior may vary by implementation.