RFC 6066 defines Server Name Indication as an extension, whereby virtualised web servers may be given an SNI extension in order to know which certificate should be presented.
It has the following to say about cases where the indicated server name does not match a known name (emphasis mine):
If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert or continue the handshake. It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because the client's behavior in response to warning-level alerts is unpredictable. If there is a mismatch between the server name used by the client application and the server name of the credential chosen by the server, this mismatch will become apparent when the client application performs the server endpoint identification, at which point the client application will have to decide whether to proceed with the communication. TLS implementations are encouraged to make information available to application callers about warning- level alerts that were received or sent during a TLS handshake. Such information can be useful for diagnostic purposes.
What is the potential security impact of continuing the handshake when an invalid SNI is sent? I'm particularly thinking about cases where an entirely different domain is provided, or an incorrect subdomain. What is the compatibility rationale behind not rejecting such requests? My limited testing showed that sending "microsoft.com" in the SNI field to a TLS service on google.com didn't reject my content, whereas doing the same to a CloudFlare-enabled service caused the fatal alert.