Valid Emails Still Bouncing? The Sending Domain Playbook

A campaign manager at a research and advisory firm called us in something close to a panic. A campaign had gone out to eight contacts at a large enterprise account. Almost all of them bounced. One got through.

The first assumption, naturally, was bad data. So the team re-verified every address. Twice. Every one came back valid.

Then she said the thing that explains why this problem is so much more serious than a bounce metric suggests:

“If I continue using it and these are the kind of bounces I’m looking at, I’m going to be in a very big problem. I don’t want to be answerable to my leadership for causing issues to my primary domain. You know how dangerous that can be.”

She was not worried about eight emails. She was worried that her company’s main domain (the one every invoice, contract and client email flows through) was being damaged by an outbound campaign. That is the correct thing to worry about, and it is the reason this article exists.

This is the sending domain playbook: why valid addresses bounce, how to diagnose it properly, and how to run outbound at volume without ever putting your primary domain at risk.

First, separate the two things called “bounce”

Nearly every confused deliverability conversation comes from collapsing two very different events into one word.

A recipient-level rejection means the address is wrong. The mailbox does not exist, the domain has no mail exchanger, the account was closed. This is a data problem and verification fixes it.

A sender-level rejection means the address is fine and you were refused. The receiving server looked at your sending IP, your domain’s reputation, your authentication records, or the pattern of your sending, and declined to accept the message. Verification cannot fix this, because there is nothing wrong with the address.

When valid, twice-verified addresses bounce, you are almost always looking at the second category. And the distinction matters enormously, because the remedies are opposites. For a data problem you clean the list. For a reputation problem, cleaning the list changes nothing and every additional send makes it worse.

How to tell which one you are looking at

The answer is in the bounce message itself, and this is the single most skipped step in outbound troubleshooting. Do not work from the dashboard’s bounce count. Open the actual non-delivery report and read the SMTP response.

A few patterns and what they mean:

• 550 5.1.1 User unknown / 550 5.4.1 Recipient address rejected: genuine recipient problem. The mailbox is not there.
• 550 5.7.1 Service unavailable, client host blocked: sender problem. Your IP or domain is on a blocklist.
• 421 4.7.0 Try again later / throttled: rate limiting. You are sending too fast for your reputation. Not fatal, but a clear warning.
• 550 5.7.26 unauthenticated email ... DMARC: authentication failure. SPF, DKIM or DMARC is misconfigured.
• Message rejected due to content / spam-score references: content filtering rather than reputation.

The critical diagnostic question, once you have the code, is: is this happening across all your sending accounts, or only one?

If every mailbox on the domain is affected, you have a domain or IP reputation problem, and it is serious. If it is isolated to one mailbox or one recipient domain, the blast radius is small and the fix is local. In the case above, the team confirmed other accounts on the same domain were sending normally, which immediately ruled out a domain-wide reputation collapse and pointed at something specific to that campaign and that recipient’s filtering posture. That one question saved a week of chasing the wrong problem.

Our fuller diagnostic walkthrough for filtering and placement issues is in why are my emails going to spam, and the broader fundamentals in email deliverability.

Why enterprise recipients bounce good addresses

There is a specific scenario that catches teams selling upmarket, and it is worth naming because it looks exactly like a data failure.

Large enterprises run aggressive inbound filtering: Proofpoint, Mimecast, Barracuda, Microsoft Defender. These systems do not merely score content. They evaluate whether they have ever seen your domain before, whether your domain is newly registered, whether your sending pattern looks like a human or a sequence, and whether several near-identical messages just arrived at several employees at once.

That last one matters. Eight similar emails landing on eight people at the same company within a short window is a textbook pattern for bulk-mail detection. Each individual address is perfectly valid. The pattern triggered the block. This is why a campaign to a single large account can bounce almost entirely while the identical sequence to eight different companies sails through.

Practical implications for enterprise outbound:

• Stagger sends to the same account across days rather than minutes.
• Vary the message meaningfully between recipients at one company. Not spintax on a template, actually different angles per role.
• Keep per-account volume low. Six contacts at one enterprise in one week is fine. Six in one hour is a flag.
• Expect the first contact with a heavily filtered organisation to be the hardest. Reputation with that recipient builds over time.

The core principle: never send outbound from your primary domain

