Mail Submission Fails When the VPN Connects: Find the Stage

Mail that worked all morning stops the moment the tunnel comes up, and the first instinct is to retype the password. That instinct skips the more useful question: did the client reach the server at all, and did it get far enough to offer credentials? A timeout, a certificate error and a rejection reply are three different failures, and only the third involves the account. Work through the stages in order and the VPN becomes a variable you can test rather than a suspect you blame.

Step 1: classify the failure before touching credentials

Read the error the application actually produced, then place it in one of three buckets. A timeout or connection reset means the TCP path failed; a TLS or certificate error means the path worked and the handshake did not; an SMTP reply with a code means a mail server answered and made a decision. Each bucket points at a different owner.

The buckets are worth separating because the fixes contradict each other. Extending a timeout helps nothing when the server rejects the sender, and changing a password does nothing when the route is black-holed. A reply code is the most valuable evidence in the list, because it proves the whole transport chain worked and the problem is policy or identity. Save the exact text, including any enhanced status code, before you retry.

Stop here if you cannot reproduce the failure outside the VPN. A problem that appears in one application on one machine is not yet a network problem.

Step 2: confirm the endpoint and the TLS mode

Message submission is its own service, not the same thing as server-to-server relay. Confirm the hostname, the port and the TLS mode from the provider's documentation for submission, because a familiar port borrowed from another mail setup is not evidence. Port 587 expects a plaintext greeting followed by STARTTLS, while port 465 expects TLS from the first byte.

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -quiet
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -quiet
nc -vz smtp.example.com 587

Running the wrong one of those two probes is exactly the mistake the client makes when it is configured for the other mode. If the implicit-TLS probe hangs on 587, or the STARTTLS probe fails on 465, the port and the mode disagree. Fix the mode in the client instead of disabling certificate verification, which converts a configuration error into an unverified connection. The split is old enough to be standardised: implicit TLS on port 465 is the arrangement described in RFC 8314.

A certificate error here is information rather than an obstacle. It names the identity the server presented and the identity the client expected, and both are fixable without weakening the connection.

Step 3: compare paths without changing the account

Hold the endpoint, account and client settings constant and change only the path. Send once with the tunnel down and once with it up, and record the route and the source address the server would see. If the failure follows the path, you have isolated it; if it follows the machine, you have not.

ip route get smtp.example.com
curl -v --ssl-reqd --url smtp://smtp.example.com:587 --user "$SMTP_USER" \
  --mail-from [email protected] --mail-rcpt [email protected] --upload-file msg.txt

A full tunnel changes the source address the provider sees, and some providers treat an unfamiliar source more strictly than an unfamiliar password. That is a policy decision on their side, and it may be a greylist, a rate limit or a block. Do not generalise from one provider to all of them, and do not assume a missing NAT rule explains every failure. The curl transcript shows which stage failed even when the application's own log does not.

If the tunnel is supposed to carry internet traffic, its routing and its egress policy both have to allow this destination. A tunnel that carries only private routes leaves the mail connection on the local path, which is a different comparison.

Step 4: send one harmless message and record the reply

Correct the stage that failed, then submit one harmless message through the same application rather than through a webmail page. The application's own send path is what you are testing, including its stored settings and its TLS mode. A webmail session proves nothing about it.

Record the reply, the port, the TLS mode and the path you used, so the next person can reproduce the result. A working browser and a green VPN icon are observations about other things. If the message arrives, the remaining work is to make that configuration the default for every machine that sends through this account.

The checklist is complete when you can name the stage that failed, the port and TLS mode the client uses, the path the message took, and the reply the server returned. Those four facts turn a vague outbox problem into a change someone can review.