I started a while ago to use a catch-all email address. This got me thinking, can you have a reversed catch-all address? That is to say, can one send an email with any "local-part" without generating an account for it?

[email terminology: [email protected]]

To put up an example.

Let's say that I have set up a catch-all email address; [email protected]. That would mean, that any email sent to an email address which I have not registered with my host-provider would arrive at [email protected].

Thus, I sign up to a random website, with a "non-registered" "local-part" and that email is [email protected]. This would mean that any email sent to [email protected] would be forwarded to [email protected].

Now, what happens if I want to send an email from [email protected]? The only way I know, would be to go into 'my-host-provider > emails > manage' and create an email account for [email protected].

So, with the infinite wealth of knowledge here in SuperUser, do you have any ideas?

If this is possible, I do assume it will partially depend on which host-provider and email-client I am using.

  • Conceptually there is not a problem with this - the question is if/how this is imllemented in the mail client. My (Roundcube) webmail client will pick up the recipient, and when replying can set that recipient as the sender. It also allows me to set up alternative from addresses and also entirely edit the sender on a per mail basus.
    – davidgo
    Commented Mar 18, 2023 at 13:16

1 Answer 1


That's really nothing special, catch-all or not. Every IMAP/SMTP mail client allows you to specify a "From:" name and address that are different from the SMTP username (when configuring an account you are asked for both separately), as functionally SMTP authentication is already separate from the identity information, so you can just do that and configure something like an "alias" in your email app. In fact, some clients such as Thunderbird even let you edit the "From:" header on the fly while composing a message.

The only question is whether your SMTP server checks the "From:" header – it may insist that the From address matches the SMTP username, or it might not. It depends on the mail provider's SMTP configuration.

(Some systems, such as Hotmail, will just quietly replace any custom "From:" name with the one from your account, but this is rare – most systems either explicitly refuse the message or don't bother checking at all.)

  • That's nifty! Thank you! I just tried it out and did sent an email to myself with an alias. However, this got sent directly to the spam bin. I assume this is because it gets an invalid signature where the private/public key does not correspond, and thus gets put in the spam bin. Is there a way to create aliases where you'll have a valid signature in order to not get sent to spam?
    – FoxPaw
    Commented Mar 19, 2023 at 17:02
  • Valid signature of what type? If you mean DKIM, that's up to the server – practically all setups use a single DKIM keypair for the entire domain (with the server signing anything that comes through an authenticated "client SMTP" session). Commented Mar 19, 2023 at 17:09
  • What type of signature... honestly, I don't know super much about the email headers so that was just a guess. So, do you have any idea why then, my test email got sent to the spam bin? I did send it with an alias that matched my domain. And do you have a possible solution for the problem? (If I were to send the email without the alias, it would show up as usual)
    – FoxPaw
    Commented Mar 19, 2023 at 17:38
  • Check whether there is a DKIM-Signature in the headers, and whether they contain anything that would indicate validation failure from the receiving server, or anything resembling a spam filter's reports. Send two messages, one from an alias and one normally, then compare their sources side-by-side to see if there are any differences. Commented Mar 19, 2023 at 17:42
  • I checked the differences and this is what I got: the valid got under X-Microsoft-Antispam-Mailbox-Delivery: dest:I; wheras as the junk-sent had a dest:J; OFR:SpamFilterAuthJ. Due to lacking MC docs, what these parts exactly means are a bit uncertain. ORF seems to be some sort of custom ruling. Anyhow, I did try to another alt email address (google this time) and both the alias and the 'real' email-address went through fine. Which is to say, I'm happy enough. Thank you so much for both your time and help! This little rabbit hole as expanded my little knowledge of emails a lot!
    – FoxPaw
    Commented Mar 19, 2023 at 19:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .