SMTP Errors 0x800CCC78 and 0x800CCC79: Outlook Cannot Send, Server Rejects Address

Fix it now

These are send-side rejections. Outlook connected to the outgoing server, began the transaction, and the server refused either the address you are sending from or the address you are sending to. Receiving keeps working throughout, which is why it looks like an Outlook fault when it is a decision taken on the server.

Test-NetConnection smtp.office365.com -Port 587

1. Switch on outgoing authentication. In the account’s More Settings, on the Outgoing Server tab, tick the box requiring authentication and leave it using the same settings as the incoming server unless the provider documents otherwise.
2. Check the outgoing port and encryption. Microsoft’s own guidance for client submission to Microsoft 365 is smtp.office365.com on port 587 with TLS, and port 25 is also accepted there – but 587 is the one to use.
3. Read the address the account sends from and confirm it is the mailbox’s own primary address rather than an alias or a departmental address you have not been granted.
4. Send one test to an external address and one to an internal address. Which of the two fails tells you whether the sender or the recipient is being refused.

If webmail sends the same message without complaint, the difference is in Outlook’s outgoing settings rather than in the server’s rules – so compare those settings against the provider’s documentation field by field.

If the message reaches Sent Items rather than sitting in the Outbox, you are done. If not, the next section explains what the server is actually refusing.

Why it happens

Microsoft publishes no meaning for 0x800CCC78, 0x800CCC79, 0x800CCC7A, 0x800CCC7B or 0x800CCC69. The neat mapping you will find elsewhere – this one is the sender, that one is the recipient – is inference from where they tend to appear. Fortunately the underlying behaviour is documented in the SMTP world generally and by mail providers specifically, and it is more useful than the codes are.

An SMTP conversation runs in a fixed order: the server greets, the client identifies itself, encryption is optionally negotiated, authentication optionally happens, the client declares who the message is from, then who it is for, then sends the message. A rejection is the server saying no at one of those steps, and there are only two it is likely to be – the sender declaration or the recipient declaration.

Relaying is the heart of it. A mail server accepts messages addressed to domains it is responsible for from more or less anyone, because that is how it receives mail. It accepts messages addressed to other domains only from senders it trusts, because anything else is an open relay that will be abused within hours. If Outlook has not authenticated, sending to an outside address is relaying and gets refused. That is not a broken client; it is a correctly configured server declining.

Sender identity is the other half. Many hosts insist the declared sending address is the authenticated mailbox or one of its permitted aliases, partly to stop abuse and partly because published sender policies make mail from a mismatched address unlikely to be delivered anyway. Typing a departmental address into the account settings does not grant permission to use it; that permission is granted on the server, by an administrator.

Full reference

Which address is being refused

Submission settings you can check against a source

Use 587. Port 25 works for client submission to Microsoft 365, so the common advice that it is simply wrong is overstated – but it is the port most likely to be blocked or redirected by whatever network the machine happens to be on, which makes it the port most likely to produce an intermittent, location-dependent fault that costs an afternoon to characterise.

Getting send-as right

1. Establish whose address it actually is: a shared mailbox, a distribution address, or a person who has left.
2. Ask the administrator to grant send-as permission on that mailbox to the account that needs it.
3. Leave the account’s own address alone in the account settings.
4. Turn on the From field in a new message and choose the granted address there, per message.
5. Confirm the sent copy lands somewhere sensible; where it goes depends on how the mailbox and the permission are configured, and it is better to find that out on a test than on something that matters.

When the message is stuck in the Outbox

• Move it to Drafts. A failing message retries on every send and receive cycle, and repeated failed submissions can trip rate limits at the provider.
• Recreate it as a new message rather than editing the failed copy, which can carry the same bad recipient with it.
• Check for an unusually long recipient list, or an attachment type a gateway is likely to reject outright.
• Send a plain one-line message to yourself to confirm the account is working at all before you retry the difficult one.
• Check Sent Items rather than watching the Outbox empty; an item that disappears from the Outbox without arriving in Sent Items has not been accepted.

Codes, honestly

None of the five codes here is documented by Microsoft, so treat them as labels for where you were rather than as instructions. The diagnostic that actually works is the pair of test messages: one internal, one external. If internal succeeds and external fails, it is relaying and therefore authentication. If both fail, it is the sending address. That test takes a minute and does not depend on anybody’s interpretation of a hexadecimal number.

Every code this article covers

Confirm the fix worked

1. A message to an external recipient leaves the Outbox and appears in Sent Items.
2. A message to an internal recipient does the same.
3. The Outbox is empty after a full send and receive cycle.
4. A message with an attachment also completes, so the transfer stage is exercised rather than only the handshake.
5. The same tests pass from a different network, which confirms the fix is in the settings rather than in the route.

Questions people ask about this