SMTP Error 101

Is "SMTP Error 101" a real SMTP code?

No — and knowing this is the fastest path to fixing it. Genuine SMTP reply codes are always three digits in the 2xx–5xx range (for example 220, 421, 550), as defined in RFC 5321 §4.2. There is no 101 reply in the SMTP protocol.

The 101 you are seeing is an operating-system socket error, not a server response. On Linux, errno 101 is ENETUNREACH — "Network is unreachable" (defined in the kernel's asm-generic/errno.h and the glibc error-code list). Your mail library tried to open a TCP connection to the SMTP host and the kernel's routing-table lookup failed before a packet could even be sent — so the SMTP conversation never even started.

You'll typically see it wrapped in a client message such as:

SMTP ERROR: Failed to connect to server: Network is unreachable (101)
SMTP connect() failed.

OSError: [Errno 101] Network is unreachable

The first form is emitted by PHPMailer; the second by Python's smtplib/socket. Both are reporting the same OS-level connect() failure — the application has not received any SMTP banner or status code from the server.

What causes the "Network is unreachable (101)" error?

The connection failed before any SMTP handshake, because the kernel couldn't even find a route to send the packet on. Real, specific causes:

• No route to the destination network. The host has no default gateway, or routing to the provider's IP range is broken. This is the literal meaning of ENETUNREACH.
• IPv6-only resolution with no IPv6 path. If the SMTP hostname resolves to an AAAA (IPv6) record but your machine or ISP has no working IPv6 route, the kernel returns ENETUNREACH. This is a frequent cause on cloud VMs and IPv6-misconfigured hosts.
• A down or misconfigured local network interface. A container or VM with a down interface, missing default route, or broken virtual network stack produces this immediately.
• Wrong host or unreachable IP. A misspelled smtp. hostname or an IP/subnet that doesn't exist routes to nowhere.

Note: 101 (ENETUNREACH, no local route) is distinct from 111 (ECONNREFUSED, the host is reachable and actively refused the port) and from 110/ETIMEDOUT (the packet was sent but silently dropped). This distinction matters in practice: outbound firewalls and hosting-provider port blocks — the most common real-world cause of SMTP connection failures on shared hosting and cloud VMs — almost always surface as 110/ETIMEDOUT or 111/ECONNREFUSED, not 101. A remote block doesn't stop your kernel from finding a route; it stops the packet (or its reply) somewhere downstream. If your actual symptom is a hang followed by a timeout, or an immediate "connection refused," you're looking at a port-blocking problem, not ENETUNREACH — see the related articles on error 110 and error 111 below. Error 101's wording ("unreachable") points specifically at your local routing table, interface, or DNS resolution — not at the remote server's or a firewall's response.

How do I fix "SMTP Error 101"?

Work from the local network outward — most fixes are routing/interface changes, not SMTP-config or firewall changes:

1. Confirm it's a routing issue, not a block or auth problem. From the sending machine, test the route and port directly:

# Can you even route to the host?
ping smtp.yourprovider.com
# Can you open the SMTP port? (use the port you configured)
nc -vz smtp.yourprovider.com 587
openssl s_client -starttls smtp -connect smtp.yourprovider.com:587

If these hang and then time out, or return "connection refused," that's 110/111 territory (likely a firewall or port block), not 101. A genuine 101/ENETUNREACH usually fails immediately with "Network is unreachable" rather than hanging.

2. Check your routing table and default gateway. Run ip route (or route -n) and confirm a default route exists and points to a live gateway. A missing or stale default route is the most direct cause of ENETUNREACH.

3. Fix IPv6 or force IPv4 if IPv6 is broken. If the host resolves to an IPv6 (AAAA) address but your machine or network has no IPv6 route, either repair IPv6 connectivity or force IPv4 (e.g. connect by an IPv4 address, or in code bind/resolve to IPv4 explicitly).

4. Verify the host and port are correct. Cross-check against your provider's official SMTP docs (host spelling, port number) — a misspelled hostname can resolve to nothing routable.

5. If the socket connects but you still can't send, look elsewhere. Once the socket connects, a real SMTP code (e.g. 220, 535) will appear — that's an auth or protocol issue, not error 101. And if you saw a timeout or an explicit refusal rather than an immediate "unreachable" failure, check whether an outbound firewall or hosting provider is blocking 465/587/25 (both 465 and 587 are valid per RFC 8314) — that's the 110/111 fix path, not this one. If you're using Gmail/Google Workspace, note that "Less Secure Apps" was removed in 2022 — use an App Password (with 2-Step Verification enabled) or OAuth2.

If you're sending through Courier, you don't manage sockets, routing, or interfaces yourself — Courier connects to the provider for you, so a raw (101) from your own infrastructure usually means the failure is in your local environment's network configuration, not in the delivery layer.