IMAP and SMTP explained: why receiving email and sending email are different
Understand the two connections behind a desktop email app, why one can work while the other fails, and what to check before resending.
You can see new email in your desktop app, but a reply will not send. Or sending works while the inbox appears stuck. That can feel contradictory if you think of email as one connection.
A standards-based email client usually does two different jobs. It accesses and manages a mailbox using IMAP, then submits outgoing messages using SMTP. Understanding the difference makes troubleshooting more precise and helps you avoid unnecessary password resets or duplicate messages.
IMAP gives the app a view of your mailbox
IMAP is the connection used to work with messages and folders held by your email provider. It allows a client to fetch message information, search the mailbox and synchronise changes such as read states or flags. The protocol also supports folder and message management. The IETF's IMAP specification describes these operations.
A desktop app may keep downloaded copies so you can read previously saved mail offline. Those copies are a local view of the account, rather than a new email account.
This is why moving or deleting a message in one client can affect what you see elsewhere. The app is asking the provider to change the server mailbox. An offline view may not show that change until it reconnects.
SMTP submits the message you want to send
SMTP submission is the outgoing part of the workflow. Your app hands the completed message to your provider's sending service, which then handles onward delivery. The IETF's message-submission standard distinguishes this submission step from the later relay between mail systems.
A provider accepting a message is not the same as every recipient receiving or reading it. An address can be rejected, a recipient's server can delay delivery, or filtering can place the message somewhere unexpected.
For everyday use, keep three questions separate: did the app submit it, did the provider accept it, and did the recipient receive it? Different evidence answers each question.
Sign-in can authorise separate capabilities
OAuth sign-in asks a provider to give the app permission without making you type your main account password into the client. The permissions still have a purpose and a scope.
For Microsoft mail, IMAP access and SMTP sending are separate permissions. Maintaining access between sign-ins may involve a further offline-access permission. Microsoft's OAuth guidance explains those distinctions.
In an organisation, approval may also depend on administrator policy. Successfully signing in does not prove that every mail protocol is enabled for your mailbox. Ask an administrator to check the account's permitted connection methods instead of repeatedly trying the same credentials.
Why receiving can work while sending fails
Consider an account that downloads new messages correctly but keeps outgoing messages in an Outbox. That points you towards the sending side.
Possible causes include a network problem, an expired authorisation, a sending limit, an attachment the provider rejects or an organisation restriction. Microsoft documents that Authenticated SMTP can be controlled at organisation and mailbox level.
The next useful step is to capture the visible error and check whether the provider's own webmail can send. Do not disable security controls or change unrelated incoming settings merely because the outgoing connection failed.
Why a message can appear before its body
Mail apps do not always download an entire account in one operation. A list may show subjects, senders and dates while message bodies are still downloading. Attachments can be separate again.
Inbox Invaders downloads Inbox messages in the background. Other folders download bodies when opened, with older pages available separately. Attachments are obtained when needed. A visible subject therefore does not mean every file in that message is already available offline.
Before travelling without a connection, open the messages you need and save the required attachments. Confirm that the content is present instead of relying on the message count.
Handle uncertain sends carefully
An internet connection can fail after a provider accepted a message but before the app received a conclusive response. In that situation, sending another copy immediately can create a duplicate.
Inbox Invaders keeps a recoverable Outbox and distinguishes unresolved delivery. Check the status shown by the app and the provider's Sent folder. If the result is still unclear, confirm with the recipient before editing and sending again.
A successful send also does not prove that a folder move or draft synchronisation finished. Those are different operations with their own connection and server state.
A short troubleshooting sequence
Start with the smallest useful question: is the problem receiving, sending, or both? Then check the account's connection status and the exact message shown by the app.
Next, use the provider's webmail to establish what is on the server. Confirm that you still have permission to connect and, for a managed work account, ask whether policy changed. Reconnect through the app if authorisation is no longer valid.
Keep passwords, tokens and private message contents out of support screenshots. A description of the operation, provider and visible error is often enough to begin.
Knowing the two jobs behind email helps you choose a better next step. IMAP and SMTP work together, but a problem in one does not automatically mean the other is broken.