Exchange 2013, 2016, and 2019 Emails Stuck in Drafts: How to Troubleshoot

Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.

If a message stays in Drafts after you click Send, first check whether it also happens in Outlook on the web (OWA). If OWA sends successfully but Outlook desktop does not, investigate Outlook’s connection, profile, add-ins, or cached data. If OWA also leaves the message in Drafts, check mailbox submission and Exchange health. If Exchange has accepted the message, use its queue error and message-tracking events to follow the failure.

Do not treat Drafts, Outlook’s Outbox, and an Exchange transport queue as the same problem. Record the message details and test a small internal message before deleting or changing anything.

#	Preview	Product	Price
1		The Admin's Guide to Microsoft Exchange Server Subscription Edition	$42.93	Buy on Amazon
2		Microsoft Windows Server 2022 Standard | Base License with media and key | 16 Core	$359.99	Buy on Amazon
3		Mastering Microsoft Exchange Server 2016	$43.49	Buy on Amazon
4		Microsoft Exchange Server - Break Fix Guide for Administrators: Exchange Server: On-Premises &...	$8.57	Buy on Amazon
5		Microsoft® Exchange Server 2010 Administrator s Pocket Consultant	$25.59	Buy on Amazon

First identify where the message is stuck

Exchange’s Mailbox Transport Submission service retrieves mailbox messages and submits them to the Transport service, which categorizes and routes them. The Front End Transport service does not keep a local message queue. See Microsoft’s Exchange mail-flow overview.

Five-minute triage: compare OWA, Outlook, and recipient type

1. Preserve the evidence. Record the sender, recipients, subject, approximate size, attachment names and sizes, time of the attempted send, client, connection mode, and exact error. Do not delete the only copy yet.
2. Test in OWA. Open Outlook on the web, create a new message with no attachment, and send it to one internal recipient. Then try a second small message to an external recipient. Use a new message rather than relying on the original draft.
3. Compare the result. If OWA works and Outlook desktop fails, start with Outlook. If both fail, or multiple users are affected, investigate server-side submission and transport.
4. Check scope. Ask another user to test, ideally one on the same database and one on another server or database. Note whether the issue affects internal mail, external mail, shared mailboxes, or only mailboxes recently moved during a migration.
5. Capture the exact time and subject for any server-side search. A narrow time window makes message tracking more useful.

If Outlook on the web also leaves the message in Drafts

OWA removes most Outlook desktop and local OST causes, but it still depends on Exchange client access, mailbox submission, and server health. Start with a small new test message, then check whether the problem is specific to a mailbox, server, or destination.

#1 Best Overall

Sale

The Admin's Guide to Microsoft Exchange Server Subscription Edition

$42.93

Buy on Amazon

Check Exchange transport services

Run in the Exchange Management Shell on the relevant Mailbox server:

Get-Service MSExchangeTransport,MSExchangeFrontEndTransport,MSExchangeMailboxTransportSubmission,MSExchangeMailboxTransportDelivery |
    Select-Object Name,Status,StartType

Normally, the Transport, Mailbox Transport Submission, and Mailbox Transport Delivery services should be running. Front End Transport should normally be running where client or proxy transport depends on it. Confirm the actual service names and their state in the target Exchange version before taking action.

Capture queues, tracking, and relevant event-log details before restarting a service. A justified restart may clear a transient service fault, but it will not repair a broken connector, DNS, permission, limit, or certificate configuration—and it can obscure the timing and evidence of the original failure.

Run a mail-flow test

Test-Mailflow
Test-Mailflow -TargetEmailAddress [email protected]
Test-Mailflow -Identity EXCH01

Use the applicable form for your environment. Test-Mailflow tests submission, transport, and delivery and reports a result such as Success or FAILURE along with latency. A failed local test points toward server-side submission, mailbox transport, database, or transport problems. A successful internal test with failed external delivery points more toward the outbound route. A successful test does not rule out a one-user, delegated-sending, or single-message issue. See Microsoft’s Test-Mailflow documentation.

