macOS
macOS Mail stops fetching new messages only when connected to corporate VPN with split DNS
troublesync_editorial
1w ago
Environment
Environment
MacBook Pro 2019 running macOS 12.6.5, Apple Mail 14.0, corporate VPN (IKEv2) provided by company ASA gateway; split-DNS pushes internal DNS suffix and internal resolver 10.8.0.2 over tunnel; normal Wi‑Fi (home/coffee) and cellular tethering behave differently
Symptoms
Symptoms
When connected to corporate VPN over Wi‑Fi, Apple Mail shows 'No new messages' and does not poll IMAP accounts. Mail app idle for hours; other apps (Safari, Terminal) can resolve external hostnames normally. When VPN disconnected, Mail immediately shows queued new messages.
Observations
Observations
- Terminal: nslookup/mailserver.example.com resolves to internal IP only while VPN is active (10.10.11.5). - ping to mailserver internal IP times out or shows high packet loss only from Mail; curl to IMAP port (tcp/993) to that IP from Terminal succeeds and returns TLS banner. - Console logs show repeated MailKit network errors referencing 'socket hang up' and 'kCFErrorDomainCFNetwork' timestamps matching attempted fetches. - When VPN is active, other clients on same Mac (Thunderbird) can connect to same IMAP server using same settings and fetch email successfully.
Already attempted
Already attempted
- Rebooted Mac and reconnected VPN. - Flushed DNS cache (sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder). - Disabled 'Use system proxy' in Mail (not applicable). - Created a new Mail account profile (same credentials) — same behavior. - Tested IMAP via openssl s_client and curl from Terminal (works). - Disabled 'Automatic proxy discovery' and toggled Wi‑Fi. - Contacted VPN admin: confirmed split-DNS pushes internal resolver and internal route for 10.10.11.0/24. No server-side blocking reported.
Question
Question
Why does Apple Mail fail to fetch from the internal IMAP server only when the corporate VPN with split-DNS is active, while Terminal tools and other mail clients can connect successfully? What reversible diagnostics and fixes can I try that do not expose credentials or require server-side changes?
COMMUNITY RESPONSES
Verified community troubleshooting
0 replies
No answers yet..
Showing 0 of 0 community responses
AI DIAGNOSTICS
Incident analysis
Most likely causes
VPN client installs Network Extension or content filter that blocks or intercepts background socket calls from Mail but allows interactive Terminal clients 75%
Per-app VPN or proxy-policy on the gateway prevents traffic from Apple's Mail process (com.apple.mail) while allowing other user agents 30%
Split-DNS returns internal hostname resolving to internal IP that is reachable only via a specific route; Mail's background sockets may be created before route/DNS update completes, leading to persistent cached failure 25%
Summary
Symptoms point to an application-level network-resolution or socket-routing mismatch when the system resolver returns an internal IP over the VPN. Terminal tools using the system resolver work which suggests the internal IP and route are reachable. The Mail app likely uses a DNS/connection path that ends up routed differently (for example, preferring IPv6, hitting a local proxy, or using cached negative entries via the OS resolver), or Mail's background connection is being blocked by the VPN client or per-app firewall (Network Extension) when using the system network service. The fact other mail clients succeed indicates a Mail-specific interaction with macOS networking (CFNetwork) or app entitlements/Network Extension policies pushed by the VPN.
Suggested Fixes
Diagnostic step 1
Capture Mail network traffic without exposing credentials: use tcpdump to capture IP/port/connect attempts to the IMAP server while reproducing the failure (sudo tcpdump -i <iface> host <mail-ip> and port 993) and inspect whether connections are attempted and whether TCP handshake succeeds
Diagnostic step 2
Start Apple Mail from Terminal with Console logging enabled: open Console.app → start a system log session; then launch Mail from Terminal (open -a Mail) and reproduce; collect CFNetwork logs shown in Console for clues
Diagnostic step 3
Temporarily test Mail against the mail server over an SSH SOCKS proxy to bypass VPN resolver: ssh -D 1080 user@bastion and configure a test Mail account to use localhost:1080 as SOCKS (or use network.proxy.socks in a test client) to see if behavior changes (do not put production credentials in logs)