Catch all email addresses accept every message, which is exactly why your verifier cannot tell you anything useful.

Definition

A catch all email address is an email address on a domain whose email server accepts emails for every local part, including mailboxes that were never created.

The setting belongs to the domain, not to the email address. Once a catch-all is configured, [email protected] and [email protected] get the same answer at the door: accepted. What happens to those emails next is invisible to the sender.

Google's admin help describes the purpose in plain terms: getting incoming messages sent to non-existent or incorrect email addresses in your domain into a single mailbox. Whether a human ever reads that mailbox is a separate question, and the sender cannot see the answer.

Accept all email address: the same mechanic, a different label

Email verification tools often say accept all email address, while mail providers such as Google, Proton and Namecheap call the setting catch-all. Hunter's help center bridges the two: an accept-all domain, also known as catch-all, is configured to accept all emails, even if they are sent to non-existent mailboxes.

Hunter also states the limit in its own help center: no verification tool, including Hunter, can fully confirm deliverability on these domains. The reason is not a weakness in any one product. The constraint sits in the protocol, as the SMTP sections below show.

Depending on the tool, the same bucket may be labeled accept-all, catch-all, unverifiable, risky or unknown. In this page's view, treat all of those email addresses as one segment with one decision attached, which the rest of this page builds.

How a catch-all email domain works

Email delivery is a short conversation. The sending email server finds the recipient domain's MX records, connects, and names one email address in a RCPT TO command. The receiving server then decides whether to accept that recipient.

RFC 5321 says that when the recipient is known not to be a deliverable address, the email server returns a 550 reply, typically with a string such as no such user. A catch-all domain does not take that branch, because it has been told to accept unknown recipients.

Instead it accepts, then sorts. Real mailboxes get their emails. Everything else is routed to one designated catch-all mailbox, a group, a forwarding destination or another server, depending on how the administrator configured it. Some setups may also file or discard the extra mail.

The Postfix documentation shows how small the switch can be. In a Postfix virtual alias table, an entry of the form @domain address is a wildcard, and Postfix says that with this form its SMTP server accepts mail for any recipient in the domain, regardless of whether that recipient exists.

Standard domain versus catch-all domain

The last row matters to two very different audiences. To a sales team it is a verification problem. To a mail administrator facing spammers who probe addresses, a server that says yes to everything leaks less, which is the trade explored further down.

Catch-all versus alias, forwarder and role address

Several mail features sound alike, and the differences decide what a verifier can see. The table below sorts them by what the receiving server knows when the RCPT TO command arrives, which is the only moment an email checker gets to ask.

Role addresses have a standard behind them. RFC 2142 lists business mailbox names such as INFO, MARKETING, SALES and SUPPORT, and encourages organizations that exchange email with the Internet to support the names that match their services.

A catch-all can sit on top of all three. A domain may run real aliases and role mailboxes and still accept everything else, which is why an info@ address on a catch-all domain is likely real but tells you little about the buyer you wanted to reach.

Why companies turn a catch-all email on

An archived TechNet Wiki article on Microsoft Learn adds one more motive: some organizations face a legal requirement to receive all mail sent to them, whether or not a user mailbox exists. That is the article's description of a need, not legal advice for any jurisdiction.

A person with a personal domain may also give each service its own email address and watch which one starts receiving spam. That habit needs either a catch-all or a separate alias per service, and the catch-all is less work.

Why email verification tools return risky or unknown

An email verifier has no password to the recipient mailbox. It can only ask the receiving email server questions and read the replies. On a catch-all domain every answer is identical, so the tools cannot separate a real person from a guessed email address.

Vendors still have to report something, so they hedge: accept-all, catch-all, unknown, unverifiable or risky. None of those labels means the email address is bad. They mean the test could not run, which is a different and more useful thing to know.

• Valid, in this page's reading, means the email server rejects unknown local parts and accepted this one.
• Invalid means the server rejected this email address outright.
• Accept-all or catch-all means the server accepts every email address, so the result is undefined.
• Unknown means the server refused to answer, timed out, or deferred the check.
• Role or disposable flag the mailbox type, not whether the email address exists.

Label names and exact definitions differ by vendor, so read your own tool's documentation before you act on a status. The list above is this page's summary of the logic, not any one vendor's definitions.

How to tell if a domain is catch-all

The logic is simple. Ask the server about a local part nobody would ever be assigned, such as a long random string. If the server accepts that recipient as readily as a real name, the domain accepts unknown recipients, and every other answer from it carries no information.

You cannot tell from the email address itself, since the setting lives on the domain. The same person can move from a strict domain to a catch-all domain when a company changes mail provider, so an old verification result can stop meaning anything.

Some vendors add a confidence score on top. Hunter says its score for accept-all emails is based on the freshness and number of web sources that mention the email address. That is inference from public evidence, not an answer from the mail server.

