Hey Mark, 

Thanks for reaching out to the community. This is likley happening due to this option in Settings->protocols.

 Please let me know if this helps. 

Kind Regards, 

Check your smtp logs to confirm that Zach's theory matches your data.

Because Office365 will sometimes disconnect early and incorrectly assume success, I recommend keeping this option enabled, even at the risk of some duplicates.

Then investigate why sessions are getting broken so that redelivery is attempted.

Thank you for the responses.  I did check the setting and my "Continue delivery if session is disconnected by client" is DISABLED.  It's not something I've ever changed or needed to change.

Unfortunately, nothing so far is adding-up.  This issue only arose since my last update (version aforementioned); it was not happening prior.  Also, as mentioned this happens with incoming third-party emails, but also emails generated by my own software... which sits on the same physical box and uses SM.  

I'm updating to build 8251, which apparently was released the day after the build I have.  Guessing that must have been a minor, but important fix.  Will return to this thread after a bit to see if the issue corrects itself.

Thanks again for assistance :)

Understood, but it would still be good to understand whether the message appears twice in SMTP log, or once in SMTP log but twice in delivery log, or once in both.  If once in both, is it twice in webmail and outlook or twice in only one of them 

It will also help you know what to look for after the upgrade.

That's a point worth checking out so I did.  I'm no expert at interpreting the logs, but it appears the message appears only 1 time in each of the DELIVERY and SMTP logs (I've protected the IP and email addresses, but changed nothing else):

DELIVERY LOG
------------
00:20:34.165 [13266041] Sending remote mail to: receiveremail@email.com
00:20:34.556 [13266041] CMD: RCPT TO:<receiveremail@email.com>
00:20:34.931 [13266041] Process delivery status notification step from recipient success. Recipient: [receiveremail@email.com], Notify: [], LastError: [], RanDomainFilter: [False], RanGlobalFilter: False
00:20:34.931 [13266041] Delivery for senderemail@server.com to receiveremail@email.com has completed (Delivered)

SMTP LOG
--------
00:20:14.117 [160.240.60.220][28975643] cmd: RCPT TO:<receiveremail@email.com>
00:20:14.117 [160.240.60.220][28975643] rsp: 250 OK <receiveremail@email.com> Recipient ok

This represents an example of a duplicate email.  It was a result of an internal system-generated email and was one of about 4 sent, about a minute apart.  This is the only one which came in duplicated in my Inbox (Outlook desktop).

If it is only in the delivery log once, then it should only be in webmail once.

This suggests that the problem is with Outlook synchronization.   Past advice from support: (1) in webmail, delete any sync connection objects that are no longer used, and (2) force a resync of all others.

   In rhe past, a full resync required deleting all sync object and the Outlook profile, but awhile back they provided a "resync all protocols" option which does not require that.

I'm not using Office 365 or Exchange though, just Office 2019 desktop (with Outlook 2019).  Would your "resync" still apply?

Yes.  It still uses synchronization, whether the connection protocol is imap, pop, mapi, or ews. If you used autoconfigure, it probably chose mapi, which provides the best feature set.

Are you seeing the duplicates only in Outlook? If you check that same message in webmail you see only the one copy?

As Douglas noted, any sync protocol aside from POP is maintaining an index of what is on the server. So, duplicates seen in that client's index can usually be cleaned up by resyncing that client (removing the account and/or profile, and removing the sync key from Settings>Connectivity>Synchronized Devices if using MAPI/EAS/EWS) and allowing it to pull down a fresh copy of the mail data from the server. 

I do recommend completing that resync on the latest available public version though to ensure you have all of our latest fixes and improvements available when the resync begins. 

Update - I received a duplicate email today and decided to check the web interface to which emails forward to another address.  The other address through the web interface only shows the email coming in 1 time.

So perhaps Outlook (not web, but installed Windows ver of Office 2019) is the culprit?  I'm using only POP3 accounts and see no "sync" options as described.  Wonder if there is something else to check?  If this turns out to be the issue, it's not SM.

Thanks for your followup on this Mark, that is definitely interesting behavior! POP is a pretty simple protocol, and there is no two-way sync involved so that would put my bet on Outlook as well. Could you try doing an OST/PST repair on that Outlook profile and see if that helps? You can find those steps here:

Outlook really does seem the most likely since I think we can rule-out SM and its recent updates.  Perhaps the pst file has some errors (always it seems no matter how many repairs).

Thanks as always for the assistance :)

You're very welcome!

Hey Mark! Just wanted to check in on you and see if the PST/OST repair process helped here? The other thing I thought of too is double-checking the account list in that Outlook profile to make sure they don't have their account doubled up or anything like that. Let me know what you find out :)

Too early to tell since when it happens, it irregular, inconsistent.  I'll give it a week and then update.

That makes perfect sense. Fingers are crossed for you :)