Mail reaches the server without VPN: where to enforce the rule

Mail keeps polling and the VPN is down, yet the account still syncs. The app is doing what it was configured to do; nothing in a normal mail profile says the server is reachable only through the tunnel. That leaves two different requirements, and they are easy to blur: the service should refuse direct clients, or the Mac should never make the attempt.

Pick the requirement before choosing a product. A server rule and a client rule fail in different places, produce different evidence and belong to different owners. Applying both is valid when both statements are true, but one is not a substitute for the other. Both requirements are legitimate; they are just not the same control.

The symptom looks like the Mac, but the server may be the leak

When mail syncs outside the tunnel, start with what the server accepts. If the mail listener answers a direct connection from the internet, no client-side convenience setting changes that fact. The Mac is behaving normally against a service that is still open.

Ask the mail administrator which source address the service sees. A VPN gateway, reverse proxy or load balancer can translate the client address, so the address pool in the VPN configuration may not match what arrives at the mail process. A rule written against the wrong source either blocks everyone or blocks no one.

That answer also tells you whether the service can distinguish VPN clients at all. If every client arrives through the same proxy address, source-based admission cannot separate them, and the requirement has to move to authentication or to the client side.

Server admission: refuse the source, not the app

A host or network firewall can restrict the mail listener to approved source ranges while leaving authentication and TLS unchanged. A rule condition that matches remote addresses, subnets or ranges is the usual building block; the exact syntax belongs to the server's firewall product, not to the mail application.

This is the strongest boundary when the requirement is "the service must not serve direct clients." It holds even if the user installs another mail client, because the refusal happens before authentication. It also survives a Mac that ignores its VPN policy.

Its limit is equally important. A rejected connection proves the service refused the session; it does not prove the Mac made no attempt. DNS resolution, a TCP SYN to an earlier load balancer and a retry after failure can all happen before the server's rule is reached. If the requirement is about disclosure of attempts rather than access, server admission is only half the control.

Client enforcement: block the attempt, not just the tunnel

A client-side rule has to forbid the traffic, not merely start a tunnel when mail is opened. An activation trigger for a mail domain can bring the VPN up at the right moment, but it does not define what happens while the tunnel is down or after it fails.

Use the endpoint product's supported blocking policy and scope it deliberately. An app-level rule covers every account in that mail application, including personal ones. A destination-level rule has to name the work account's IMAP, submission and authentication endpoints, and it has to keep working when those addresses change.

Cover both address families and existing sessions. A policy that blocks new IPv4 connections while leaving IPv6 or an established socket alone produces intermittent syncs that look random. Network changes and sleep cycles are part of the same test.

App-level and destination-level rules have different blast radius

An app-level block is simple to reason about: no traffic from Mail leaves without the tunnel. It is also blunt, because the same application may hold a personal account that has nothing to do with the policy. Users notice that first and report it as a broken mail app.

A destination-level block is narrower and harder to maintain. It needs the complete set of endpoints the account uses, including discovery and authentication services, and a process for updating them. Miss one and the account half-works; over-include and unrelated mail stops.

Choose by the requirement's wording. "This work account must not connect directly" points at destination scope. "This Mac must not run mail outside the VPN" justifies the broader app rule, provided the owner accepts the personal-account side effect.

Test refusal and absence separately

With a dedicated test account, connect through the VPN and confirm normal operation. Then disconnect and test twice: once to see whether the server refuses the login, and once to see whether the Mac attempts a connection at all. Those are different observations and they belong in different logs.

Watch the client-side evidence for a SYN or a DNS query while disconnected, and the server-side log for a rejected or accepted session. If the server refuses but the client still attempts, the server rule is working and the client rule is missing. If the client makes no attempt but the server still accepts other clients, the boundary is exactly where you placed it.

Record the enforcement owner, the source address the server actually sees, and the test account used. The next network or proxy change can move that source, and a note naming the observed value is faster to check than another round of guessing.