I don't believe this is actually an emoji issue as such. It's about (a) different devices having different fonts installed (emojis are, O disgust and horror, a whole Unicode sector, notably 1F600 through 1F64F but also some others) and (b) though less common nowadays, different browsers having different Font Substitution skills. (MSIE has historically been the most grossly inept and backward in this area.)

Amusingly enough I just recently met an almost identical problem from the other end. I made an ebook of a text from 1841 that included a long list of astronomical symbols, most of them in the 2600-26FF area. It was a nasty shock to discover that certain built-in fonts don't display them as ordinary, dignified-looking, black-and-white letters but as colorful 3D emoji. So I had to do The Bad Thing and instruct the document to use {list of exact fonts} if it possibly could, just so this one article would not come out looking utterly ridiculous.

Sure, you can import a font. If so, I recommend editing it down to just this group of characters, so users don't have to download a multi-hundred-kilobyte file when all it's supposed to be used for is emojis. But then you'll get the users who don't want brightly colored emoji jumping out at them. I assume you've eliminated the idea of treating them like smileys with a one-on-one substitution: in the same way that typing ":-)" yields your forums's chosen happy-face, typing #&x1F600 by itself could yield some other resident smiley.

In the database, they show up like:

That's characteristic of multi-byte characters stored in a one-byte character set. If your users typed plain text in Russian or Chinese, it would look equally alarming. Some quick experimentation confirms that if I enter some basic emoji and then reinterpret as ISO-Latin-1, what I mainly end up with is ð (eth).

There are services that provide just the block(s) of Unicode characters used for emojis. For WP I see s.w.org embeds via json as though every WP site invites their use. Similar to Google fonts, they are "embedded" requiring users to download some extra bytes. I have no recommendations for that, but if you look around there is likely a compatible service. The users' devices will show them differently depending on their OS and browser though they are fairly standardized for intent. IE/Edge might still be dodging their implementation. They never liked Unicode, seem to be waiting for it to go away.