Two domains can look identical in a form field and behave completely differently at the SMTP layer. One accepts mail to a specific list of addresses. The other accepts mail to anything, including addresses that have never existed. That second kind is a catch-all, and whether it is a feature or a red flag depends entirely on who is asking.
What catch-all actually means
At the SMTP layer, the receiving server decides whether to accept a recipient. A strict domain accepts [email protected] and rejects [email protected] at RCPT TO. A catch-all domain accepts both, then decides later where the message goes — usually a single mailbox, a database row, or a routing rule.
For a disposable mail service, catch-all is not optional. If a user can mint any local part on demand, the domain must accept mail for local parts that did not exist when the message was sent. Enforcement happens at ingest, not at RCPT.
Why it is diagnostic
From an abuse-prevention angle, catch-all behaviour is one of the cheapest signals available. A verification flow that sends a message to a randomly generated local part and gets an acceptance gets information for free: either the domain is a catch-all, or that address genuinely existed. A domain that accepts everything is a domain where identity is not attached to the address.
Combine that with two other checks and the picture sharpens considerably:
- MX lookup. Does the domain accept mail at all? No MX and no A record fallback means the address can never receive anything, and the signup is guaranteed dead.
- Blocklist membership. Is this domain on a known throwaway list? A hit is a strong prior; a miss is not proof of legitimacy.
None of these three is decisive alone. Together they sort addresses into "certainly dead," "probably manufactured," and "worth verifying properly," which is the useful output. A single boolean is not.
The cost of being wrong in each direction
Blocking catch-all domains outright is the wrong move for most products. Plenty of legitimate infrastructure uses catch-all: companies that route anything@theirdomain into a shared support inbox, developers running their own mail server for testing, and privacy-forward services that generate per-service aliases. Rejecting all of them costs real signups.
The opposite error is worse in a different way. Accepting catch-all without any other signal means an attacker can mint unlimited identities on a domain they control for a few dollars, and every downstream control that keys on "unique email" collapses. The lesson is that email uniqueness is a weak identity primitive and should never be the only one.
Using catch-all deliberately in testing
If you are testing your own product, a catch-all inbox is the right architecture, and Inboxmil is built that way: a plan can enable catch-all at the provider level, and the signup flow can send to a generated local part without a provisioning step in front of it. That removes a race condition, because you never have to wait for an address to exist before the message is sent.
The discipline that makes it safe is retention. A catch-all with unlimited retention is a storage liability and a privacy problem. A catch-all with a TTL — 15 minutes for guests, 24 hours on free, up to 720 hours on the largest plan — is a bounded resource. The address disappears and the mail goes with it.
What to tell a user who is rejected
If a service refuses a catch-all address, the useful message names the reason instead of hiding it. "This address cannot receive mail" and "this address belongs to a disposable service" are different errors with different fixes, and collapsing them into one opaque rejection teaches the user nothing. The same principle applies in reverse: a disposable mail service should be clear that its addresses are for testing and will be refused by services that require a durable identity.
The takeaway
Catch-all is a routing decision that doubles as an identity signal. Build it into your own testing flow because it removes provisioning from the critical path, bound it with a TTL so it cannot become a liability, and do not treat it as proof of anything when it appears on the other side of a form.