Catch All Email Hosting Checklist: 8 Things to Verify

Running catch all email hosting means your mail server accepts every message sent to any address at your domain — including ones that don't exist yet. One DNS wildcard record, and nothing slips through. That's the pitch.

Here's what actually happens: the moment you enable catch all email hosting, your server stops returning 550 5.1.1 User Unknown and starts returning 250 OK for every RCPT TO command. Attackers detect this within minutes using Directory Harvest Attacks — automated floods of random prefixes (admin@, invoice@, payroll@, careers@) designed to exhaust storage, map valid addresses, and crater your sending IP's reputation. Cisco's email security appliance flags domains at just 25 invalid recipients per hour as probable DHA targets. A real attack sends thousands per minute.

Your hosting provider may suspend your domain. The legitimate mail you set catch all email hosting up to capture gets buried in a spam flood or silently dropped. Before you flip the switch, run this checklist. Eight items. Miss one and you'll pay for it.

For the full architecture behind catch-all routing — quarantine sinks, PCRE filtering maps, Exchange loop prevention — start with domain catch-all routing without losing control first. This checklist is for after you understand the trade-offs and still want to proceed.

What Catch All Email Hosting Does to Your SMTP Stack

Catch all email hosting modifies your server's behavior at the SMTP envelope layer. Instead of rejecting unknown recipients before the DATA command with a 550 error, the server accepts every RCPT TO and routes unmatched addresses to a fallback mailbox. This shifts filtering from pre-accept (cheap, at the connection layer) to post-accept (expensive, requiring storage writes and spam scoring for every probe).

The practical cost: every spam probe that would've been rejected in milliseconds now generates a queue entry, a spam scan, a storage write, and potentially a Non-Delivery Report. When your server generates NDRs to forged MAIL FROM addresses, that's backscatter — your IP sending unsolicited notices to innocent third parties. Backscatter listings typically take 2–4 weeks to clear and drag down every domain sharing your server's IP range.

This is the core trade-off with catch all email hosting: wildcard routing flexibility in exchange for your cheapest and most effective spam defense — edge rejection at the SMTP handshake.

The 8-Point Catch All Email Hosting Checklist

A reliable catch all email hosting provider must pass eight technical checks: pre-accept SMTP filtering, real-time log access, volume rate limits that protect your account, SRS and ARC forwarding support, dynamic reply identity, backscatter and NDR controls, standard IMAP export, and transparent storage policies. Failing any single one creates operational risk that compounds fast at scale.

1. Pre-Accept SMTP Filtering — Rejection Before the DATA Command

Your provider must filter connections at the SMTP handshake, before accepting the message body. If your host returns 250 OK first and then decides what to do, every spam probe gets stored and every bounce to a forged address generates backscatter by definition.

Pre-accept rejection looks like this in your logs:

postfix/smtpd[1234]: NOQUEUE: reject: RCPT from unknown[192.0.2.1]:
  550 5.7.1 Service unavailable; Client host blocked using zen.spamhaus.org;
  from=<probe@attacker.com>, to=<random123@yourdomain.com>

Post-accept filtering looks like this:

amavis: Blocked SPAM {DiscardedInbound}, [192.0.2.1]
  <probe@attacker.com> -> <random123@yourdomain.com>, Score: 17.2

The second version means the full message was accepted, queued, and processed before filtering happened. That storage and CPU hit occurred for every single probe in the DHA. Ask your provider directly: "Do you filter at the SMTP connection layer before accepting the message body?" If they say "our spam filter handles it," that's post-accept. Wrong answer for catch-all.

2. Real-Time SMTP Log Access

A catch-all removes your bounce signal. When a client says "I sent an email to billing@ but you didn't reply," you can't rely on a dashboard message count. You need raw SMTP logs showing the specific handshake, filter score, and routing decision for that exact message.

This is what useful log access looks like:

Jan 03 10:14:22 mail postfix/smtpd: connect from mail.outlook.com[40.107.100.99]
Jan 03 10:14:23 mail postfix/cleanup: message-id=<20260103.ABC@outlook.com>
Jan 03 10:14:24 mail amavis: Passed CLEAN {RelayedInbound}, [40.107.100.99]
  <client@outlook.com> -> <billing@yourdomain.com>, Hit: -1.5

Google Workspace and Microsoft 365 restrict raw SMTP log access to their admin consoles — and even then, data is often delayed 30–60 minutes and lacks per-connection detail. If your provider requires a support ticket to find out why a specific message failed, they're not suitable for catch-all hosting. The delay will cost you a client.

3. Volume Rate Limits That Protect Your Account, Not Just the Host

Catch-all domains attract volume attacks. Attackers blast thousands of random prefixes specifically because a wildcard accept response confirms the domain is worth probing. This creates a dangerous scenario for catch all email hosting on shared or per-user platforms: the attack volume triggers your provider's abuse thresholds, and your domain gets suspended — not the attacker's IP.

Ask this specific question before enabling a catch-all: "If our domain receives 10,000 messages in one hour from a Directory Harvest Attack, do you suspend my account or throttle the attack source?"

4. SRS and ARC Forwarding Support

