> Which one is giving trouble there?

Probably all of them.

Section 5.4.3.1

  > The receiving entity SHOULD choose which certificate to present
  > based on the domainpart contained in the 'to' attribute of the
  > initial stream header (in essence, this domainpart is
  > functionally equivalent to the Server Name Indication defined for
  > TLS in [TLS-EXT]).

and 13.7.2 says

  > Once the identity of the stream peer has been validated, the
  > validating entity SHOULD also correlate the validated identity with
  > the 'from' address (if any) of the stream header it received from the
  > peer.  If the two identities do not match, the validating entity
  > SHOULD terminate the connection attempt (however, there might be good
  > reasons why the identities do not match, as described under
  > Section 4.7.1).

You can manually set a server in most clients, and I don't know how that is generally implemented. I guess that should work then.

But if you serve a certificate for jabber.example.com for a user trying to connect to an account user@example.com using SRV records then that mismatch will give you at least a certificate warning popup. And for good reason too: How would a user verify that a certificate

abcde.1234.jabber.freshhosting.donut

is valid for the account joe.doe@example.com ?