Email delivery and reading email are separate operations. SMTP transports messages between clients and servers or between servers. IMAP and POP3 provide mailbox access. A user who cannot see a message may have a delivery problem, a filtering problem, a mailbox-selection problem or a client synchronization problem. Choosing the right evidence first avoids changing SPF or DKIM for a failure that happened after delivery.
Follow the message through the stages
A user or application submits a message to a submission service. The service may authenticate the client, apply policy and queue the message. SMTP servers then transfer it toward the recipient's delivery system. An accepting server can still route the message through filtering, quarantine or mailbox rules before the user sees it. SMTP acceptance is therefore a specific transport event, not a promise about inbox placement or reading.
RFC 6409 separates submission from message relay. RFC 5321 describes SMTP transactions and responsibility after acceptance. Record which server issued the response and at which transaction stage. A submission success on the sender's service does not demonstrate acceptance by the final recipient's service.
Distinguish the access protocols
IMAP lets a client work with server-side mailboxes and message state. Its operations include selecting a mailbox, searching and fetching messages, and managing flags. POP3 provides a simpler retrieval-oriented model with a transaction state and deletion requests committed in its update phase. A POP client does not necessarily delete every retrieved message; client settings and the actual DELE/QUIT sequence matter. See RFC 9051 and RFC 1939.
Neither protocol is a substitute for the SMTP delivery transaction, and neither establishes DMARC alignment merely because a user logged in. Modern clients may use provider APIs instead of IMAP or POP. Establish the real client protocol before applying a generic troubleshooting checklist. Treat port numbers as clues rather than proof of the service, security mode or authorization used.
Use a stage-specific diagnostic
If submission fails, inspect the client configuration, server response, TLS and authentication method without exposing credentials. If server transfer fails, collect the remote SMTP response or delivery-status notification, queue identifier and recipient. If the service confirms delivery, inspect the destination mailbox, quarantine, rules and any forwarding. Only then investigate client synchronization, selected folders, filters and cached state.
Compare the same account through an authorized provider interface and the affected client. If the message exists on the server but not the client, prioritize access and presentation. If it is absent from both, do not conclude that IMAP lost it; return to the delivery trace. Preserve timestamps and identifiers because similar subjects can refer to different messages.
Work through two missing-message examples
These are hypothetical investigations, not executed tests. In case A, the sender has a final 250 response from its own submission service but no recipient-service acceptance. The next evidence is the outbound queue and downstream SMTP trace. Checking the recipient’s IMAP folders cannot establish whether the queued message ever reached that service.
In case B, the recipient service’s trace identifies delivery to the correct mailbox, and the same message is visible in the account’s authorized web interface but absent in one desktop client. The next checks are the selected account, folder subscription, filters and synchronization state. That evidence supports an access or presentation investigation, not a new SPF record.
In either case, record Message-ID, recipient, relevant timestamps and server-local queue identifiers together. Message-ID alone is not authentication or an infallible unique incident key. If the server-side evidence is incomplete, keep the stage unresolved rather than claiming IMAP lost the message.
Interpret POP deletion carefully
Retrieving a message with RETR does not itself request deletion. DELE marks a message for deletion, RSET can clear those marks, and QUIT from the transaction state enters the update phase. If a session ends without that QUIT, RFC 1939 says it must not remove messages through this update process. Even a requested update can fail, so inspect the server’s result instead of assuming a retrieved message was deleted. Use the provider’s current secure access methods; these command names are explanatory, not a recommendation to expose passwords on an unprotected connection.
Locate the first missing stage
- Submission: retain the server response and sender queue ID for this message.
- Transfer: find acceptance or rejection by the recipient service, not merely the sender service.
- Storage: check the actual destination mailbox, quarantine, rules and forwarding.
- Access: confirm the same account, folder and message in an authorized server interface and the affected client.
- Decision: assign the first unproven stage to its owner; do not change DNS merely because a client cannot display a message.