DELIVTERMS: Catch-all

It's time for another installment of DELIVTERMS, the deliverability defining series here on Spam Resource where we break down all those confusing technical terms related to email technology, spam filtering and deliverability. Today, the term we are defining is: Catch-all.

What is a catch-all? A catch-all is an email configuration where you tell your email server to accept all mail sent to any address at your domain.

Let's say you have the email domain solarmora.com, and the only valid email address, the only valid user for the domain, is bob@solarmora.com. If somebody tries to email chris@solarmora.com, that email attempt will be rejected. It'll bounce back. The sender might even receive an NDR. But if you enable a catch-all email configuration for your email domain, and you tell it to accept any mail to any address and deliver it to Bob's mailbox, then mail sent to chris@solarmora.com will not bounce; instead, it will get delivered to Bob.

Sometimes you might want to create a dedicated mailbox to store and hold all of the email messages sent to any other non-registered address in your email domain. You'd call that mailbox a catch-all mailbox or catch-all address.

Accepting mail to any address at your domain via a catch-all can have both upsides and downsides.

Upsides include:

It's an easy way to redirect mail when people leave your company or organization, and you want to make sure that no important follow up email is missed, for example, when it comes to incoming email invoices that might have been previously handled by somebody who has now left the organization.
If you're a bit of a "one person show" you can easily invent individual email aliases for various purposes, without any prior preparation. Meaning if your email domain is really just you and only you, and if you're helping a friend test their signup form on Tuesday at 4pm, you could just submit tuesday4pmtest@solarmora.com as your email address, knowing that your "catch-all" email configuration for your domain will result in that mail getting forwarded to you, even though you didn't previously configure this email address in your email domain configuration.
You can do something very similar for companies you do business with, or with newsletters you want to sign up for. Give them different addresses at signup, knowing that you could perhaps filter mail from them (or even reject it) later, if they fail to honor an unsubscribe request, or if a particular email address leaks to spammers and you suddenly start getting spam mail to one or more of your email aliases.
If you're like me and do a lot of different email testing as part of email marketing or deliverability consulting, sometimes it's necessary to sign up for an email automation series multiple times, to test a signup process, segmentation scenario or drip campaign execution. I always submit different email addresses each time I test, in case I need to override a system's prohibition against running the same address through an automation series more than once.

Downsides include:

You'll potentially get more spam. Random jerks do try to just send spam to random addresses at various domains. But, depending on your email system's configurability, you can block that mail. I do this in Google Workspace; if somebody starts spamming me using a unique email address, it's very easy for me to configure email routing for that address so that any future attempts to mail that address are rejected. It's like spam filtering, but instead of blocking the sender, you're blocking specific attempts to send mail TO a specific address or alias.
People attempting to send mail to your domain will not get a valid rejection response (for example, an NDR would not be sent back) when trying to mail a non-existent address. Meaning if somebody accidentally emailed blob@solarmora.com instead of bob@solarmora.com, the mail to blob@ would get delivered to whatever address is configured in the catchall configuration. That could be a good thing, or it could be harmless, or it could be a privacy nightmare, depending on the size and nature of your organization.
External services attempting to verify the validity of email addresses at your domain using SMTP verification will struggle, as your mail server will never provide a negative response. This could be a feature or could be a bug, depending on your opinion of email verification providers. Nevertheless, the cat's already out of the bag on this one, as I found over the past few years that "catch-all" email domain configurations are very common in the world of business email.

How does one configure a catch-all email address or catch-all email routing?