Could build a small .NET helper EXE or DLL that handles:
IMAP login
download unread/new mail
save attachments
send SMTP mail
return results to Access

Access would call it when needed. The helper could use a modern mail library and Access would stay clean.
That keeps the Access app from having to fight SSL/TLS and IMAP protocol details directly.

Yes, it can definitely be done. In fact, I've got my own code that receives email directly into Access without going through Outlook.

I've been hesitant to make a video about it because I don't consider my solution 100% polished. It works well enough for what I use it for, which is primarily pulling customer service emails into my database, but there are limitations.

At a high level, my system connects to the mail server using POP3 over SSL and downloads the messages. I use a small PowerShell script to handle the actual connection to the mail server, and then Access takes over from there. It imports the downloaded messages, pulls out things like the sender, recipient, date, subject, and message body, does some cleanup and decoding, and then stores everything in my Access tables.

The biggest limitation is that my system is really designed around extracting the text from the message. I'm not doing anything useful with attachments or embedded images. That's fine for my purposes because I mostly care about getting the text of customer service messages into my database so I can process them.

I've got it working with Gmail just fine. I receive Gmail messages with it all the time. Again, though, it's basically text only, and depending on how a particular message is encoded, especially if somebody sends pictures or attachments, sometimes you can get some garbled MIME/encoded garbage mixed in with the message. I then just use AI to clean those up - which are only like 1% of the total messages I receive.

I've thought about putting together a video or two showing how my system works, along with its limitations. If that's something you'd be interested in, let me know. And if anyone else is interested in seeing how this works, let me know too. If there's enough interest, I'll put something together.

There are also some lightweight email utilities out there that might make this whole process easier. Instead of having Access deal directly with all of the POP3/IMAP, SSL, authentication, MIME, and other email nonsense, you could let one of those utilities retrieve the mail and drop the messages into a local folder or some other local data store. Then Access can take over from there, import the messages, and do whatever you want with them. I haven't spent a lot of time exploring those options yet, but if that's something you guys would like to see, I'm happy to look into it.

For my own purposes, the extremely lightweight solution I have works fine. Customer emails come into Gmail, Gmail forwards them to a separate Gmail address that I use specifically for customer service, and my Access database pulls the messages from there. Everything is still archived in Gmail, so technically I can always go back and find the original message if I need to. But I specifically tell customers not to email me images or screenshots. That stuff belongs in the forums. If somebody emails me an image, I'm generally just going to tell them I can't receive it that way. Yes, I could go digging through Gmail to find the original message and attachment, but I'm not going to. LOL. For customer service, I really just need the text, and my current system handles that just fine.

Also, I did spend some time playing around with talking directly to Gmail using IMAP, and honestly, it was a pain. IMAP is much more complicated to deal with directly, and I had a hard time getting everything working reliably. POP3 was much easier for what I needed. I just have Gmail make the messages available through POP3, my Access system pulls them down, and Gmail keeps the original messages there and marks them as "Received." Since I'm not trying to build a full replacement for Gmail and I really just need to grab incoming customer service messages and process the text, POP3 ended up being the much simpler solution for me.

I would like to see this. It's hard for me to believe in 2026 there is not a solid solution for this already. Email is a part of every business and so are databases. Maybe the answer comes from the Gmail Graph API.

The solid solution Microsoft envisions is that you just use Outlook. But with them moving away from desktop Outlook toward this new web Outlook that I can't stand, getting email into your own database so you can work with it is becoming more important.

For me, I like taking incoming emails from customers and attaching them to their records. When I pull up a customer service email, I can immediately see the customer, the courses they've purchased, and any memberships they have. If they ask me a question, all of that information is right there. It saves a step.

You can bring email in through Outlook fairly easily, but let's be honest, Outlook isn't the best solution. My text-based POP3 email reader has been working fine for five or six years now, but it has limitations. If someone sends me something with a picture in it, it becomes an issue. I have to strip out the encoding, and probably one out of every hundred emails sends me back to Gmail to figure out what they actually sent.

I'll do some more research into it. It would be nice if there were a simple, lightweight app built specifically for this: it checks your mail every five minutes, or whatever schedule you set, and either gives you a clean API that Access can call to retrieve the email or simply saves the messages to a local folder for Access to import.

Ray, I like your idea of a small .NET helper EXE or DLL. That is probably the cleanest architecture. Let the helper deal with IMAP, SMTP, SSL/TLS, OAuth, attachments, and all the modern email insanity. Then Access just calls it, receives a result, and imports the message data into its own tables. That keeps the Access side focused on what Access does well instead of trying to make VBA behave like a full-blown mail client.

As for Gmail's API, I think that could be another possible direction, although it adds API authentication and OAuth setup to the mix. It may be a better long-term route than trying to directly manage IMAP connections from VBA. I'll see what options are available and whether there is something practical enough to teach without turning it into a three-hour lesson on Microsoft's and Google's authentication hoops.

If it were me, I would just export the info from the email client to Access.  If the main goal is to avoid using Outlook, you can use free clients like Thunderbird, which has mods for exporting and importing.  Trying to have Access do everything is not always the best way.

The goal is to have a complete history of interactions with each one of our customers. Having email lost in another program makes this difficult.

I had actually been working on a similar personal project to transform Access itself into an enterprise communication client completely independent of Outlook/Thunderbird/Bluemail,etc. However, due to competing work priorities and projects, it’s been sitting on the back burner, and unfortunately, I don't see myself getting back to it before December.
I've also accumulated extensive notes exploring various approaches for this, considering EXE + JSON versus Access's .net dll registration, COm, and bitness headaches alongside adapting a Conversation/Thread structure to track and report conversations on a per client basis by topic and message count (e.g., 2026 Proposal Working - 4 messages, Price Update - 8 messages).
I hope I can find the time to finish it soon. If so, and if Richard deems it appropriate, I'll pass it along to him so he can share it with you all. No promises but I'll try to find some time.

Yes I have used Thunderbird also and I really like it.
It works really well with Access.

Yeah, Thunderbird is one of those programs that I remember seeing when I was doing some preliminary research on this months ago. I might have to look into it.

I like Thunderbird, better than outlook in a lot of different ways. One thing using the Thunderbird Client, it groups, all of the emails together by the sender.
And Thunderbird has a lot of documentation on how to program it with VBA.