Hi @GoceRibeski Welcome to the community!
So my take is that your certificate doesn't cover mail.adwdevelopments.com, it only covers the apex domain name.
So you will need to expand the certificate to cover the mail.adwdevelopments.com and you should be set. @JuergenAuer is correct that a mail subdomain isn't required, but if you want to use it you'll need to expand the cert to cover it. (and it is already set up!)
Cert Hostname DOES NOT VERIFY (adwdevelopments.com != *.prod.phx3.secureserver.net | DNS:*.prod.phx3.secureserver.net | DNS:prod.phx3.secureserver.net)
(see RFC-2818 section 3.1 paragraph 4 for info on wildcard ("*") matching) So email is encrypted but the host is not verified
I’m using cPanel email from GoDaddy hosting, don't intend to change it for now.
This is the guide that I used few years ago when I set the cert:
GoDaddy is strange when it comes to securing the mail server of a shared hosting instance. When developing CertSage (my ACME client specifically designed to acquire Let's Encrypt certificates for GoDaddy shared hosting), I had to determine which subdomains should be included when attempting to acquire a certificate. I debated on the usefulness of securing the mail subdomain. This really comes down to how you want to configure email clients on your devices that manage email accounts on your mail server. I've found that by using mail. instead of the x.prod.y.secureserver.net, I often have to configure the SMTP (outbound) for my email clients to "accept all certificates". This seems to indicate that the server is presenting the default (Starfield) certificate rather than the Let's Encrypt certificate despite the email clients being configured to contact the server via the mail. domain name. If I just configure the x.prod.y.secureserver.net as my SMTP (outbound) server in my email clients, I do not need to "accept all certificates".
I suspect this may have something to do with ensuring that the SPF TXT records that GoDaddy automatically creates will work without customization.