SMTP verification and why it fails here

Two SMTP commands were built for exactly this job, and neither gives a reliable answer on a catch-all domain. Both are defined in RFC 5321, the Simple Mail Transfer Protocol standard.

VRFY exists for this and sites may switch it off

VRFY asks an email server to confirm one address. RFC 5321 is strict about honesty: a server must not return a 250 code in response to a VRFY command unless it has actually verified the address. Checking syntax alone does not qualify.

The standard also tells operators how to decline. If a site disables these commands for security reasons, the server must return a 252 response, rather than a code that could be confused with successful or unsuccessful verification. A 252 is a shrug, by design.

RFC 5321 also says 252 should be returned when an address appears to be valid but cannot reasonably be verified in real time, particularly when a server is acting as a mail exchanger for another server or domain. That is a relay, and a relay can behave like a catch-all from outside.

RCPT probing is the fallback, and it is blunt

Because VRFY often gives no answer, email verification tools can open an SMTP session and issue RCPT TO commands without ever sending an email. RFC 5321 acknowledges this: in many cases, RCPT commands can be used to obtain the same information about address validity.

The same section warns what goes wrong. Where determination of address validity for RCPT commands is deferred until after the DATA command is received, RCPT may return no information at all. A catch-all email domain is the extreme version of that deferral.

Greylisting adds a second failure mode. RFC 6647 describes servers that answer mail from unfamiliar sources with a temporary 4yz failure and expect a later retry. A verifier that connects once, gets a 4yz and disconnects learns nothing, which is one way an unknown result can appear.

Microsoft's own products show the relay case in practice. Its Exchange Server documentation says the Recipient Filter agent performs recipient lookups only for authoritative domains, and skips the lookup for domains configured as internal relay or external relay.

The replies an email checker actually sees

RFC 3463 explains the enhanced codes in that table. It defines X.1.1 as a bad destination mailbox address, meaning the address portion to the left of the @ sign is invalid, and says the code is only useful for permanent failures.

Reading the table backward is the skill. Only a firm rejection at RCPT time lets you treat an email address as dead. Every other reply is either a yes on a strict email domain, or noise on a permissive one.

Bounce risk after the email server has said yes

Acceptance is a promise, not a delivery. RFC 5321 uses contractual language: once the server has issued a success response at the end of the mail data, a formal handoff of responsibility for the message occurs.

The standard then makes the receiver own the outcome. If there is a delivery failure after acceptance, the receiver must formulate and mail a notification message to the address from the envelope return path. That notification is the email bounce, and on a catch-all domain it arrives after the send.

RFC 5321 names the cases where this is unavoidable: the server may be unable to validate every address in the RCPT commands, for example because it is acting as a relay and has no immediate access to the delivering system. A relaying catch-all fits that description.

So catch-all emails do not remove bounces. They move them out of the SMTP session, where your sending tools see them instantly, into an asynchronous email that lands in your inbox after the campaign has already gone out.

Worse, RFC 5321 says dropping mail without notification of the sender is permitted in practice, while calling it extremely dangerous. A domain that quietly bins unknown email addresses gives you no bounce, no reply, and a contact that looks healthy forever.

Can a catch-all email be a spam trap?

Yes, in one specific way. Spamhaus describes classic or pristine spamtraps as email addresses never given to a live user or exposed on a website that have started receiving email anyway. In some cases, it says, these are addresses at wildcard domains that accept mail to any local part.

That is the catch-all mechanic seen from the other side. A guessed email address on a wildcard domain is accepted without complaint, and if nobody was ever given that address, the only reader may be a trap operator measuring how the sender built the list.

Spamhaus also says spamtraps are never revealed by their owners, and urges senders to treat them as proof of a data collection or hygiene issue rather than hunting for them. No verifier can flag a trap on a catch-all domain, because the server answers yes either way.

The practical rule follows, in this page's view: the riskiest catch-all rows are the ones produced by a pattern guesser with no other evidence. An address someone published or used to write to you is a different kind of row.

Directory harvest attacks, and why email servers stop answering

There is a reason administrators dislike email servers that answer address questions truthfully. RFC 5321 itself notes that accepting a message may trigger additional undesirable traffic by providing verification of the address.

Microsoft defines the abuse in its Exchange Server documentation on recipient filtering. A directory harvest attack, in Microsoft's words, is where a spammer uses an automated program to collect email addresses that return a 250 2.1.5 Recipient OK SMTP response.

Microsoft's countermeasure is tarpitting, which it defines as artificially delaying server responses for specific SMTP communication patterns that indicate high volumes of mail, so that the cost of sending spam increases for the spammer. By default, it says, tarpitting is configured for 5 seconds on Receive connectors.

A catch-all works against harvesting in a cruder way. If the email server says yes to everything, harvesting returns a list of email addresses with no signal in it. Your verification tools become collateral damage in a defense aimed at someone else.