Check database, server, and disk health

• Confirm the affected mailbox database is mounted and available, and review DAG or database health where applicable.
• Review Application and System event logs for transport, mailbox, database, Active Directory, or disk errors around the failure time.
• Check Exchange Health Manager and transport-related events.
• Check free space on system, database, transaction-log, and transport queue volumes. Resource pressure can destabilize services; it is an operational check, not proof of a particular cause.
• Review recent cumulative or security updates, certificate changes, Windows changes, and antivirus or other security software that could lock queue or log files. Follow Microsoft’s Exchange antivirus guidance before changing exclusions.

Inspect queues before retrying messages

On the affected server, run:

Get-Queue |
    Format-Table Identity,Status,MessageCount,NextHopDomain,LastError -Auto

For a multi-server overview, run:

Get-QueueDigest |
    Format-Table Server,DeliveryType,NextHopDomain,Status,MessageCount -Auto

Get-Queue shows queues on the server where you run it. Get-QueueDigest aggregates queue information across servers and can lag by roughly one to two minutes by default, so use the specific server’s Get-Queue output for immediate investigation. Microsoft explains the queue types and statuses.

Rank #2

Sale

Microsoft Windows Server 2022 Standard | Base License with media and key | 16 Core

• Server 2022 Standard 16 Core

$359.99

Buy on Amazon

• Submission queue growing: messages have reached Transport but are waiting for processing.
• Status Retry: the last connection attempt failed. Read LastError and investigate the cause.
• Status Ready: the queue is available for delivery; it may still be waiting for processing or a delivery attempt.
• External next hop: investigate DNS, Send connector configuration, firewall access, TLS, smart-host authentication, and the remote server’s response.
• Internal mailbox delivery: investigate the target database, Mailbox Transport Delivery, database availability, and server-to-server routing.
• No queue entry: if OWA still shows the message in Drafts, it may never have reached Transport. Focus on mailbox submission, mailbox/database health, and service state.

Do not run Retry-Queue as a blind fix. Correct the underlying error first. If you have identified and corrected a known transient failure, copy the exact queue identity from Get-Queue and retry that queue deliberately. For example, the command form is Retry-Queue -Identity "<exact queue identity>" -Resubmit $false; do not substitute a guessed identity.

Trace whether Exchange received and handled the message

Search using the sender, recipient, server, and a narrow time range. Adjust the window and identities to match the recorded evidence:

