You're mentioning encrypting the email and digitally signing it. These are two different things which, although they both can be used in your case, have different practical outcome: by using encryption, you're hiding the encrypted data from view (the email address).
That being said, in theory, your scheme should work fine. In practice, however, i would shy away from such a scheme:
- Most public key encryption (or digital signature) algorythm generates big results: too big to comfortably fit in a query string. Or rather, it might fit in the maximum size allowed by most browsers but probably not in a single line of an email which will be inconvenient for your users.
- Your scheme creates a single point of vulnerability: once the private key is compromised, all future transactions are tainted. If you use the regular "random key in a DB table" approach instead, you do not have this single point of failure: an attacker would need to compromised the existing DB to crack the system.
- Your scheme is trading a trading a bit of DB space for a quite a lot of complexity in your code, increasing the attack surface and, potentially, leaving you vulnerable to a DOS (since public key validation is quite not exactly as cheap in CPU and memory as a DB lookup).
So, unless there is a real business case for it (for instance, if there is a strong need to be able to validate a query without reaching the database), I suggest you use the more common approach.
I'd like to add: generally speaking, I like to stick to the KISS principle with my software. Given two ways of achieving the same result, I try to stick to the one that requires the less code.