Should you send emails to a catch all email address?

Yes, conditionally, and never as an undifferentiated block. Deleting every accept-all email address can strip real buyers out of your lists, because the setting says nothing bad about the people behind it. Mailing the whole segment blind puts a sending domain and its reputation at risk.

Score each catch-all email address before it enters a sequence. This scoring model was written for this page as a working default, and it is not measured against any dataset.

Email addresses with one weak signal or none go to a hold list. Revisit them once you have confirmed the naming pattern at that company another way, such as a colleague's email address that did come back valid.

Hunter's help center adds that accept-all emails with sources are always better than accept-all emails without any. That matches the first row of the table, and it is the cheapest filter you can apply before a single email is sent.

A workflow for a list full of catch-all emails

1. Separate the bucket

   Split the export into valid, invalid and accept-all email addresses. Invalid goes out. Valid enters the normal sales cadence. Accept-all gets its own track.

2. Enrich before you guess

   Run the accept-all rows through lead enrichment to attach a source, a current role and a confidence score. An email address with a source outranks a generated one.

3. Score and rank

   Apply the signal table above. Keep only email addresses with at least two positive signals in the first send, and park the rest.

4. Send a small batch first

   Send a small first batch from a domain that has finished email warm up, not a full campaign. As a working default for this page, keep watching for bounces for at least a day, since catch-all bounces arrive after acceptance.

5. Read replies, not opens

   On a catch-all domain a silent email address is ambiguous. Count replies, out-of-office notices and late bounces as the evidence. Google says it does not track open rates, so an open count proves little.

6. Promote or retire

   Email addresses that produce any human signal move to your verified segment. Those with no response after a full sequence leave the email database.

How the catch-all email setting looks at each provider

Knowing where the switch lives helps you read someone else's domain, and it is the same page you need if you run the email domain yourself. Each row below comes from that provider's or project's own documentation.

Exchange Online has no single catch-all switch

Microsoft's product documentation describes accepted domain types, not a catch-all button. A community article in Microsoft Learn's archived TechNet Wiki shows a workaround: set the domain to InternalRelay, create a dynamic distribution group of all users, and add a mail flow rule.

That rule redirects mail from outside the organization to a catch-all mailbox, except when the recipient is a member of the all-users group. The same article warns that the method is not officially supported by Office 365 Support, should be tested in a lab first, and that NDRs will not be generated.

The last point is the one senders feel. A domain built this way sends no bounce for a wrong address, so a mistyped or guessed email lands in a shared mailbox and the sender never hears about it.

Postfix: two different catch-alls

Postfix documents luser_relay as an optional catch-all destination for unknown recipients of its local delivery agent. By default, it says, mail for unknown recipients in those domains is returned as undeliverable, so luser_relay changes a rejection into a delivery.

The virtual alias wildcard reaches further, and Postfix attaches a warning to it. Accepting mail for non-existent recipients and then returning it as undeliverable to an often forged sender address may turn your mail system into a backscatter source.

Postfix lists two fixes: replace the wildcard with explicit one-to-one mappings, or add a reject_unverified_recipient restriction for that domain. Either way the server goes back to answering honestly at RCPT time.

Notice how different these mechanisms are. Google routes after acceptance, Microsoft decides at the perimeter or by mail flow rule, and a registrar or a Postfix wildcard simply relays. From outside, all of them look the same to verification tools.

Setting up a catch-all email on your own domain

There are good reasons to run one on a company domain: no email is lost to a typo, and retired aliases keep working. There are also costs, and they arrive quickly.

• Pick a destination first. Proton recommends a dedicated email address such as [email protected] so catch-all messages do not clutter a personal inbox. Google lets the destination be a user account or a Google Group.
• Use a group if several people should read it. Google notes that a group lets other people in your organization check the messages sent to the catch-all address.
• Give someone the job. A catch-all mailbox nobody reads is worse than a bounce, because senders believe their emails arrived.
• Filter aggressively. Expect spam aimed at common local parts. Rules that file emails by recipient keep the mailbox usable.
• Keep real mailboxes real. A catch-all does not replace the aliases people actually use, such as billing@ or support@.
• Do not create backscatter. If your server accepts first and bounces later, follow the Postfix guidance and verify recipients at RCPT time.
• Do not run one on a sending domain. The reason is in the section after next.

Turning a catch-all email off, and what happens next

Switching it off is usually one control in the place you switched it on: disable or delete the routing setting at Google, set the accepted domain back to Authoritative at Microsoft, clear the catch-all at Proton, or delete the wildcard forwarder at a registrar.

Your email server then starts rejecting unknown recipients. Microsoft's documentation shows the reply its service returns once Directory-Based Edge Blocking is active: 550 5.4.1 Recipient address rejected: Access denied. Proton shows senders a message saying the address could not be found.

