First, read what Deer Hunter wrote above. The best way to securely send private keys is to never send them in the first place. Full stop.
That being said, there probably are some circumstances in which you might legitimately need to transfer some private key/s that exist in your hands & and in one location to some one else's hands in another location. You should minimize these times as much as you can, preferably by just walking the client that needs them through generating the keys themselves. But there may be some times when that's not practical for some reason (or, more likely) it's not your call to make. So, what do you do then?
Well, you do what governments and tech firms do when they need to distribute very sensitive encryption keys (if most often in symmetric or even in one-time pad key distribution scenarios, rather than with asymmetric private keys) out to a remote location: you:
(1.) Encrypt the hell out of the key/s to be transferred before it/they ever leave your facilities, using a unique "outer" key created only for one transfer and then destroyed. If that protective encryption key is generated from a password or pass-phrase, the password or phrase meets very high strength requirements.
(2.) Use a channel with much better security than existing, general-purpose networks--aka the Internet!--to get the encrypted package to its destination. Physical delivery of a memory device containing the encrypted key is the simplest but not always most practical channel.
(3.) Keep the "outer" key that unlocks the protective encryption (or a password/passphrase that forms the basis for the key) in your possession until it's time to transfer the key/s you want to transfer and then decrypt them at clients's location. That means either you being at the key transfer event in person to decrypt the protective encryption, or sending the key that unlocks the protective encryption using another, independent high-security electronic channel to get it to client's place at decryption time.
(Why not just skip to #3 and send the original private key you need to move to the client by that highest-security electronic channel? Because we don't trust any one channel, not even what we think is one that has especially-good security, nearly enough to handle info like a private key. We make a possible opponent intercept at least two channels/mechanisms of transfer, and we make it difficult to intercept anything useful from either one, let alone both.
Now, that all sounds arduous and complicated. But in reality it doesn't at all necessarily need to be either. (Assuming we're in a common, this-key-is-important-but-it-wouldn't-be-truly-catastrophic-if-it-was-compromised situation.) For example you could:
-Use a well-regarded hardware-encryption protected USB device--no lack of options out there-- for transport. Write private key to that, lock it with a unique strong password/code/phrase, and drive it across town to client's location that needs the key. Plug it in when you get there, unlock it, and copy the private key to client's system.
-Grab a new (not previously used) ordinary USB stick. Use a software program you have strong trust in to encrypt the private key in a file. Transfer file to the USB. Then double-check USB--just to be sure-- that the only thing on it is the now-encrypted package. Do registered mail or FedEx to get it to client's site. When it arrives, use Off-the-Record or a similarly-security messaging app like it to convey the key to the protective encryption (or password/phrase needed to re-generate it) to client, who then decrypts & gets the private key.
-Need to be able to repeatedly distribute keys to a client, on-demand and electronically? Encrypt private key in file as in last example. Have a simple-but-secure VPN or SSH-access server that you only use for encrypted key file distribution, that client have pre-shared auth information to login to, and that you normally keep disconnected from any remote access. When client calls you and tells you he's ready to receive the key, transfer it from your internal storage environment to the server. Enable remote connections to server from client's ip address. Client connects and grabs encrypted key file. Finally, you then use high-security messaging app (or whatever) to transfer the protective key to your client.
Lots of options. It's true that there's some work involved in each if you want the transfer to be well-secured. Turned-off by the prospect of doing the work? That's understandable. In that case, see point #1 (the original point Deer Hunter made): create a technological arrangement where you don't need to transfer private keys at all.