Email Not Sending Over VPN: SMTP and IP Restrictions

Your VPN is connected, the inbox refreshes, new messages arrive, and then you press send and nothing happens. The message sits in the outbox, a red warning appears, or the app says it cannot connect to the outgoing server. When you disconnect the VPN, it goes through straight away. This is a very common pattern, and it is not a sign that your email or your VPN is broken. It is a sign that outgoing mail is treated differently from incoming mail.

This article explains why, in plain language. It covers the ports that mail uses, the ways networks and providers restrict sending, what a shared VPN address can mean for a mail provider's checks, how to read the error messages, and a step-by-step approach that fixes most cases without trial and error. It stays on legitimate use: sending your own mail from your own account. It will not help you send bulk mail, avoid a provider's rules or get around a block that someone placed on purpose.

Why sending is different from receiving

Email has two jobs, and they use different systems. Receiving means your app asks the mail server for new messages, using a protocol such as IMAP or POP. Sending means your app hands a message to an outgoing server using SMTP, and that server delivers it onward to the recipient's server. They are separate servers, they often sit behind different hostnames, and they listen on different ports.

The two directions also carry different risks. Anyone can try to use an open outgoing mail server to send junk. For decades, networks and providers have therefore been much stricter about outgoing mail than incoming mail. They watch which addresses connect, which ports are used, whether the user has signed in, and how many messages are sent. A setup that triggers none of these checks over your normal connection can trigger one when a VPN changes the path.

That explains the classic symptom: the inbox works, sending fails. The inbox only needs the retrieval connection to succeed. Sending needs the extra permission to use the outgoing server, and that is where restrictions live.

Cause 1: the outgoing port is blocked

Mail submission uses a handful of ports. Knowing which is which helps you read your settings:

Port	Purpose	Notes
25	Server-to-server mail delivery	Not meant for ordinary mail apps. Widely blocked on home, mobile, hotel and many cloud networks.
587	Mail submission, usually with STARTTLS	The usual choice for mail apps. Requires signing in.
465	Mail submission over TLS from the start	Also common and accepted by many providers.
2525	Alternative submission port offered by some providers	Not universal; use only if your provider documents it.

A frequent cause of failed sending is a mail app still configured to use port 25, or an old setup with encryption turned off. That may have worked on one network and stopped on another. Port 25 is the most blocked mail port, and many VPN servers and hotel networks stop it to cut down on abuse. If your settings show 25, replace them with the submission port and encryption type published on your mail provider's help page. Encryption on mail connections relies on the same technology as secure web browsing, described in the TLS 1.3 specification.

The tell-tale sign of a blocked port is a timeout with no error code. The app waits, then says it cannot connect to the outgoing server. Nothing refused you, because nothing answered at all.

Cause 2: the provider does not trust the address

When you sign in to your mail account, the provider sees the internet address you connect from. With a VPN on, that address belongs to the VPN service, and it may be shared by many people at the same time. Mail providers pay close attention to this, because their abuse systems judge addresses by their history. An address that other people have used badly can be treated with suspicion even though you did nothing wrong.

What you may see:

• A sign-in challenge. The provider asks you to confirm it is really you, by code or message, because the address is unfamiliar. Complete it normally.
• A temporary limit. Sending is paused for a while, or capped to a small number of messages until trust is restored.
• A refusal with a code. You may see 535 (authentication refused), 550 or 554 (message rejected) with wording about policy or the connecting address.
• Messages delivered to spam. This is separate from your provider's decision. Recipients' systems sometimes look at the headers and pay attention to how a message was submitted.

Nothing here is a bug in your VPN, and it is not something you should try to hide from your provider. If your provider asks for verification, give it. Turn on strong sign-in protection for your mailbox, such as two-step verification, which the CISA guide to multifactor authentication explains. A mailbox that uses it is less likely to be locked when an unfamiliar address appears.

To read how an address is seen by the outside world, see the article on what a public IP address is.

Cause 3: your mail app uses a stale or wrong setup

Sometimes the VPN only exposes a mistake that was already there. Check these in the account settings of your mail app:

• Outgoing server name. It must match what your provider publishes. Typos and old names are common after a provider migrates.
• Authentication for sending. Many apps have a switch that says the outgoing server requires a login. If it is off, the server refuses you.
• Same username and password for sending. Some providers want the full email address as the username, not only the name before the at sign.
• App-specific passwords. Providers that use two-step verification often need a separate app password in a third-party mail app. The normal account password is rejected with a 535 error.
• Encryption type. STARTTLS on 587 and TLS on 465 are not interchangeable. A mismatch looks like a connection failure.