Get-MessageTrackingLog `
  -Server EXCH01 `
  -Start (Get-Date).AddHours(-2) `
  -End (Get-Date) `
  -Sender [email protected] `
  -Recipients [email protected] |
  Select-Object Timestamp,EventId,Source,Sender,Recipients,MessageSubject,RecipientStatus

Exchange message tracking records activity as messages move through transport and mailbox services. Common events include SUBMIT, RECEIVE, SEND, DELIVER, FAIL, DEFER, and DROP. Interpret the sequence and recipient status, not just the presence of one event:

1. No matching record: the message may not have reached Transport, or the search may use the wrong server, time range, sender, or recipient. Verify the search scope before concluding.
2. SUBMIT but no later progress: investigate categorization, mailbox transport, service health, and related queue or event errors.
3. DEFER or FAIL: use the event details and recipient status to identify the specific failure.
4. SEND: Exchange handed the message to the next hop. If the recipient has no copy, investigate that gateway or remote system, filtering, quarantine, or delivery timing.
5. DELIVER: Exchange recorded internal delivery. Check the recipient’s folders, rules, quarantine, mailbox, and client synchronization.
6. DROP: investigate the recorded policy, limit, or transport-agent reason.

Tracking retention and file-size settings are configurable. Do not assume default values are still in effect; confirm local configuration and that the relevant logs have not rolled over. See Microsoft’s message tracking documentation.

If only external messages fail

When internal delivery works but external messages fail, inspect the outbound path and the actual queue or tracking error. Review Send connector settings:

Rank #3

Sale

Mastering Microsoft Exchange Server 2016

$43.49

Buy on Amazon

Get-SendConnector |
    Format-List Name,Enabled,AddressSpaces,DNSRoutingEnabled,SmartHosts,Port,
                RequireTLS,TlsAuthLevel,TlsDomain,CloudServicesMailEnabled

If Exchange routes directly using DNS, test the destination domain. If it uses a smart host, test that host instead:

Resolve-DnsName example.net -Type MX
Test-NetConnection example.net -Port 25

# For a smart-host deployment:
Test-NetConnection smtp.contoso-provider.example -Port 25

Investigate the specific failure indicated by the evidence:

• DNS cannot resolve the recipient domain or configured smart host.
• TCP port 25 is blocked by a firewall, ISP, cloud provider, or security appliance.
• The remote system rejects the certificate, TLS negotiation, sender, recipient, or connecting IP.
• The connector routes through an obsolete server, wrong smart host, or incorrect address space.
• A hybrid connector points to an unavailable server or an incorrect coexistence route.
• IPv6 resolution selects a route that fails even though IPv4 works.
• A security gateway accepts SMTP but fails to forward the message onward.

If tracking shows SEND to a gateway, the Exchange-to-gateway handoff succeeded; continue investigation with that gateway and its logs. Do not disable TLS validation or create an anonymous relay as a generic workaround.

If only internal messages fail

Check whether the destination mailbox’s database is mounted, whether Mailbox Transport Delivery is running, and whether server-to-server routing and Active Directory site topology are healthy. Compare senders and recipients on the same server, different servers, and different databases. A failure confined to cross-server messages points toward routing, database, or coexistence paths rather than general external delivery.

If only Outlook desktop fails

If OWA sends the same kind of test message successfully, do not start by restarting Exchange services.

Rank #4

Microsoft Exchange Server - Break Fix Guide for Administrators: Exchange Server: On-Premises & Online Support Document

$8.57

Buy on Amazon

1. Check the status bar. Look for Disconnected, Working Offline, Trying to connect, or a persistent Synchronizing folders state. Confirm Send/Receive > Work Offline is not enabled, then try Send/Receive.
2. Open and recreate a stale draft. A long-open draft can fail with “The function cannot be performed” in a documented Exchange Server 2016 case. Record its details, close it, and create a new message rather than repeatedly sending the same stale draft. See Microsoft’s documented Exchange 2016 issue.
3. Test in Safe Mode. Close Outlook, then run outlook.exe /safe. If sending works there, disable non-Microsoft add-ins one at a time and retest.
4. Compare profiles. Create a new Outlook profile for a controlled test. If appropriate, compare Cached Exchange Mode with Online Mode on a test workstation rather than changing users’ settings organization-wide.
5. Investigate synchronization and OST health. Look for persistent synchronization errors and confirm whether the message reaches the mailbox from another client. Use Microsoft’s guidance for Outlook connection and send/receive issues.

Cached Exchange Mode can introduce local synchronization and OST failure modes. Online Mode is a useful diagnostic comparison, not automatically the best permanent setting: it increases dependence on the server and network. Microsoft has also documented a Cached Mode and transport-provider condition associated with messages stuck in Drafts or Outbox; use the Outlook troubleshooting guidance rather than applying registry changes without verifying that the documented issue matches your setup.

If sending from a shared mailbox or delegated identity

Confirm which account Outlook is actually using and whether the user has the permission that matches the chosen sending method. Full Access lets a user access a mailbox; it does not by itself grant Send As. The user may instead be configured for Send on Behalf.

Get-RecipientPermission [email protected] |
    Where-Object {$_.Trustee -like "*user*"}

Get-MailboxPermission [email protected] |
    Where-Object {$_.User -like "*user*"}

Review the result and the mailbox’s delegated-sending configuration; do not infer Send As from Full Access alone. Microsoft describes this distinction in its article on sending from a shared mailbox with Full Access.

Check message size and recipient limits

Limits can apply at the organization, connector, server, mailbox, client protocol, mail-flow rule, gateway, and recipient end. The most restrictive applicable limit wins, so increasing one setting may not resolve the failure.

Get-TransportConfig |
    Format-List MaxSendSize,MaxReceiveSize,MaxRecipientEnvelopeLimit

Get-Mailbox [email protected] |
    Format-List MaxSendSize,MaxReceiveSize,RecipientLimits

Get-SendConnector |
    Format-List Name,Enabled,AddressSpaces,SmartHosts,Port,MaxMessageSize

Get-ReceiveConnector -Server EXCH01 |
    Format-List Name,Enabled,Bindings,RemoteIPRanges,MaxMessageSize

Compare the configured values with the size, recipient count, and any error returned by the client or remote system. The documented Exchange organization-level default send and receive size is 10 MB in the referenced configuration, but administrators can change it, and other limits can be lower. OWA, ActiveSync, and EWS have distinct client-specific limits. Binary attachments also grow by approximately 33% when Base64 encoded, so a 64 MB transport limit may allow only about 48 MB of binary attachment data. See Microsoft’s message size and recipient limits.

Best Value

Microsoft® Exchange Server 2010 Administrator s Pocket Consultant

• Used Book in Good Condition

$25.59

Buy on Amazon

For Exchange 2013/2016/2019 coexistence or migration

When the problem began after adding or moving mailboxes to another server, test paths in both directions. Compare mailboxes on the old and new servers and test internal as well as external delivery:

Also review each server’s Send and Receive connectors and scope, internal and external namespaces, Autodiscover, certificates assigned to SMTP and IIS, Hybrid Configuration Wizard settings, and Active Directory site routing. Confirm that the new server is included in the intended connector path and that no route still depends on an offline or misconfigured older server.

Changes to avoid without evidence

• Do not delete queue databases as a routine remedy; this can cause message loss and destroy evidence.
• Do not disable TLS validation or create an anonymous relay connector to bypass a routing problem.
• Do not alter retry intervals as a general fix. Microsoft documents a 15-minute default retry interval and advises against changing it without a specific reason or guidance. A different interval does not correct a broken route. See Exchange message interval configuration.
• Do not repeatedly restart every Exchange service. Collect queue, tracking, service, and event evidence first, then act on the affected component.
• Do not delete the only copy of the message before recording its details. If a fresh attempt is needed, preserve the original and send a new small test message.

When to escalate

Escalate to your Exchange support team or Microsoft support when tracking shows unexplained repeated FAIL, DROP, or DEFER events; queues keep growing; database or Active Directory errors appear; multiple servers or databases are affected; or a certificate, hybrid configuration, or third-party gateway is involved. Escalate promptly if there is potential message loss or a retention obligation. Keep the recorded timestamps, message identifiers where available, queue output, tracking events, error text, and relevant event logs.

Exchange Server 2013, 2016, and 2019 are legacy versions; support status and available security updates vary by version and date. Check Microsoft’s current lifecycle information for the exact server before treating continued operation as a long-term plan. If recurring incidents stem from unsupported infrastructure, assess a supported upgrade or migration separately from the immediate mail-flow repair. A migration will not fix a client-only Outlook problem or a poorly configured hybrid route.

Quick Recap

SaleBestseller No. 1

The Admin's Guide to Microsoft Exchange Server Subscription Edition

$42.93

SaleBestseller No. 2

Microsoft Windows Server 2022 Standard | Base License with media and key | 16 Core

Server 2022 Standard 16 Core

$359.99

SaleBestseller No. 3

Mastering Microsoft Exchange Server 2016

$43.49

Bestseller No. 4

Microsoft Exchange Server - Break Fix Guide for Administrators: Exchange Server: On-Premises & Online Support Document

$8.57

Bestseller No. 5

Microsoft® Exchange Server 2010 Administrator s Pocket Consultant

Used Book in Good Condition

$25.59

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.