Before you flip it, list every alias in current use, including ones only a supplier or an old web form knows about. Emails sent to anything you forget will bounce immediately instead of quietly arriving.

Microsoft also warns that the change is not absolute. Its guidance says there might be infrequent instances where recipient addresses that do not exist in your organization are allowed to relay through the service, and Google says routing changes can take up to 24 hours.

Never on a cold email sending domain

If you send outbound emails from a dedicated domain, a catch-all on that domain works against you in two ways, and neither is obvious until a campaign is already running.

First, it muddies your own feedback. A catch-all on the sending side accepts every reply, auto-response and mistyped address aimed at you, so the mailbox fills with noise that hides the messages a person needs to read.

Second, it invites junk. Emails aimed at guessed local parts land in the inbox tied to your sending identity, and the reply address your prospects write to becomes hard to monitor. Keep that mailbox clean and staffed, as covered in the cold email hub.

Configure the sending domain with real mailboxes, working MX records, SPF, DKIM and DMARC, and one reply address a human reads daily. For mail to personal Gmail accounts, Google's email sender guidelines require SPF or DKIM and a TLS connection from all senders.

DMARC is now defined by RFC 9989, published in May 2026, which obsoletes RFC 7489. It also warns that a DMARC pass by itself does not guarantee that delivery to the inbox would be safe or desirable, so authentication never excuses mailing unverified email addresses carelessly.

Catch-all emails, engagement and sender reputation

Catch-all email addresses do not damage a sender by themselves. In this page's view, what hurts is volume sent to a segment that never replies and sometimes bounces late, because that pattern looks like a list-quality problem to the receiving side.

Google's email sender guidelines cover mail sent to personal Gmail accounts, those ending in @gmail.com or @googlemail.com. Its FAQ says the guidelines do not apply to messages sent to Google Workspace accounts, so a catch-all on a company's Workspace domain sits outside them.

For mail that is in scope, Google requires all senders to keep the spam rate reported in Postmaster Tools below 0.3%, and advises keeping it below 0.10% and never reaching 0.30%. Senders of more than 5,000 messages a day to Gmail accounts must also publish DMARC.

Two more lines from the same guidelines matter for an unverifiable segment. Google lists automatically unsubscribing recipients who have multiple bounced messages, and says that if messages start bouncing or being deferred, you should reduce sending volume until the SMTP error rate decreases.

Google also tells senders not to send messages to people who did not sign up to get messages from them, and to consider unsubscribing recipients who do not open or read their messages. For an accept-all segment, both point toward small batches and fast retirement.

Postmaster Tools reports domain and IP reputation. In this page's view, keep accept-all emails off the domain that carries your best verified contacts until the segment has proved itself. Your outreach is only as safe as the worst list on that domain.

Mistakes teams make with catch-all emails

• Deleting the whole accept-all segment, and with it every real buyer whose company happens to run a catch-all email domain.
• Mailing the whole segment at once, from the same domain you use for verified contacts.
• Reading a clean bounce report on send day as proof of delivery, when the email server may bounce later or discard silently.
• Treating a vendor confidence score as a protocol answer. It is inference from other evidence, such as web sources.
• Feeding pattern-guessed email addresses into a catch-all domain, where nothing will ever tell you they were wrong and some may be traps.
• Sending one test email and reading silence as success. On a catch-all domain silence is the expected result either way.
• Running a catch-all on the domain you send outbound emails from, then wondering why the reply mailbox is unusable.
• Re-verifying an accept-all list with the same tools and expecting a different answer. The protocol has not changed.

Where catch-all emails fit in your prospect data

A verification status is one field on a contact record, and it should never be the only field you act on. Source, role, seniority and recency matter more when the protocol refuses to answer.

That makes the accept-all bucket a data problem before it is a sending problem. Build your prospect list so every email address carries where it came from, then let provenance break the tie that SMTP cannot.

The same discipline applies across your B2B data. An email address verified two years ago is not verified today, and an accept-all address enriched from a live company page can beat a valid address from a stale export.

A catch-all is also different from a broken domain. A domain not found error means the domain does not resolve for mail at all, while a catch-all domain resolves and accepts everything, so the two need opposite handling.

In a sequence

One email earns its place in the accept-all track: a short note to a colleague whose email address did come back valid, asking for the right person. It turns an unverifiable guess into a confirmed email address without burning the account.

Subject: Right person for {{topic}} at {{companyName}}?

Hi {{firstName}},

I am trying to reach whoever owns {{topic}} at {{companyName}}. I have {{guessedAddress}} for {{targetName}}, but I am not confident it is current.

Could you point me to the right person, or tell me if {{targetName}} is still the one to ask?

Happy to send the one-paragraph version so you can forward it.

{{senderName}}

Frequently asked questions