Most of Your Bounces Came From One Company's Domain? Here's What It Means

When most of a day's bounces come from one recipient domain, the problem is that domain, not your whole list. There are five usual causes: the company moved mail provider, its server stopped accepting every address, you used the wrong email pattern for everyone there, its directory is out of sync, or it blocked your sending. The bounce text and the domain's MX records tell you which, in about ten minutes. Pause the domain rather than deleting every lead at it.

A typical report, from an r/coldemail thread: a 3% bounce rate in a day, 24 bounces out of 918 sends, all at one company's domain. The rest of the list was fine. That pattern is the subject of this post.

Step 1: read the bounce text

Export the bounces for that domain with the full reason, or paste a few into Bounce Doctor. The codes split into two groups:

What the bounces say	Group	Meaning
550 5.1.1 user unknown, 550 5.4.1 Recipient address rejected: Access denied, "recipient not found"	Bad address	The server says these mailboxes do not exist
550 5.1.2 / host not found / no MX	Dead domain	The domain no longer receives mail
550 5.7.x policy, spam or "not authorized"	Block	The server is refusing your sending
Gateway text, such as 554 Blocked - see proofpoint.com/postmaster or Mimecast "envelope blocked"	Block	A security gateway is refusing you
4.x.x deferrals that expired	Temporary, then failed	Throttling or greylisting that ran out of retries

If every bounce is in the bad address group, go to step 2. If they are blocks, skip to cause 5.

Step 2: check whether the mail host changed

Look up the domain's MX records with the MX lookup or the email provider lookup. Then compare with what you would expect, or with an earlier verification result if you have one.

• MX now points to *.mail.protection.outlook.com (Microsoft 365), but the company used to be on Google Workspace, or the reverse.
• MX now points to a gateway (pphosted.com for Proofpoint, mimecast.com for Mimecast) that was not there before.
• MX points somewhere unexpected, or does not exist.

A recent change of host is the single most common cause of a sudden cluster.

The five causes

1. The company moved mail provider

During a migration, addresses that worked on the old system may not exist on the new one: aliases that were not recreated, shared mailboxes renamed, ex-employee forwards dropped. On Microsoft 365 with Directory-Based Edge Blocking switched on, any address not in the new directory is refused with 550 5.4.1. Our 550 5.4.1 explainer covers that bounce in detail.

What to do: re-verify the remaining addresses at the domain now. Ones that come back valid on the new host are safe to send. Suppress the ones that come back invalid.

2. The domain stopped being catch-all

A domain that accepted every address when you verified it (catch-all) has been reconfigured to reject unknown recipients. Every guessed or stale address now bounces at once.

This is also why "verified" leads can bounce in a cluster. If the domain was catch-all at check time, no verifier could confirm any mailbox there. A verifier that reports accept-all as valid would have passed them all. SimpleVerifier keeps catch-all rows risky and graded for exactly this reason. See accept-all vs unknown results.

What to do: re-verify. Now that the server answers clearly, the check will tell you which addresses are real.

3. You used the wrong email pattern

If your list was built by guessing (first.last@ for everyone at a company) and the company actually uses flast@, every guess bounces. Often it was a catch-all domain that hid the mistake until something changed.

What to do: find the real pattern from a confirmed address (a reply, a signature, the website) with the email format finder, regenerate the addresses, and verify them before sending. Our post on email address patterns lists the common ones.

4. The recipient's directory is out of sync

Hybrid Microsoft 365 setups, half-finished migrations and misconfigured accepted domains can make real people bounce. Microsoft's own fix for 550 5.4.1 affecting every address at a domain is an admin-side resync. Only the recipient's IT team can do it.

What to do: if you are certain the addresses are real (you have emailed them before, they replied), pause the domain for a few days and try one address again. Do not keep sending to the whole group.

5. The company blocked you

A cluster of 5.7.x rejections, or gateway messages, means the company's mail system has decided not to accept your mail. Common triggers: many contacts at one company receiving similar messages on the same day, a recipient marking you as junk, or your IP or domain reputation at that gateway.

What to do: stop sending to that domain from the affected inbox or domain. Do not delete the leads: the people still exist. Fix what you can on your side. Our guides cover Proofpoint, Mimecast and Cisco Talos reputation. Contact high-value people another way, and spread future sends to one company over days, not hours.

Why one domain can pause a whole campaign

Bounce limits in sending tools usually apply to the campaign or the inbox, not per domain. If a list has 50 contacts at one company, for example from a scraped team page or a full account export, one domain-level problem can push the whole campaign over the line in a single day. Our post on bounce rate thresholds by platform lists where each tool pauses.

Two habits limit the damage:

1. Cap contacts per domain per day. Spreading 50 contacts at one company over a week means a domain problem shows up after a few bounces, not fifty.
2. Check the domain mix before you send. The email list segmenter and bulk email provider lookup show which domains and hosts dominate a list.

A worked example (illustrative)

A team sends step 1 to 900 leads. 24 bounce, and 22 of them are at one manufacturing company that had 40 contacts on the list, all built as first.last@. The bounces read 550 5.4.1 Recipient address rejected: Access denied.

The MX lookup shows the company is now on Microsoft 365. The team's verification from six weeks earlier had marked the whole domain catch-all. So the domain used to accept everything, and after a move to Microsoft 365 it now rejects unknown recipients. A reply from one of the contacts shows the real format is flast@.

They pause the domain, regenerate the 18 remaining addresses in the right format and re-verify them: 12 come back valid. They send those the following week, capped at five a day. The other 878 leads were never the problem.

A ten-minute diagnosis

1. Filter bounces to the one domain. Paste them into Bounce Doctor.
2. Bad addresses or blocks? If blocks, go to cause 5.
3. Look up the MX. Did the host change? If yes, cause 1.
4. Was the domain catch-all when you verified? If yes, cause 2 or 3.
5. Do the bounced addresses share a format that differs from a confirmed one? If yes, cause 3.
6. Re-verify the remaining addresses at the domain on the verify page, and send only to what comes back valid.

Where SimpleVerifier fits

A re-check after a cluster tells you which addresses survive a migration or catch-all change. Catch-all domains come back risky rather than valid, so a domain that could flip later is visible before you send. We cannot tell you a company's internal directory is broken, or lift a block. Those are on the recipient's side.

The first 100 checks are free with a Google sign-in. Plans are on the pricing page.