Catch-all email domains and what they mean for validation

A catch-all email domain is one whose mail server accepts messages for every address at the domain, whether or not a mailbox with that name exists. For validation, that means mailbox-level checks are blind: an SMTP probe for jane@ and one for zz-not-real-8812@ both get 250 OK, so no verifier can tell you whether the address you care about is real. Treat catch-all as "unknown" rather than valid or invalid, and lean on other signals plus an actual delivered message.

How a domain ends up catch-all

Catch-all is a routing decision made by whoever administers the domain's mail. Mainstream hosted mail makes it a few clicks. Google Workspace, for example, documents it as an admin routing rule: send misaddressed mail to a catch-all mailbox, where you pick a user or group and apply the rule to unrecognised or inactive accounts. Self-hosted servers and many domain registrars' email-forwarding products offer the same thing as a wildcard forward (*@yourdomain.com goes to one inbox).

People turn it on for reasons that are mostly sensible:

• Small companies don't want to lose a customer's email because someone typed sales@ when the address was hello@.
• Departed employees. Mail to former.engineer@ still lands somewhere instead of bouncing to a client.
• Individuals with vanity domains use catch-all as a home-made alias system: netflix@me.dev, bank@me.dev, one inbox.

There is a second, less visible group: domains that look catch-all to a probe without being configured that way. Some mail gateways and filtering services accept every recipient at the SMTP stage and only look up the mailbox afterwards, sending a bounce later. RFC 5321 section 3.3 allows this, calling it a "subsequent failure". The probe sees the same 250, and the outcome is the same uncertainty. We go through why probes mislead in SMTP mailbox verification limits.

How verifiers detect it

The test is simple, and you can reason about any vendor's "accept-all" flag once you know it:

1. Connect to the domain's MX host and start a session as you would for a normal probe.
2. Issue RCPT TO for an address that cannot plausibly exist, typically a long random string.
3. If the server accepts it, label the domain catch-all. Any 250 for the real address is now meaningless.
4. If the server rejects it with 550, the domain does at least some recipient checking, so a 250 on the real address carries a bit more weight.

Two things follow. First, it is a domain-level property, so cache it per domain, not per address. Second, the detection is itself probabilistic. A server that defers unknown senders with greylisting, or rate-limits the second RCPT, can produce a wrong label either way.

pingutil does not do this. We don't open SMTP connections to anyone's mail server, so there is no catch-all flag in the response. If you need one, it has to come from a verification vendor or your own probe, with all the caveats above.

Why catch-all is so common in B2B lists

If your list is built from business addresses (inbound demo requests, webinar signups, a purchased or scraped list), expect catch-all to be a meaningful slice. It concentrates in exactly the places B2B marketers care about: small and mid-sized companies on custom domains with an admin who flipped the switch years ago. Consumer webmail never shows up as catch-all because the user doesn't control routing on gmail.com or outlook.com.

That's why a blanket "delete all catch-all" rule usually hurts. You'd be removing a real chunk of small-business leads to protect a bounce rate that a careful first send would protect just as well.

What catch-all means for different jobs

The right response depends on why you're validating.

The abuse angle: unlimited addresses on one domain

For trust and safety teams, catch-all matters for a different reason. Someone who owns cheap-domain-123.xyz with a catch-all has an infinite supply of unique, deliverable, confirmable addresses. Every one of them passes a confirmation email. Every one of them is a different string, so email uniqueness doesn't help, and the canonical-key trick from Gmail dots and plus addressing doesn't help either because there's no shared base mailbox to fold them into.

You can't see the catch-all configuration without probing. You can see its footprint in your own data: many signups, each with a different local part, sharing one registrable domain, in a short window, from a domain that isn't a well-known company. That pattern catches catch-all farms and also domains bought specifically for abuse, without needing to know which is which.

Count signups per registrable domain

Group by the registrable domain, not the raw host, or a@mail.example.com and b@example.com will be counted separately. pingutil returns that as domain (eTLD+1 from the Public Suffix List, so mail.stripe.com becomes stripe.com). The reasoning is in eTLD+1 explained. Store it on the user row at signup:

async function classify(email: string) {
  const res = await fetch('https://pingutil.com/v1/lookup', {
    method: 'POST',
    headers: {
      authorization: `Bearer ${process.env.PINGUTIL_KEY}`,
      'content-type': 'application/json',
    },
    body: JSON.stringify({ input: email, skip_enrichment: true, check_dns: true }),
  });
  if (!res.ok) return null; // fail open; don't block signup on a lookup error
  const data = await res.json();
  return {
    registrable_domain: data.domain,
    category: data.category,                       // 'company', 'free', 'disposable', ...
    is_spam: data.verdict.is_spam,
    randomness_score: data.email_signals?.randomness_score ?? null,
    has_website: data.domain_signals?.has_website ?? null,
  };
}

Then a velocity query flags domains worth a look. This is Postgres; adapt the interval syntax for your database:

SELECT registrable_domain,
       COUNT(*)                        AS signups,
       COUNT(DISTINCT email_canonical) AS distinct_inboxes,
       AVG(randomness_score)           AS avg_randomness,
       BOOL_OR(has_website)            AS any_website
FROM users
WHERE created_at > now() - interval '24 hours'
  AND category = 'company'          -- free/edu/gov domains are shared by design
GROUP BY registrable_domain
HAVING COUNT(DISTINCT email_canonical) >= 5
ORDER BY signups DESC;

The threshold of 5 is a starting point, not a recommendation backed by data. Pick it from your own baseline: look at how many distinct people from one real company normally sign up in a day.

Read the output with judgment. Five signups from acme-corp.com in a day might be a team evaluating your product, which is good news; spotting teammates from the same company covers that side. Five signups from a domain with no website, randomized local parts and no prior history is a different story. Same query, different reading. That's why it routes to review rather than blocking.

Practical rules

• Never mark an address invalid because its domain is catch-all. It's unknown.
• Cache catch-all status per domain if you get it from a vendor, and expire it. Admins change routing.
• For signups, confirmation email beats any catch-all check, because it proves the human can read the inbox.
• For list sends, warm up catch-all segments separately and let real bounces decide.
• For abuse, stop asking "is this address real" and start asking "how many distinct addresses has this domain sent us today".