Here is the rule that everything else in this article supports.

Your primary domain (the one carrying invoices, contracts, support and client conversations) should never be the domain running cold outbound. Not because outbound is disreputable, but because the risk is asymmetric and irreversible in a way that most teams do not appreciate until it happens.

If cold outbound damages the reputation of your primary domain, you do not just lose a campaign. Your finance team’s invoices start landing in spam. Your support replies do not arrive. Contract PDFs go missing. And recovering a burned domain reputation takes months of careful low-volume sending, during which every business-critical email you send is degraded.

That is the risk the campaign manager was describing. She was not being dramatic. She was being precise.

What to use instead

The standard solution is a set of secondary sending domains: separate domains, registered specifically for outbound, that carry your mailboxes for cold campaigns. They typically resemble your brand (getyourcompany.com, yourcompany-mail.com, tryyourcompany.com), and when someone types one into a browser it redirects to your real website, so the experience for a curious prospect is seamless.

The mechanics that make this work:

• Reputation isolation. The secondary domain builds and carries its own sender reputation. Whatever happens to it does not touch your primary domain.
• Disposability. If a domain does get burned, you retire it and move on. This is infrastructure you can throw away, which is exactly the property you want.
• Brand continuity. The redirect means a prospect who investigates lands on your real site.
• Independence from corporate IT. More on this below, because it is often the real blocker.

The IT objection, and how teams actually get past it

On that same call, once the team agreed secondary domains were the answer, the conversation hit a wall that will be familiar to anyone who has run outbound inside a larger company:

“The domain is resting in our servers, and you are routing these emails through our servers, and our IT team is not okay with that.”

This objection is legitimate and it kills more outbound programmes than any deliverability issue. Security teams do not want a sales vendor inside the corporate mail path, and they are right not to want that.

The resolution is architectural. A correctly configured secondary domain does not route mail through the vendor’s servers at all. The mailboxes sit on Google Workspace or Microsoft 365, sending goes out through Google’s or Microsoft’s infrastructure and IP reputation, and the outbound platform authenticates via delegated access to send on the mailbox’s behalf. The vendor orchestrates. The mail provider transmits. Nothing traverses the vendor’s mail servers, and nothing traverses the company’s production infrastructure either.

That distinction, orchestration versus transmission is the answer to give your security team, and it is worth confirming explicitly with any vendor you evaluate. Ask directly: does mail leave my mailbox provider’s IPs or yours?

The pattern that works in IT-restrictive organisations

There is a repeatable structure that outbound leaders at large companies use to get this shipped, and it is worth stating plainly because it looks like a workaround but is genuinely the correct architecture.

Sales operations, not corporate IT, purchases the outbound domains. The mailboxes live in a workspace tenant that is separate from the production corporate tenant. The domains are treated as marketing infrastructure: an expense line, like ad spend, rather than as part of the engineering estate. The company still owns everything; it simply is not entangled with the systems that IT is responsible for protecting.

This is not shadow IT. Ownership stays with the company, billing goes through the company, and security policy still applies. What changes is that a disposable, reputation-isolated asset is no longer subject to controls designed for irreplaceable production infrastructure. Once framed that way, most security teams agree quickly, because you are removing outbound from their risk surface rather than adding to it.

The arithmetic: how many domains and mailboxes you need

Two constraints drive the whole calculation.

Constraint one: roughly five mailboxes per domain. Beyond that, the domain’s sending volume looks disproportionate to its size and starts drawing scrutiny.

Constraint two: conservative daily volume per mailbox. Even fully warmed, treat 30 to 50 cold emails per mailbox per day as the working ceiling. Higher is possible on a mature, well-reputed mailbox, but it is not where you start and it is not where you should design your capacity plan.

So the working capacity of one domain is approximately five mailboxes times 30 to 50 emails, or 150 to 250 emails per day.

Working backwards from a target:

• 500/day: 2 to 3 domains, 10 to 15 mailboxes.
• 1,000/day: 4 to 6 domains, 20 to 30 mailboxes.
• 2,000/day: 8 to 12 domains, 40 to 60 mailboxes.

These numbers surprise people who assumed outbound scale was a software setting. It is not. It is infrastructure, and at high volume it is a genuine operational estate. Teams running serious volume operate a hundred or more mailboxes, and the largest run several hundred. Plan for that reality rather than discovering it after your first domain gets throttled.

