Good Idea to Split Closely Related/Dependent Business Logic into Separate Classes? [closed]

Please excuse the vagueness of the question. It's difficult to put what I am asking into words - an example would help...

In my project I have the following class:

public UserService {
   private readonly INotificationService _notificationService;
   
   ...

   public void CreateUser(CreateUserRequest data)
   {
      ...
      _notificationService.SendUserCreatedNotification(user);
   }
}

So as you can see I have a UserService that has a method to actually create a new user. It then calls a NotificationService to send a "notification" that a user has been created.

However, something about this makes me feel uneasy.

I could do this by mistake...

_notificationService.SendUserCreatedNotification(userThatWasntJustCreated)

...and nothing would "break" or "complain".

The NotificationService trusts, and only works properly, in the case that the user that is passed into it has in fact been newly created, but the NotificationService has no way to check that. The logic in that class depends on external state (that the caller is passing a user that was actually just created) and that makes me feel uneasy.

Is this a code smell? Am I justified in feeling uneasy about this?