So i have asked before and im gonna ask again with some clarity hopefully…
I have a few virtual servers set up on my instance. I can sign into the webmail.site.com and send and receive mail. I can send emails to the site@site.com address from my gmail for example.
I for the life of me cannot connect to the site@site.com email via Outlook of the Windows Mail client. It cant detect the settings.
My Bind DNS records and cloud flare records all match and i have " Enable mail client autoconfiguration" set to Yes in Virtualmin>Email Settings> Mail Client Configuration
In my experience, Microsoft has always had issues with autoconfig, especially Outlook. Just as a test, use a different client like Thunderbird and see if it works with autoconfig. If it does, then you know it’s just the typical issues on Windows clients that you need to work on. If Thunderbird doesn’t work either, then there’s probably more to it than that.
I did create a new lets encrypt certificate for the autoconfig subdomain, since my webserver is set to redirect everyone to https. I thought maybe it would be that. But no.
Unrelated: can anyone explain why it autoconfigures to STARTTLS 587?
When I manually configure I tend to use SSL/TLS 465
Is anyone preferable?
EDIT: I guess 587 should be used. Learned something in the process of autoconfigure
StartTLS on 587 is the default port and has been for a long time. SSL/TLS on 465 was the planned configuration for SMTPS back in the mid 1990’s, but was already deprecated by… I’m thinking 1998? I remember it was right around the turn of the century.
Although it’s still allowed as a message submission port (with implicit TLS), Port 465’s primary assignment is IGMP for source-specific multicasting.
At this point, I keep 465 available as a fallback in case clients can’t connect over 587 for whatever reason, since the most-common reasons for it not working would be beyond my control anyway. Autoconfig uses 587, and the instructions I give them specify StartTLS over 587. Only if that doesn’t work do I tell them to try SSL/TLS over 465.