Preserving the format of an email address (see RFC 5322 § 3.4.1) when encrypting it is quite easy. All you have to do is encode the ciphertext in base64 and prepend it to something like @a.invalid
if you want to make sure that it cannot be resolved even by accident. This results in emails like this:
3IPRr5/[email protected]
That is a technically valid email address for a non-existent and non-resolvable domain.
Note that this does not preserve the length of the plaintext. If you wish to do that as well, you could use a dedicated FPE mode of operation as per NIST SP800-38G. Unfortunately, that would likely result in an email address that is invalid due to the fact that the format specified in RFC 5322 is too complex for it.
While not strictly FPE, you may be able to get what you want by using a Vigenère cipher with the key generated by a secure stream cipher, such as ChaCha20. The set of characters in the Vigenère key must be valid for that atom of the address. You must of course skip the @
. This will preserve the length. Note however that it requires a more complicated construction as fgrieu pointed out, notably due to the fact that the IV would need to be stored separately or a unique key must be used for each email.
.invalid
$\endgroup$@
leads to a different (often inexistent) mailbox. RFC 5321 prescribes:The local-part of a mailbox MUST BE treated as case sensitive.
Fact is email address syntax is horribly complex, variable (in particular, RFC 6531 supports UTF-8); plus it often is not implemented as specified. Until you define with precision what's acceptable as plain and encrypted email address, this question is not answerable as a crypto question. $\endgroup$