If storing previously used email addresses was a critical business requirement, I'd implement a dedicated service to fulfil that requirement. The service would run on its own dedicated server hardware and operate in a similar way to a hardware security module (HSM). The idea is to have the service as a separate component with a bare minimum attack surface, so that even if an attacker compromises the web server they can't just recover the full "previous users" list.
The service would expose three externally-facing API calls: add, check, and remove. The add API would take the hash of an email address and add it to a database table along with the current timestamp. The check API would take the hash of an email address and return true if the hash is already in the database, otherwise false. The remove API would take a hash as an input and remove it from the database if it is found; this function would allow support staff to clear an erroneous entry. Finally, the service would have an internal process that removes entries older than a specific age. After this period the email could be used again, so the exact length of time is ultimately a question of what the business will accept, but it also minimises the impact of a breach.
As for the hashing itself, I'd use Argon2id with a static salt. The static salt prevents generic precomputation (i.e. a non-targeted database of hashes of email addresses), and Argon2id is designed to be slow to brute-force even with GPU acceleration. If an attacker gets access to the database that stores the hashed email addresses, and the salt, they will be able to check whether specific email addresses are in that list, and they will eventually be able to check a whole dictionary of known email addresses, but the process will be far slower than with a regular hash like SHA256.
The service could be implemented with a REST API over HTTPS, using client certificates for authentication. Rate limiting and alerting should be used to prevent an attacker who compromises the web server (or whatever other server consumes the service) from spamming it with thousands of email addresses to see if they are present.
The system itself should be locked down to present a bare minimum attack surface. Full-disk encryption should be used (this should be standard operating practice anyway), the host firewall should use a default block policy and only allow traffic from systems that require it, network firewall rules should replicate those rules for defence in depth, unnecessary services should be disabled, management interfaces (e.g. SSH) should be kept on their own isolated management network and be configured securely (latest protocol version only, no password logon, no remote logon for root, etc.), monitoring & alerting should be deployed, patches promptly installed, and all the other usual security hardening steps.
The question of whether you go to all this effort depends on how sensitive you (and your customers) consider the past registration status to be. That's ultimately a business decision.
The rest of the problem is one of communication and law. Make it clear in your terms of service / privacy policy that your systems log the minimum information necessary to prevent abuse, in exactly the same way as you'd keep web server logs with IP addresses in them for that purpose. Be clear about the maximum retention period of the information you store. Users will still be upset if their information is breached, but in my experience they're far less understanding if you surprise them with unexpected data retention that wasn't publicly documented. You may also want to consult a legal professional to determine the specifics of your statutory obligations in terms of privacy laws (e.g. GDPR, DPA, etc.) in your operating jurisdiction, particularly in relation to "right to be forgotten" laws and how they affect your intended goal here.
