I could very well be wrong on this, but a cursory inspection of the RedirectFallbackMiddleware class gives me the impression that it supports a “cross-site” redirect. In other words, the new_path field could contain a value like https://example.com/contact-us. (Should be rather easy to test…)
Depends upon what you mean by “valid”. In this case, “valid” simply means that something resolves the name contact.example.com to your IP address handling those requests, and so allows your browser to issue an HTTP request to that name - or that there is a proxy or some other traffic-management device that will translate requests to a different name to that name. (Django needs to receive that request as being sent to contact.example.com, however that happens.)
If the request is to contact.example.com, then the current site is contact.example.com, and that’s what you would need to have configured in the sites framework (along with example.com and any other sites you want managed by the sites framework).
If you’re looking to completely remove contact.example.com, then yes, you’ll need to look at a different way to manage this. You could possibly handle this at the web server layer (nginx or apache), or you could make your own version of the redirect middleware.
If that’s a question you’re asking, that’s really pretty much up to you. It’s a judgement call, probably depending upon how close your new / clarified question is to what you’ve already posted. If you’re just refining what’s here, then my suggestion would be to add to this thread. But if you’re going in a different direction with what you’re looking for, then I would probably suggest a new thread.