Warm-up: the ten days you cannot skip

A brand new domain has no sending history. To a receiving server it is indistinguishable from a domain a spammer registered this morning, because in the relevant sense it is the same thing. Warm-up is the process of building a history that says otherwise: starting at very low volume, sending to addresses that reliably open and reply, and increasing gradually.

The realistic timeline is seven to ten days minimum before a new domain carries meaningful campaign volume, and two to three weeks before it reaches full capacity.

This produces the objection we hear most often, and it is a fair one: we cannot lose ten days of pipeline. The campaign manager on that call put it exactly that way.

The answer is that you do not have to. Warm-up is a planning problem, not a pause:

1. Run other channels during warm-up. LinkedIn and calling do not depend on domain reputation at all. Shifting outbound to those channels for a week costs you far less than a burned domain. This is precisely what that team did, they paused email, ran LinkedIn campaigns, and lost almost no activity.
2. Warm the next domains while running the current ones. Warm-up should be permanently in progress somewhere in your estate. A domain coming online every few weeks means capacity is always ahead of demand.
3. Warm the domain before you need it. The ten days only hurts when it starts the day you need capacity.

One detail that trips teams up: warm-up is per mailbox, not just per domain. The domain builds reputation, but each new mailbox on it also needs its own ramp. Adding five mailboxes to a warmed domain still requires warming those mailboxes, though it goes faster than a cold domain.

Keep warm-up running continuously rather than treating it as a one-time setup, because it also functions as an early warning system: a drop in warm-up inbox placement is the first visible sign of a reputation problem, usually days before it shows up in campaign results. The mechanics are covered in email warming and the product side in email warm-up.

Domain rotation: the strategy that makes the estate resilient

Once you are running several domains, rotation turns a fragile setup into a durable one.

The core idea: do not run every domain at full capacity simultaneously. Keep some active, some resting, some warming. A resting domain recovers reputation. A warming domain is future capacity. An active domain is producing pipeline.

A workable cycle with six domains:

• Two active. Carrying current campaign volume.
• Two resting. Low or no cold volume, warm-up traffic only, reputation recovering.
• Two warming. New or recently rested, ramping toward active.

Rotate roughly monthly. The benefits compound: no single domain accumulates enough negative signal to burn out, you always have capacity in reserve, and if one domain does develop a problem you simply rotate it out instead of scrambling. As the campaign manager on that call put it when describing the same approach from a previous role, the damage gets negated.

Rotation is also what makes recovery survivable. Without it, a burned domain is an emergency. With it, a burned domain is a scheduled maintenance item.

Authentication: table stakes, and still the most common failure

None of the above matters if authentication is wrong, and misconfiguration remains one of the most frequent root causes of unexplained bounces. Every sending domain needs three records, and they need to be right.

• SPF lists which servers may send for your domain. Watch the ten-DNS-lookup limit, exceeding it silently invalidates the whole record. Publish exactly one SPF record per domain.
• DKIM cryptographically signs your mail so the recipient can verify it was not altered and genuinely came from you. Use a 2048-bit key.
• DMARC tells receivers what to do when SPF or DKIM fails, and sends you reports. Start at p=none to observe, then move to quarantine and eventually reject once you have confirmed legitimate mail passes.

Since 2024, Google and Yahoo have required authentication for bulk senders and enforce a spam complaint rate below 0.3 percent. These are published thresholds, not guidance. Google’s own email sender guidelines are the authoritative reference and worth reading in full before you scale volume.

Verify the actual DNS rather than trusting a setup wizard. Mail-tester gives you a fast end-to-end score, and MXToolbox checks individual records and blocklist status. Our step-by-step version is the email deliverability checklist.

What to monitor, and the numbers that mean stop

Set thresholds in advance, because in the middle of an incident nobody agrees on what counts as bad.

• Bounce rate. Under 2 percent is healthy. Above 5 percent, pause the campaign and diagnose before sending again.
• Spam complaint rate. Keep below 0.1 percent. Google’s enforcement threshold is 0.3 percent, so 0.1 is your safety margin.
• Warm-up inbox placement. The leading indicator. A decline here precedes campaign problems by days.
• Reply rate by domain. A domain whose replies fall while others hold steady is showing a placement problem, not a copy problem.

