This allows multiple ServerName entries to be valid by tls.Config{}.

A new field for additional server names is most reasonable, to not require changes to existing implementations by people using the tls module.

tls.config.AdditionalServerNames []string

Mail servers like Google offers for your domain name don't do this, and this is why multiple server names are required in the TLS client.

ispapp.co.		300	IN	MX	5 alt2.aspmx.l.google.com.
ispapp.co.		300	IN	MX	10 aspmx2.googlemail.com.
ispapp.co.		300	IN	MX	10 aspmx3.googlemail.com.
ispapp.co.		300	IN	MX	1 aspmx.l.google.com.
ispapp.co.		300	IN	MX	5 alt1.aspmx.l.google.com.

It is not possible for those google domains to return a server name of ispapp.co

The Microsoft domain yourpc-ie.mail.protection.outlook.com does because yourpc-ie.mail is unique in it.

Realize that does mean that all Google hosted email depends on the DNS MX record, meaning the cleartext DNS record can be modified in transit if you have access to a router there and the mail will be seemingly delivered to any mail server.

CC @golang/security

I'm not sure why you'd need a multiple servernames, or what that would even mean?

The mail protocol is higher level than individual TLS connections: you look at the MX records, choose one result, and resolve the address for that and make a connection. You don't connect to a single server expecting it to answer to all names listed in the MX records for a domain.

@seankhliao

The server chosen to connect to is yourpc-ie.mail.protection.outlook.com.

That server returns ServerName spamfilter.yourpc.ie as you can read in the error message: x509: certificate is not valid for any names, but wanted to match spamfilter.yourpc.ie.

Here's how Microsoft allows you to configure that with *******.mail.protection.outlook.com:

https://learn.microsoft.com/en-us/exchange/troubleshoot/email-delivery/office-365-notice

When making a SMTP connection to yourpc-ie.mail.protection.outlook.com and executing the STARTTLS command after the required initialization SMTP commands in the order defined by RFC 5321, the ServerName returned is not that of the host connected to but spamfilter.yourpc.ie.

@seankhliao

As @seankhliao said, you're supposed to figure out what name you're connecting to before you start the TLS connection, either through the STARTTLS protocol or by selecting a specific MX record.

This can be implemented in the application, I don't think we should add support for it in crypto/tls.

(Also, note that you seem to have bigger problems, since the error message says "certificate is not valid for any names".)

That's not true.

Gmail provided by Google Workspaces uses the TLS certificate of the host you are connecting to aspmx.l.google.com that is returned as one of the MX records of a domain.

The truth here is that Google and Microsoft are doing different things as email providers for different domains.

There's no way to figure out what name you're connecting to before you start the TLS connection. The only possibility is to provide the list of valid names or fail and connect multiple times.

It makes more sense to have a list of names than to open multiple connections.

@FiloSottile

@FiloSottile you should understand what I say, it will help you to learn the reasons reconnecting again and again cause location to be relevant.

If I am here, on Earth... I need to do DNS lookups from each continent at least to ensure that these DNS records are valid anytime that the TLS certificate isn't that of the domain that the email is being sent to.

That's a reality with large companies hosting email for other domains.