SMTP "101" is not a server reply - it is a client-side connection error

101 is not an SMTP reply code at all. SMTP replies are always three digits starting with 2, 3, 4 or 5 (success, intermediate, temporary failure, permanent failure), and they come from the server after a connection is established. "101" does not fit that pattern and is not generated by any mail server. It is a client-side error number - most commonly seen in older Outlook builds and some third-party mail clients - that represents a failure to even open a TCP connection to the mail server in the first place. There is no SMTP transcript behind it, because no SMTP session ever started.

Who is at fault

This is a network or client configuration fault on the sending side, before SMTP even begins. Typical causes: the wrong server hostname or port configured in the client, a firewall or ISP blocking outbound port 25/587, the mail server being down or unreachable, or a DNS resolution failure for the server hostname. On corporate networks specifically, a captive portal or proxy intercepting outbound traffic can

also produce exactly this symptom - the TCP connection appears to succeed to the client's own

operating system, but the actual mail server never sees the connection attempt because a

network appliance intercepted it first. If telnet to the mail server's port times out from a

corporate or VPN-connected network but succeeds from an unrestricted connection, suspect network

interception rather than a client or server configuration issue, and involve the local network

or IT team rather than continuing to adjust mail client settings.

What actually happens (no SMTP exchange exists)

Because the failure is at the TCP layer, there is no MAIL FROM/RCPT TO/DATA transcript to show - the connection attempt itself fails before any SMTP command is sent. The honest representation of this event is a failed TCP handshake:

$ telnet smtp.yourprovider.com 587
Trying 203.0.113.25...
telnet: Unable to connect to remote host: Connection timed out

How Gmail, Microsoft 365 and Yahoo "word" this condition

Since this is not a server reply at all, no provider wording applies - the receiving server was never reached. The closest equivalent is each provider's documented port/hostname requirements, which is where to check your client's settings:

Diagnostic commands

$ nslookup smtp.yourprovider.com
smtp.yourprovider.com  canonical name = smtp-relay.example.net.
Address: 203.0.113.25

$ telnet smtp.yourprovider.com 587
Trying 203.0.113.25...
Connected to smtp.yourprovider.com.
220 smtp.yourprovider.com ESMTP ready

$ traceroute smtp.yourprovider.com

If nslookup resolves correctly but telnet cannot connect, the problem is a firewall, blocked port, or the server itself being down - not DNS. If nslookup fails outright, fix DNS resolution first.

The ordered fix

1. Confirm the hostname and port configured in your client match your provider's documented submission settings exactly.
2. Test raw connectivity with `telnet` on the configured port, independent of your mail client, to isolate whether this is a client bug or a network issue.
3. Check for a local firewall or antivirus blocking outbound SMTP ports - common on corporate or heavily locked-down machines.
4. Check with your ISP whether outbound port 25 (less commonly 587) is blocked, which many consumer ISPs do by default to curb spam.
5. If all of the above check out, confirm the mail server itself is actually up and not undergoing maintenance.

What not to do

• Do not search for "SMTP reply code 101." It is not documented anywhere a server would publish, because no server sends it.
• Do not treat this as a deliverability or reputation problem. No message ever reached any recipient server; there is nothing to diagnose about content, authentication, or reputation here.
• Do not keep retrying the send from the same client without testing raw connectivity first. If the TCP connection itself is failing, retrying the mail client's send button will reproduce the same failure every time.
• Do not assume the recipient or your domain's DNS records are the cause. The failure is entirely local to your outbound connection attempt.

Separating this from a provider-side outage

Before assuming a local misconfiguration, rule out the simplest alternative: check the provider's

public status page for an active incident affecting SMTP submission. A provider-wide outage will

produce the identical symptom - no connection, no reply, a client-side timeout number like 101 -

and no amount of adjusting your own firewall or DNS settings will fix a problem that is not on

your end at all. Five minutes checking a status page before auditing your own network saves

considerable wasted troubleshooting time.

MailPilot connects to each provider's documented submission endpoints over the correct port and protocol for every mailbox it manages, which removes this category of client-side connectivity misconfiguration entirely for warm-up and monitored sending.