Mac Mail, Two Accounts, One VPN Rule That Cannot Split Them

Mail opens, the work inbox syncs, and the personal one starts timing out. Or both sync, but the work server only answers while a tunnel is up, and Mail has no idea which account is which. The symptom always has the same shape: one application, two accounts, and a rule that identifies the application. Fixing it starts by admitting that the application is a container, not a boundary.

Three selectors are in play here, and they are not interchangeable. One is the process making the connection, another is the host it reaches, and the third is the identity used to sign in over that host. Whichever of those your policy can name is the boundary you can actually build.

Why the application is the wrong unit

Mail is a single process serving every configured account. A rule written against the application captures all of its connections, so the personal account inherits the work tunnel and its default route. That may be acceptable, but it is a decision, not a side effect you can leave unexamined.

Check what the user actually complains about before fixing anything. A mailbox that syncs but cannot send usually points at the submission server rather than the inbox, and both may live at different addresses inside the same private range. Ask whether the failure is receiving, sending or both. The answer decides which endpoint your rule has to cover, and it saves a round trip with whoever administers the server.

When the two accounts use different servers

If work mail talks to a host inside the corporate range and personal mail talks to a public provider, a destination-based arrangement can express the requirement. It needs the real addresses of the mail servers, the DNS that resolves them, and any submission or authentication endpoints that ride along with the same service. Gather all three before writing policy, because a rule that covers only the inbox will fail on the first send.

Use addresses, not the part after the @ sign. A domain in a mail address is not a routing statement, and treating it as one produces a rule that fires for the wrong host or never fires at all. Confirm the actual endpoints from the account settings or from the administrator.

When both accounts share one server

Two accounts on the same host address defeat destination-based selection completely. A route to that address serves whoever connects, and it cannot inspect which mailbox signs in afterwards. Moving the route moves the path for both accounts, which is exactly the outcome the user was trying to avoid.

At that point the honest options are an account-aware policy if the platform and client support one, a separate approved mail client for the work account so the application boundary becomes real, or accepting that both accounts travel together. Pick one deliberately and say which you picked.

Triggering a tunnel is not the same as covering it

Apple's App Layer VPN payload documents a MailDomains setting: listed domains cause Mail to trigger a VPN connection on supported managed deployments. That is a useful capability, and it is narrower than it sounds. It starts the tunnel when Mail talks to those domains; it does not describe every route, every app association or what happens while the tunnel is down.

It is also a managed feature, not a per-account checkbox in the Mail interface. If the deployment is not managed, the setting is not available to you, and no amount of profile editing will produce it.

Test with a fresh sync, not a cached inbox

The acceptance test is a fresh synchronization for each account under the intended policy, plus the unavailable state for the protected one. A cached inbox proves nothing about the next request, and a connected VPN icon says only that some tunnel exists.

Give the administrator the work account's endpoints and the behaviour you want for personal mail, then ask which supported account-aware, domain-based or application policy implements it. Watching the two accounts sync under each condition is the only evidence that the boundary you designed is the boundary the machine enforces.