Yes, the Radix Protocol applies some limits so that a validator cannot quickly raise their validator fee % without their delegators (the token holders who delegate XRD to a validator) noticing that their emissions rewards are being reduced.
When a node-runner registers as a validator, they may set their validator fee % to anything they like - 0 to 100%. This will take effect at the start of the next epoch, when the network first considers the node as a validator for inclusion in the "top 100" validator set.
After this, validator node-runners may submit a change of validator fee % at any time. If the new fee is lower than the previous, it takes effect at the next epoch. If it is higher than the last, a delay is applied in epoch time, equalling 500 epochs, or between 1 - 3 weeks, depending on how quickly the network is producing “rounds”. The new higher fee will be visible on the Radix Explorer and to current delegators during this time. Delegators will continue to be credited with emissions based on the previous fee while deciding if they would like to remain staked.
Also, the Radix Protocol prevents raising the fee by more than 10% (absolute) at a time. For example, increasing the fee from 1% to 12% would require two sequential 500 epoch delays (again, approximately 1 - 3 weeks for each of the two 500 epoch delays). So if you intend to run a validator with a 100% fee (likely because you will be your node's only intended staker), ensure you do this on first registration rather than setting it lower and having to raise it slowly later.
Any validator fee emissions from the node will be credited to a special "owner address" specified by the validator node-runner. The node-runner should set this owner address to one they control, such as an address created in the Radix Desktop Wallet. For security, it is strongly advised not to set this address to the node's own address. This address is also the address the node-runner should use to stake to their own node if they turn off the node's "allowExternalDelegation" flag.
Further reading: