Well, current SMTP specifications allow for anyone to use any domain
in either the rfc2821 identities, or any place in rfc2822. All
authentication schemes intend to change that.
AFAIK, none of SSL, TLS, or SMTP AUTH make any such change.
well, it depends on what you mean by "being able to use any domain"
for instance, SSL/TLS server certificates do not allow the server to
[convincingly] claim to be any domain it wants to be within the SSL/TLS
protocol. they don't try to restrict the server's domain name
according to the IP address, and they don't inherently impose
constraints on what domains the protocols layered over SSL or TLS use.
what they do is allow a server to convincingly claim to be a domain -
if the client trusts the CA in the server certificate.
similar limitations apply to client certs.
whether it's appropriate for the higher-layer protocol to expect its
domains to match those in the SSL/TLS certificates varies from one
protocol to another. in the case of email, it's generally not
reasonable for an SMTP client or server to expect the domains in EHLO,
HELO, MAIL, or RCPT to match those used at the SSL or TLS layer,
because third-party relaying is an extremely useful feature of the SMTP
architecture.