When attempting to verify e-mail addresses, I frequently come across servers configured to "catch all" requests (as is the online terminology for the situation). I'm surprised that this is common, because it seems like they are wasting bandwidth and disk space to accept and/or store messages bound for potentially non-existent addresses, which nobody shall ever see.

Obviously, this differs if the mail server is a honeypot, but I've not encountered one of those yet, and the rationale is evident in that circumstance.


An example is an EmailHippo result for mailTo:[email protected] - an e-mail address for a hotel. Because RFC 5321 states that local parts are case-sensitive, I wanted to verify that "Info@" was what they meant to put on their contact page rather than an entirely lower-case variant, as is more standard.

  • 1
    I have never experienced the name (first part) being case sensitive. This may be mail server dependent and bad practice. This has nothing to do with catchall. Apr 13 at 20:07
  • @RohitGupta, I explained why it related: Per stackoverflow.com/revisions/9808332/…, they are case sensitive, by the standard. The sole exceptions are Outlook and GMail. Relevantly, in order to verify the e-mail address, the server needs to reject invalid addresses. Apr 14 at 13:21
  • Your assertions about case sensitivity are incomplete. While RFC5321 does say that that the SMTP command is case sensitive, it then immediately goes on to say "However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. " - Most MTA's do not exploit mail sensitivity as a result.
    – davidgo
    Apr 14 at 22:41
  • @RokeJulianLockhart email addresses are not case sensitive in cpanel/dovecot either. The username will be left as typed and the domain is converted to lower case before the message is delivered.
    – Steve
    Apr 15 at 1:13
  • 1
    One other thing about catch-all emails. It is tempting, but don't do it. I had catch-all enabled for a while and would create email addresses on the fly e.g. [email protected]. Then they would get spammed to death and I couldn't shut them down because a) there were so many and b) I needed them to be active. Don't be like me.
    – Steve
    Apr 15 at 1:14

2 Answers 2


It is not certain that catchall is indeed enabled. The mail could be accepted by the MX but relayed to another server where enhanced checks will take place. At that point the mail could bounce or go to trash silently.

I suppose you are doing command line testing of the SMTP server, without committing a mail message. So you don't get past that first server.

Also, there is often more than one MX for a domain name. Each MX may be different and they may have different configurations too.

The bottom line is that in order to reject invalid E-mail addresses, the Internet-facing server needs to have some kind of list of current users in the organization. This is not always the case, especially with organizations that have infrastructure split between cloud and on-premises servers.


There are at least a couple of facets to your question:

Why have a catch-all SMTP policy

In organisations, people come and go - having a catch-all can allow for legitimate email that is misaddressed / addressed to an obsolete account to be picked up.

Similarly, some people (looking in the mirror) use this to provide unique emails at whim - which can help to work out where spam comes from and who has been compromised/abused your trust.

Your failure here appears to be the expectation that "no one will ever see" the email. This is not a given as normally catch-all boxes are directed to a default account.

Further, it is not uncommon for mail servers to act as a mail hub/router and forward email on to another server for a whole raft of reasons - among many others are spam filters - it often makes sense for email to be accepted by a spam filter, filtered and if appropriate forwarded on to another mail server - I am aware of businesses who specialise in SMTP spam filtering and forwarding that do just this - and indeed, imagine something like GMAIL requiring to parse an email as the first step of accepting delivery.

About verifying email addresses

I do not believe it is possible to - in the general case - programmatically reliably verify the existence of a particular email address. Although the VRFY and EXPN commands exist in RFC5321, Section 7.3 allows a server to return a 252 response to a request - and this has been standard for as long as I can remember - and I have been doing this a LONG time (indeed before RFC5432 was written)

Probably about the best you can do here is validate the domain and MX records.

  • 3
    Many mail servers seem not to honor the VRFY and EXPN commands these days, because they can be abused by spammers building target lists.
    – Kate
    Apr 15 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.