These problems can hide for months, because on your home network a lenient path let the app get through. Fixing the setup is a better answer than turning off the VPN for ever.

Cause 4: a company or school mail server limits where you can sign in

Work and university mail systems are more restrictive still. Some only accept sign-ins from the organisation's own network, or from named locations, or they require you to use the organisation's approved connection. If you use a personal VPN on top of that, the mail system may reject you as an unexpected location. That is a policy, not a fault. Ask the IT team how to connect from outside, and follow their instructions instead of trying to get around the rule. The article about using a VPN for remote work explains how personal and company connections relate.

A step-by-step approach

Work through these in order and stop when sending works.

1. Confirm the failure is about sending. Receive a test message. Then send one to yourself from the webmail page in a browser. If webmail sends fine with the VPN on, your account and the VPN path are healthy and the mail app is the problem.
2. Look at the exact message. A timeout means a port problem. A 535 means a sign-in problem. A 5xx rejection with a policy sentence means a trust or content problem.
3. Check the outgoing server settings against your provider's help page: server name, port, encryption and the requirement to sign in.
4. Switch to port 587 with STARTTLS or 465 with TLS, whichever your provider documents. Avoid 25 for ordinary sending.
5. Create an app password if your provider uses two-step verification and you are in a third-party app.
6. Complete any security prompt from your provider and wait a short while if it announces a temporary limit.
7. Test with the VPN briefly off to confirm the VPN path is involved. If it works only with the VPN off, move to the next step.
8. Change the connection method or location in the VPN app, if it offers one, and test again. A different path may be treated differently by your provider.
9. Use split tunneling, if your app offers it, so the mail app uses your normal connection while the rest stays in the tunnel. The explainer on split tunneling describes the idea and its trade-offs.
10. Contact your mail provider with the error text, the time and the settings you tried.

Keep a note of what you change. That way you can undo any one step.

Worked scenarios

The freelancer in a cafe. Inès connects to cafe Wi-Fi, switches on the VPN and tries to send an invoice from her mail app. The message sits in the outbox. Her app uses port 25 from an old setup. She changes the outgoing port to 587 with STARTTLS as her provider recommends, and the invoice goes out. The cafe's network and the VPN both stop port 25 and her old setup had only worked at home.

The employee on a hotel network. Kofi's work mail sends fine in the office but fails on the road with a "sign-in not allowed" error. Webmail works. The company mail system only accepts the mail app from approved locations. He asks IT, who give him the company's own approved connection. He uses that instead.

The traveller with a security code. Anh turns on a VPN abroad, and her provider sends a code to confirm the new location. She enters it, and sending resumes. The next day, a second prompt appears after she changes the VPN location, and she completes that one too. Frequent location changes produce frequent prompts, so she keeps one location per trip.

The parent with a school account. A school parent portal sends confirmations over a mail app that stopped working with the VPN. Webmail works. Fixing the mail app's outgoing authentication setting solves it without touching the VPN.

Common mistakes

• Keeping the VPN off for everything. Fix the mail setup, or use split tunneling, instead of dropping protection on a public network.
• Using port 25 for a mail app. It is built for server-to-server delivery and is blocked on many networks.
• Using the normal password where an app password is required. The 535 error looks like a wrong password because that is how it is reported.
• Changing VPN locations repeatedly. Each new address can trigger a new check.
• Re-adding the account over and over. It rarely helps and can create duplicates and lockouts.
• Treating a block as something to defeat. If a provider or an employer limits sign-ins, work with them.

Limits of this advice

Mail systems differ widely and update their rules often. A port that works today may be restricted tomorrow, and a provider's trust decisions are not visible to you. This article cannot promise that any change will fix your case, and it cannot see what your provider sees. If everything is configured as documented and you still cannot send, the provider's support team is the right place to go, ideally with the exact error text and time. For broader checks on a tunnel that connects but misbehaves, see websites not working with a VPN and VPN connected but no internet.

Summary

When email will not send over a VPN while receiving works, the problem is nearly always in the outgoing path: a blocked or wrong SMTP port, a missing sign-in or app password, an address the provider does not yet trust, or an organisation's sign-in policy. Read the error to tell timeouts from sign-in refusals from rejections, use the submission port your provider documents, complete verification prompts, and try the VPN briefly off only as a test. If you want a pass to test your mail setup on a new network, the pricing page lists the options and the download page has the official VPNclient apps.