Watch these per domain and per mailbox, never only in aggregate. Aggregate numbers hide exactly the localised failure you most need to catch early. Two healthy domains will mask one that is quietly burning.

A note on open rates as a health signal: they are considerably less reliable than they used to be. Privacy proxies and scanning systems inflate them, and security appliances at large enterprises frequently pre-open messages. Treat opens as directional at best. We covered why in is Gmail killing email tracking.

The setup sequence, start to finish

If you are building this from scratch, this is the order:

1. Register secondary domains. Brand-adjacent, redirecting to your main site. Buy more than you currently need.
2. Create mailboxes on Google Workspace or Microsoft 365. Maximum five per domain. Real names, real signatures, real profile photos.
3. Configure SPF, DKIM and DMARC. Verify with an external tool rather than trusting the wizard.
4. Start warm-up immediately. Before you have campaigns ready. Seven to ten days minimum.
5. Connect to your sending platform via delegated access. Confirm mail leaves your provider’s IPs, not the vendor’s.
6. Begin at low volume. Ten to fifteen emails per mailbox per day, increasing weekly.
7. Monitor per domain. Set the thresholds above before you launch, not after.
8. Establish rotation. Once you have four or more domains, put the active/resting/warming cycle in place.
9. Keep warm-up running permanently. It is both maintenance and early warning.

Setup is a few hours of work. Warm-up is the long pole, and it is the step teams skip when they are in a hurry. It is also the step whose absence produces the exact panic this article opened with.

The real lesson

The team in this story did not have a data problem. Their addresses were valid and they had proven it twice. What they had was an infrastructure problem wearing a data problem’s clothing, and the reason it was frightening was that the blast radius extended to a domain the business could not afford to lose.

The fix is not a better verification tool. It is architectural: outbound runs on disposable, isolated, warmed infrastructure that has no path to your primary domain’s reputation. Once that is true, a bad campaign costs you a domain you can replace for a few dollars instead of the mail system your company runs on.

That is the whole argument. Everything above is implementation detail.

If you want the sending, warm-up and bounce handling to live in one place, with per-mailbox limits, automatic pausing on hard bounces, and DNS health checks built in, that is how Salesgear’s sales engagement platform is designed. The warm-up engine is covered at email warm-up, and if you are comparing tools on deliverability specifically, best sales engagement platforms goes through the category.

Frequently asked questions

Why do valid email addresses still bounce?

Because bounces come in two kinds. A recipient-level rejection means the address is wrong. A sender-level rejection means the address is fine and the receiving server refused you, based on IP or domain reputation, authentication failures, or a sending pattern that looked like bulk mail. Verified addresses that bounce are almost always the second kind, which is why re-verifying the list changes nothing.

Should I send cold email from my main company domain?

No. The risk is asymmetric. If outbound damages your primary domain’s reputation, invoices, contracts and support replies start landing in spam, and recovery takes months of restricted sending. Use secondary domains that redirect to your main site, so a burned domain is a replaceable asset rather than a business incident.

How long does a new sending domain need to warm up?

Seven to ten days minimum before meaningful campaign volume, and two to three weeks to reach full capacity. Warm-up applies per mailbox as well as per domain, so new mailboxes on an established domain still need their own ramp. Run other channels during warm-up rather than pausing outbound entirely.

How many mailboxes can I run per domain?

Around five. Beyond that the domain’s volume looks disproportionate to its apparent size. With a conservative 30 to 50 cold emails per mailbox per day, one domain supports roughly 150 to 250 emails daily, so 1,000 per day needs four to six domains.

Does an outbound platform route my email through its own servers?

It should not, and this is worth confirming explicitly. In a correct setup, mailboxes sit on Google Workspace or Microsoft 365, mail leaves through those providers’ infrastructure and IP reputation, and the platform authenticates via delegated access to orchestrate sending. Ask any vendor directly whether mail leaves your mailbox provider’s IPs or theirs.

What is domain rotation and do I need it?

Rotation means running domains in a cycle of active, resting and warming rather than all at full volume. It prevents any single domain accumulating enough negative signal to burn out, keeps spare capacity available, and turns a burned domain from an emergency into a scheduled swap. It becomes worthwhile once you run four or more domains.