Written in a rush, hope it helps.
See if you can work out what they have offered as evidence to you. EVERYTHING needs to line up. Get copies of the proof as close to the source as possible.
As advice I would ask for copies of the email server backup from various points as these will also need to line up and people never make the effort to cover the backups. If nothing else the cr_p this will cause will be worth it. Put it under the guise of forensic evidence. The reaction should also tell you how confident they are.
As a general guide this is the flow.
You type an email in a client (outlook, webmail, apple mail app on iPhone etc) and it sends it to the SMTP gateway of your email domain locally (MrSite). It is usually transferred through this gateway but is not copied for recording purposes by default.
Nothing gets saved on the SMTP server but it will insert a marker in the email to show transfer. It is also possible to make the gateway maintain a log of messages sent (from-to-date-time-size). As the sending gateway finishes it gets an "ack" from the recipient in most cases so marks it as "received" in its own sending log. It is likely that this is what is being offered as evidence. This can be faked if people feel so inclined. The backups are your best case of seeing if this has been tweaked. Sequence numbers and other stuff in the email.
These headers can be seen if you open the email mechanically as opposed to in an email tool which hides them to tidy up. Look for a "show headers" option if you have it and you should see them.
You can elect to save it to sent messages (as most do) for your own records. This goes from the client to either the client's message database (on machine or server) or to the main email server on products like Office. With Cloud based services these are clearly off site and so centrally managed to allow access from many devices like your phone. Getting the logs and evidence from these is highly painful and often expensive so beware this issue.
This gateway looks up the recipient's domain (MXrecord) and opens a session to it. It then transfers the email to it. SMTP server to SMTP server. Again this does not normally save a copy. It will also insert some markers to show receipt-action-date-time etc. It will then send it to the email server of the recipient's domain to be stored. Your machines email client (Outlook, mail, web client) will then connect to the local email server and collect it.
Other things can get in path and may have impact.
SMTP gateways can have anti-virus programs added and put emails in quarantine etc. If you are not correctly configured or informed by your provider there may be a pile waiting somewhere.
SMTP servers can re-boot/fail/glitch causing an email being lost in processing. It will receive it. Store it on disc whilst it processes the information, AV and other things, then forward to your nominated email server. Then SMTP deletes it once the email server approves receipt.
Incorrectly formed email address, in general an email with a bad address can fall into two buckets. Wrong personal name (personal.name@domain.ending) or wrong domain. Personal name can go wrong due to autocomplete the scourge of security officers the world over. In a rush you type a name (unless you are using reply-to) and hit return, Outlook offers a pick list of popular names and without noticing you hit return and select the wrong one. This will not produce a bounce or error, the incorrect recipient will likely just think you made a mistake and delete it. If they are kind they may advise the sender. If you enter a new address and get it wrong (spilling of personal.name) then it should bounce with "sender-unknown" being sent back by the SMTP gateway or email server. The recipient will not see this at all. It should be in the recipient's SMTP/Email server log. You need to check this on your side (Email receipt log around time of their sending stamp. Look for errors and rejections, also look in the server operating system logs for reboots for -10 mins to +30 min around time of senders MX timestamp)
Your local computers client may have anti virus software which processes things and so creates the opportunity for corruption and loss. The client itself may have corrupted it if it is unstable (OS, Client, connection) but these days they are usually well written to deal with instability. Were all of your and MrSites servers stable during this time.
What steps can you take to inspect/mitigate this from your side ?
Is all of the kit in your side of the email path stable or were you having problems around this time that might have corrupted the email store and so lost the entry or email content. Imagine a database list of emails, if the key is not in the list then the content is no longer seen even if it is resting on the local disc in your email server. A reboot during list update of any email might cause an application to crash and corrupt the list.
If the other party has given you an MX record of date and time of their outbound SMTP gateway then you could investigate the inbound SMTP server from your end. Again this will require support from your provider so give them the window of time you need help on in order to minimise their workload (or bill).
DM me if you need more help. May flip it to a phone call to go through in more detail if you need more info on certain elements.
One thing I will mention. I look after the good ladies home business e-commerce web site for my sins and we did use MrSite initially. I found their support to be utterly crap. We moved to a company called Create. I am not saying you should but I would recommend investigating them if you get a moment.
Hope some of this gives you ideas or help.
Best wishes with it.
