Hi Roy. I don't think this is an Access bug. That particular CDO error usually indicates a problem communicating with the SMTP server itself.

I use the same techniques I taught in the Email Seminar and send email with CDO every day. In fact, my entire email system runs on it, and I haven't noticed any changes on my end.

First, verify your SMTP server name, port number, username, password, and encryption settings. Many email providers have changed their security requirements over the years, especially regarding TLS and app passwords.

Also, let us know which email provider you're using (Gmail, Outlook, your own domain, etc.), since that will help narrow it down considerably. If possible, try the same credentials in another email client, such as Outlook or Thunderbird, to verify that the account itself can still send mail outside of Access.

My money is on either Microsoft or, more likely, the email provider changing or deprecating an older authentication method rather than anything you changed in Access itself.

Follow-up: I did some extra digging and I don't see any evidence that a recent Windows or Access 365 update broke CDO globally. If Microsoft had introduced a change that affected this technique, I'd expect to see lots of complaints from the Access, VBA, and Classic ASP communities, and I'm just not seeing that.

I also deliberately wait a little while before installing Windows and Office updates on my own systems. I prefer to let other people find the bugs first. :) Since my own email infrastructure is still running on the exact same CDO techniques I teach in the Email Seminar, I'm leaning even more toward this being an SMTP provider, authentication, or security setting issue rather than an Access issue. If multiple students start reporting the same thing this week, then I'll start pointing fingers at Microsoft. Until then, my money is still on the email provider or a changed credential somewhere along the line.

I suggest you verify your settings with MS Account.  Last time i used Richard's code and email refused to send it was because the "code" you get from MS was broken/useless due to my account settings.  Try re-applying for a new verification code

My Email provider is Gmail.
This is the SendMailConfigMod
Public Const SMTPSERVER = "smtp.gmail.com"
Public Const SERVERPORT = 465
Public Const USERNAME = "[email protected]"
Public Const PASSWORD = "XXXX XXXX XXXX XXXX"
Public Const USESSL = 1
Public Const TIMEOUT = 10
What should I be looking for?
Thanks for all the help.

Roy Ah, Gmail. That helps narrow it down a lot.

Your settings look basically correct for Gmail: smtp.gmail.com, port 465, SSL on, and your full Gmail address as the username. So the next thing I would check is the password. That needs to be a Gmail App Password, not your regular Gmail password. It looks like you may already be using one, based on the XXXX XXXX XXXX XXXX format, but I would still generate a brand new App Password in your Google account and try replacing the old one.

Also make sure 2-Step Verification is still enabled on that Google account. Gmail requires that in order to use App Passwords. If Google changed a security setting, revoked the app password, flagged the login as suspicious, or otherwise decided it doesn't like that connection anymore, CDO will usually just give you a generic transport error like this instead of a helpful message.

You can also try port 587 with TLS if your code supports that, but for the CDO method I teach, port 465 with SSL has traditionally been the most reliable Gmail setting.

So at this point, my first move would be: create a new Gmail App Password, paste that into your config, and test again.

Went to watch your video to get the details on obtaining the Gmail APP Password. Yor video doesn't match with what I have in GOOGLE. I get "Security & Sign-In", then "2-Step Verification" and that's where it all changes. There doesn't seem to be a way to obtain that APP password.

Google has changed their menus several times over the years, so my video may not exactly match what you're seeing today. It's hard to keep up.

The App Password option will ONLY appear if 2-Step Verification is enabled on your Google account. Simply seeing "Security > Sign-In > 2-Step Verification" isn't enough. You have to make sure 2-Step Verification is fully turned on and active.

Also, some account types don't support App Passwords at all. If this is a Google Workspace account (through an employer, school, or organization), the administrator may have disabled them.

After signing into your Google account, try going directly here:

https://myaccount.google.com/apppasswords

If you get an App Password screen, generate a new 16-character password and replace the existing one in your Access configuration.

If you get a message saying App Passwords aren't available, then that's likely the root of the problem and we'll need to figure out exactly what type of Google account you're using.

One other question: did you recently change your Gmail password? If so, that could very well be the culprit. In some situations, changing your main Gmail password can invalidate existing App Password sessions, which would explain why something that has been working for years suddenly stopped working.

OK, I got a new IPhone 17. I was required to upgrade my password. I verified the two-step verification and generated a new App password but I still have the same problem.

Follow-up: I shut everything down and restarted Access. Now everything in back to normal.

Ah yes... the mighty O-N-O-F-F switch saves the day again.

I'm glad it's working now. The fact that a full shutdown and restart fixed it makes me even less suspicious of Access itself and more suspicious of some temporary authentication, network, or cached connection issue.

Never underestimate the power of a good reboot. IT people have been asking, "Did you turn it off and back on again?" for 40 years because it works far more often than we'd like to admit.