Mail spinning after a VPN switch: resync or re-download?
A busy Mail window after a network change is not proof of a re-download. Read the account status, then choose between resync, login fault and VPN path.
When a network change wakes Mail up and the progress indicator starts moving, that is the moment people conclude the VPN has forced a full re-download. It usually has not. Reconnecting triggers a synchronization pass, and a synchronization pass covers mailbox state, flags and message metadata long before it covers message bodies. The useful decision is which of three stories you are in, and only the account's own status can tell you.
One busy indicator, three different stories
The three candidates are a normal resync, a login or authentication failure that keeps retrying, and a path problem where Mail cannot reach the server through the new network at all. They look similar from a distance because all three animate the same window, and they call for three different actions.
| What you observe | Most likely story | Where to look next |
|---|---|---|
| Brief activity that settles, mail arrives | Normal resync | Nothing to fix |
| Status says login failed | Mail account or provider authentication | The account and its provider settings |
| Status says offline or cannot contact server | Path through the new network | The VPN, proxy or filter in the way |
| Activity never settles, no new mail | Retry loop against a blocked or wrong endpoint | The exact status text and the destination |
That table is the whole decision. It also explains why "it is downloading again" is a description of the window rather than a diagnosis of the fault, and why changing a VPN setting in response to a login failure rarely helps.
Read the account status before interpreting anything
Look for the status indicator beside the affected account or inside the Mail window, and open it so the exact message is visible. Apple's send-and-receive guidance separates connection trouble, login failures, service availability and account limits, and those four categories lead to four different owners. Retyping a password for a service-availability message wastes the same afternoon twice.
Keep the test narrow: a single account, a single fresh operation that shares nothing sensitive, all of it through the path you intend it to use. A cached inbox can stay fully visible while current synchronization fails, which makes "I can see my mail" a poor test of whether anything is arriving. Write down the exact status text before you change a setting, because that sentence is the only evidence you will have afterwards. The version you remember five minutes later is always vaguer than the one on screen.
The Mac has internet, but Mail says offline
When everything else on the machine works and Mail reports offline, the interesting question is which path the connection is being asked to take. A proxy setting, a network filter or a tunnel that only carries some traffic can leave Mail on a route the server will not answer on. Check what the system-level proxy configuration says before editing the account.
scutil --proxyThen separate the account from the path. Webmail proves the account works at the provider, but it proves nothing about the Mail app's configuration or the route the app uses, because a browser may take a completely different path with different proxy handling. Sending and receiving can also rely on different services, so one successful operation is not a complete test of the other.
Duplicates are a separate observation
Ongoing synchronization is not evidence that visible duplicates have been created, and duplicates that already exist are not evidence of what the VPN did. If you can actually see repeated copies, record that as its own finding and check the mailbox on the server side with the provider. That tells you whether the copies exist once and display twice, or genuinely exist twice.
Either way, deleting local mail, rebuilding every mailbox or removing accounts is a drastic first response to a progress counter. Those actions destroy the state you would have needed to diagnose the original question, and they are difficult to reverse on a machine holding mail that exists nowhere else.
Decide before you remove an account
If an approved recovery procedure really does require removing and re-adding the account, preserve the two things that cannot be fetched again: unsent work and any mail that exists nowhere but this machine. Complete whatever has to be submitted before a network change is scheduled rather than after it, then disconnect through the normal controls of whoever owns the VPN.
Finally, remember what the activity display is. It is an application observation about Mail's own work, not evidence that the VPN cannot be stopped or that the tunnel is responsible. The decision, in order, is: read the status, classify it against the table, test one operation through the intended path, and only then touch the account.