The same is true for classical PGP keys with e-mail addresses: if you have your mailbox on some server, and if you have your public key posted in some keybase, what if those entries will be manipulated? You cannot stop mailbox provider from sending fake e-mails that will be poorly verified by inexperienced users. And you cannot stop keybase maintainer from sending fake PGP key, fully controlled by them, if the end user will not double-check that a keybase is no longer trusted.
1. You can wrap your public key in your e-mail. For example, in Tor, there are those long names with 56 characters. You can also use shorter names, and introduce any kind of hashing, like it was with SHA-1 truncated to 80-bit for old names with 16 characters, then the size of the name is determined by the hashrate of the attacker.
2. Using any NameCoin-like solution will work. Blockchain-based names will be bulletproof, but then, your users will have to download and verify the full list of all names (or use a third party to do that, and then it will bring us back to the starting point).
3. Your server could be a proxy for Silent payments. Then, sharing a single public key is needed, and your service could be used for scanning addresses, and providing any kind of SPV proofs for users. Then, you can only leak connections between addresses, but you cannot change them, if you cannot control them, and if you only know about "the current thing to find on the blockchain".
4. User-based puzzles will also work. For example, if your user knows that "SHA-256(pubkey||secret)" starts with N number of zero bits, and you don't know the "secret", then you cannot generate a fake address (because it would be as suspicious as brute-forcing someone's PIN). And then, users can safely share that "secret" and "algorithm" combination, that can be shorter than "pubkey". It is the same as salted passwords: if sharing the full public key by sharing 56 characters like in onion addresses is too much, then sharing a shorter "secret" is possible.
But all of those add a shit ton of complexity. It would have to be something that is transparent for the user and simple (for people who might not understand how everything works) to verify.
As I said it was just an idea I was kicking around. Since in the end you would have to trust the person running the domain and the web-server I do not see a simple way of making sure the LNRUL is actually the one that should be there without adding a way for people to check it, which in theory means trusting someone else not to be in cahoots with the person running the service. Gets back to not your keys -not your coins. But it's not your domain - not your email.
-Dave