See if this article points you in the right direction. It explains restricting ticket creation through email by email domain.

Unfortunately, these are users creating the tickets directly within the portal. They have the ability to edit that Requester/Request For field and are putting in emails that don’t currently exist in the system. I know this is intended but the hope is to lock this down within the portal itself to only allow them to select from the list of users we already have imported and prevent anything else.

​@Christian.Schickler  - Do you mean someone can only select an existing user from a list on a form when submitting a ticket?

then you would use a Drop Down, select look up the details, and select the source as “All Users”, then they will only be able to select existing users. 

If you have as screen shot of the bit your trying to control, that will help us understand more 

​@Roxwell are you sure about that?  If so that would make such a difference in my environment, we use the requesters as the data source and people can literally put whatever they want as long as it is an email address and it creates a fake account (which then fails and i have to clean up)

​@Roxwell when reporting an incident or a service request, I’m looking at the built-in Requester/Request For fields. These fields do appear to being using All Users as a source, but they also allow any email to be entered. As ​@ITMike mentioned, this creates fake requester accounts that need to be cleaned up. The hope is to only allow users from the All Users source and prevent anything else.

Is the issue “Fake” accounts, or preventing someone from selecting the wrong one?

If the issue is fakes, then I would lock down the access controls. If it’s preventing mistakes, Selection should be good enough, surely? 

​@Christian.Schickler - This might be fixed in this release with the enhancement to business rules

​@Roxwell Nice find! That’s huge. I appreciate you for sharing this information.