Send and receive errors — 0x800CCC0E, 0x8004210A, 0x800CCC0F
Mail stops moving and the send/receive dialog reports a connection error. These codes all mean the same class of thing — Outlook could not complete a conversation with the mail server — and the useful work is finding out which hop failed.
What you see
Mail sits in the outbox, or the send/receive progress window shows "Task reported error (0x800CCC0E)" or "The operation timed out waiting for a response". Webmail for the same account works, which is what tells you the mailbox itself is fine.
What is actually wrong
Four things produce these, in rough order of likelihood: security software intercepting the mail connection, the wrong port or encryption setting on a manually configured account, a network path that blocks the port outright, and a very large message stalling the connection until it times out. 0x800CCC13 is the odd one out and usually means damaged system files rather than a network problem.
Codes and articles
Start here — find out which fix applies
A script that runs the 3 inspection commands from the write-up below and prints what each one returned. It reads the machine and changes nothing — every command that could write, delete, start or stop is excluded from it by construction. Run this first, then pick the fix its output points at.
Fixes (4)
Clear a message that is jamming the queue
Check this before anything technical. One oversized message in the outbox stalls every send behind it and produces a timeout that looks exactly like a network fault.
Work offline first, so Outlook stops retrying while you are in the outbox. Send/Receive → Work Offline.
Without this, Outlook locks the message it is trying to send and you cannot delete or move it. This is why the outbox appears impossible to clear.
Open the Outbox and sort by size. Anything above about 20 MB is likely to be the problem — most mail systems reject or stall well below the limit they advertise.
Drag the oversized message to Drafts, remove the attachment, and send the attachment another way — a OneDrive or SharePoint link is the intended route.
Go back online and let the queue drain. Send/Receive → Work Offline again to toggle it off.
If the outbox still will not clear, check for a message with no recipient or a corrupted one, which sticks in the same way.
Rule out security software intercepting the connection
An Exchange or Microsoft 365 account that was working and stopped, especially after a security product was installed or updated.
Check whether the machine can reach the service at all.
Test-NetConnection outlook.office365.com -Port 443 | Select-Object ComputerName, RemoteAddress, TcpTestSucceededLook at what certificate is actually being presented. An interception proxy substitutes its own.
$c=[Net.Sockets.TcpClient]::new('outlook.office365.com',443)$s=[Net.Security.SslStream]::new($c.GetStream(),$false,{$true})$s.AuthenticateAsClient('outlook.office365.com')$s.RemoteCertificate.Issuer
If the issuer is Microsoft, the connection is reaching Microsoft. If it names your antivirus or a firewall vendor, the mail traffic is being decrypted and re-signed in transit — which is the single most common cause of these codes on an otherwise healthy machine.
Turn off the mail-scanning component specifically — not the whole product — and test. Most products have a separate "scan outgoing/incoming mail" or "SSL scanning" switch.
If that fixes it, add the Microsoft 365 endpoints to the product's exclusion list rather than leaving mail scanning off. Vendors publish these lists and Microsoft documents its own endpoints.
Re-enable everything you turned off, once the exclusion is in place.
Correct the server, port and encryption settings
A POP or IMAP account set up by hand, or an account that fails only when sending.
Confirm the machine can reach the SMTP port the account is configured for.
Test-NetConnection smtp.yourprovider.com -Port 587 | Select-Object RemoteAddress, TcpTestSucceededA failure here and not on 993 or 995 is why receiving works and sending does not. Many networks and most consumer ISPs block outbound port 25 to stop spam, so an account configured for 25 will receive perfectly and never send.
Open File → Account Settings → Account Settings → the account → Change → More Settings → Advanced, and compare against what the provider publishes. The usual current values are 993 with SSL/TLS for IMAP, 995 with SSL/TLS for POP, and 587 with STARTTLS for SMTP.
On the Outgoing Server tab, confirm "My outgoing server (SMTP) requires authentication" is ticked. An unauthenticated SMTP submission is refused by every current provider.
Raise the server timeout on the Advanced tab to 5 minutes if the connection is slow or the mailbox is large.
0x8004210A is literally a timeout. The default is one minute, which a slow link or a large first sync will exceed.
If the provider has moved to modern authentication, a manually configured POP or IMAP account with a plain password will now be refused regardless of ports. Remove it and let autodiscover set the account up instead.
Test the network path properly
Nothing above applies, or the fault follows the machine between networks — or does not.
Establish whether the network is the variable by testing on a different one — a phone hotspot is the quickest.
This one test splits the problem in half. Working on a hotspot and failing on the office network means the fault is the network, not Outlook, and everything you would have done to the client is wasted effort.
Check name resolution is returning something sensible.
Resolve-DnsName outlook.office365.com | Select-Object Name, Type, IP4Address -First 5Check whether a proxy is configured that mail traffic is being forced through.
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Select-Object ProxyEnable, ProxyServer, AutoConfigURLRun Microsoft's own connectivity test against the account, which checks the whole path from outside and reports which hop failed.
Start-Process 'https://testconnectivity.microsoft.com/'If the office network is the variable, take the findings to whoever runs the firewall. Mail inspection appliances and SSL-inspecting proxies are the usual cause and it is not fixable from the client.
Related faults
Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.