Here are some troubleshooting steps I would recommend:

1. Check Outlook’s Sent Items settings: In Outlook Classic, go to File → Options → Mail and check the option to save copies of messages in the Sent Items folder. Also check whether any Outlook rules or add-ins are moving or deleting sent messages.
2. Compare webmail with Outlook: After sending a test email, check the sender’s Sent Items folder in SmarterMail webmail and Outlook. If the message appears in webmail but not Outlook, investigate MAPI/EWS synchronization, cached data, and the Outlook profile. If it is missing in both, investigate the server-side submission and Sent Items storage process.
3. Check SmarterMail logs: Review the SMTP, delivery, and MAPI/EWS logs for the same message and timestamp. Your sample delivery log proves delivery to the recipient, but it does not establish whether a Sent Items copy was created or synchronized.
4. Enable targeted logging during a controlled test: Instead of enabling detailed MAPI/EWS logging for all 450 users, coordinate with SmarterTools support to determine whether logging can be restricted to a specific user, session, or short time window. Capture logs only for a few affected accounts and disable verbose logging immediately afterward.
5. Check Outlook synchronization errors: Review the Outlook Sync Issues folders and relevant Windows Event Viewer entries. Also check whether affected users experience the problem on multiple computers or only on one Outlook profile.
6. Investigate the reverse scenario: If a message appears in Sent Items but is missing from the recipient’s Inbox, search the SMTP logs using the message ID and timestamp. Check for delivery failures, filtering, spam handling, mailbox rules, and whether the recipient is on the same server or an external server.
7. Check server load and software versions: Because you have high email traffic, examine CPU, memory, disk I/O, database performance, and SmarterMail service logs around the affected timestamps. Verify that SmarterMail and Outlook are running supported, up-to-date versions.

I would not recommend adding IIS Basic Authentication directly to the SmarterMail webmail site when IIS is acting as a reverse proxy. SmarterMail handles its own authentication, and enabling Basic Authentication at the IIS layer can interfere with the authentication headers, cookies, and requests required by the application. It may also cause authentication prompts or prevent users from logging in correctly.

1. Restrict access by IP address: If users connect from known office IP addresses or through a VPN, configure IIS IP Address and Domain Restrictions to allow only trusted addresses. Make sure this restriction does not unintentionally block remote users or required services.
2. Use a VPN: For an organization where webmail is intended only for employees, restricting access to the webmail interface through a VPN is generally a stronger approach than adding a second login prompt.
3. Use a separate reverse proxy or access gateway: If you need an additional authentication layer, use a proxy or identity-aware gateway that explicitly supports SmarterMail's authentication flow, WebSockets if required, and all necessary application paths. Test the complete login, logout, session renewal, and mailbox access workflows before deploying it.
4. Keep IIS Basic Authentication separate from the application: If you still want to test Basic Authentication, use a separate test site or staging environment first. Do not assume that enabling it on a static website proves it will work with SmarterMail. A reverse proxy may forward authentication headers differently, and the application may not support the extra authentication challenge.
5. Strengthen SmarterMail's own security: Keep SmarterMail updated, use HTTPS, enforce strong passwords and multifactor authentication where supported, and configure appropriate account lockout or brute-force protection.