In order to know that you are giving the encryption key to the right person, you'll need to work out some form of authentication that tells you the receiver is who you think they are.
This can often be done with PKI - the receiver can signup with a certificate provider, verify his credentials, get a signed certificate and send you his certificate. The certificate will include a public key, which (if configured correctly) can be used as an assymetric encryption key. Encrypt the symmetric encryption key with the receiver's public key and send it to him. He can then use his private key to decrypt it. As the only person who holds this private key, he's the only person who can get the encryption key for your message.
The limitation here is that your point of trust (the PKI certificate provider) is only as good as the authentication mechanism. If your colleague lives in an igloo in the North Pole and can't have any contact with humans, his means of authentication will be limited to the stuff he has with him in the igloo - presumably his Internet connection and his wallet. He may be able to send a scan of a driver's license or passport, or physical copy of his signature. He may know some information about himself that only he could know. That will qualify him for a low-end sort of PKI (I believe, for example, you can get a certificate from GoDaddy under these conditions). Other forms of certificate provisioning may require appearing in person to a qualified agent who will verify that you look like your passport, and that other means of verification are approved. That works fine for a regular situation where you and your colleague may not be able to talk out of band, but your colleague isn't necessarily in an igloo.
Protocols like TLS can also work - it's using a handshake with a key exchange that allows secure communication between two points - the only challenge is knowing for certain that you have made a TLS connection to the recipient and not a man in the middle.