This is the most common technical failure in catch all email hosting setups. If you host a catch-all on Server A and forward messages to Gmail or Outlook, you break the authentication chain at two points.

SPF fails: The final receiver sees the forwarder's IP, not the original sender's. If the origin domain publishes v=spf1 ... -all, the message fails SPF at the next hop.

DMARC rejects: If the forwarder modifies the message body (breaking DKIM) and SPF is already failing, a p=reject policy silently deletes the message. No bounce. No trace in your inbox.

Your provider needs both protocols:

• SRS (Sender Rewriting Scheme): Rewrites the Envelope-From to pass SPF at the forwarding hop. Full breakdown in SRS email forwarding: how it works and why it fails.
• ARC (Authenticated Received Chain): Defined in RFC 8617, ARC signs message headers to preserve authentication results across forwarding hops so the final receiver can trust the chain.

Without both, you'll eventually see these errors from Microsoft or Google:

550 5.7.520 Access denied, your organization does not allow external forwarding.
550 5.7.1 Unauthenticated email from domain.com is not accepted
  due to the domain's DMARC policy.

If your provider doesn't mention SRS and ARC in their forwarding documentation, assume they don't support it.

5. Dynamic Alias and Reply Identity

The utility of a catch-all is receiving as multiple identities — billing@, support@, project-2026@. The pain is replying. In Gmail, replying as billing@yourdomain.com when your primary account is admin@yourdomain.com requires setting up a separate "Send As" identity, verifying it via email code, and repeating this for every alias — every time.

Your host should let you create a new reply-from address instantly and use it in your mail client without a verification loop. If adding a new identity requires a support ticket or a 24-hour wait, the operational friction compounds fast — especially for teams managing multiple domains. That friction defeats the purpose of wildcard routing.

6. Backscatter Controls and NDR Suppression

When your catch-all accepts a message with a forged MAIL FROM, then generates a Non-Delivery Report because the fallback mailbox is full, routing failed, or the spam score triggered a discard — that NDR goes to the forged sender's address. That's backscatter, and it lands your IP on dedicated blocklists like Backscatterer.org.

Ask your provider: "For spam-scored messages routed to a catch-all, does your system generate NDRs or silently discard?" You want silent discard for spam. A server that bounces spam probes acts as an open spam relay by proxy. Your domain's sending reputation absorbs the damage even when your outbound mail is clean.

7. Standard IMAP Access and Data Export

Catch-all mailboxes accumulate data fast. If you need to migrate away — because your provider fails this checklist or suspends your account during an attack — you need standard IMAP to pull your mail programmatically. "Webmail only" or proprietary API export means you're locked in.

Minimum requirements:

• IMAP access on port 993 (TLS)
• Export to .eml or .mbox format
• No rate limits that block bulk reads during migration

POP3 isn't a substitute — it deletes from the server by default and doesn't preserve folder structure. IMAP is the only protocol that migrates cleanly without data loss.

8. Transparent Storage Policies and Overflow Behavior

A catch-all inbox will fill up. Know exactly what happens when it does. Does the server reject new messages with a 452 4.2.2 Insufficient storage response — correct, because the sender gets a retry signal — or silently discard them? A silent discard at quota is the worst outcome: your clients' messages vanish and you have no log of the failure.

Also ask whether storage is per-mailbox or pooled across your domain. Pooled storage means a DHA can exhaust 80% of your total domain quota in hours, starving your primary mailboxes. Per-mailbox limits cap the blast radius of an attack. Know the model before you rely on it.

The TrekMail Approach to Catch All Email Hosting

TrekMail charges per domain, not per mailbox. This eliminates the financial pressure that drives most businesses to enable catch-all in the first place. With flat-rate pricing, you create unlimited mailboxes under one plan — jobs@, billing@, support@, archive@, and more — all sharing the domain's pooled storage. No per-seat tax, no reason to route everything to a wildcard just to avoid paying for an extra address.

Most businesses turn to catch all email hosting to dodge the per-user pricing problem — paying $6–$12/month per seat for a low-traffic address that gets three emails a month. Here's how the approaches compare:

If you do need catch all email hosting — for legacy routing, external system compatibility, or lead capture — TrekMail supports it with real SMTP log visibility, full IMAP access, and SRS forwarding. The Starter plan is $3.50/month for 50 domains with pooled storage. The 14-day free trial requires a credit card. The free plan — 10 domains, 5GB pooled storage, BYO SMTP — is always free with no card required.

Bottom Line

Catch all email hosting is a tool, not a default setting. Run this checklist before you enable it on any provider. Each item maps to a real failure mode: IP blacklistings that take weeks to clear, account suspensions triggered by attacks you didn't start, silent data loss at storage quota, and clients who never received what they sent.

SMTP-edge rejection is the most expensive failure to discover after the fact. SRS and ARC support is the most commonly absent. Backscatter controls are the ones that follow your domain for weeks after the problem starts. And if the reason you want catch all email hosting is to avoid paying per-mailbox fees — switch to a per-domain pricing model instead. The problem disappears.

Try TrekMail free — per-domain pricing, IMAP mailboxes, no per-user fees.