What Actually Happens When You Send to an Invalid Email Address

When you send to an invalid email address, the chain reaction that follows is more consequential than the single failed delivery suggests. The bounce gets logged. The bounce rate ticks up. Your ESP notices the pattern. The receiving providers notice the pattern. Your sender reputation degrades, slowly at first. Inbox placement for your valid subscribers starts drifting toward the spam folder. Over weeks, the campaign that was getting 30% open rates is getting 18%, and nobody quite knows why.

This is the chain reaction step by step: what happens technically at each stage, how the damage compounds, and what an "invalid address" actually means in terms of the protocol-level rejection you get back. The point isn't to scare you about list hygiene; it's to show why pre-send verification is the kind of work that pays back across every subsequent send, not just the one you're prepping for.

01What "invalid" means at the protocol layer

The send process condensed: your ESP hands the message to its sending infrastructure, which opens an SMTP connection to the receiving server (looked up via the recipient domain's MX records), walks through the protocol handshake (HELO / MAIL FROM / RCPT TO / DATA), and waits for the server's response at each step.

For an invalid address, the rejection comes at RCPT TO. The receiving server returns one of these:

• 550 5.1.1: Mailbox doesn't exist. The most common case for invalid addresses. The address was a typo, a fabricated entry, or a long-abandoned mailbox.
• 550 5.1.2: Bad domain. The domain has no MX records or no usable mail infrastructure.
• 550 5.2.1: Mailbox disabled. The mailbox existed at some point but has been suspended or closed.

Your ESP records this rejection as a hard bounce. The message body (DATA) never gets transmitted; the protocol exchange terminated before that step. So in a literal sense, you didn't "send" the message; you attempted to and were rejected at the protocol layer. But the attempt itself is what counts against you in the reputation systems.

02Step 1: the bounce gets recorded

Your ESP logs the bounce in two places:

1. The campaign-level bounce report: visible in your dashboard. Shows the address that bounced, the SMTP code, and (sometimes) the response text.
2. The account-level suppression list: the address gets added to your ESP's internal blocklist so future campaigns automatically skip it.

The suppression part is good: it prevents you from re-mailing a known-bad address. The campaign-level record is the part that creates the downstream chain.

03Step 2: your ESP aggregates the bounce rate

Bounce rate is calculated per campaign and rolled up to account-level rolling windows (typically 30-day and 90-day). Major ESPs all have internal thresholds where bounce rate starts triggering actions:

• Mailchimp: starts limiting send capacity around 3% bounce rate; can pause an account around 5%
• Klaviyo: flags accounts above 2% bounce rate for internal review
• SendGrid / Mailgun: terms of service typically say 5% is the line where account review begins
• HubSpot: alerts and may restrict for accounts above 3-4%

A single high-bounce campaign isn't immediately fatal at any of these. But the rolling-window rate is what matters; one bad campaign nudges the 30-day rolling number up for weeks.

04Step 3: receiving providers notice the pattern

Gmail, Microsoft 365 (Exchange Online Protection), Yahoo, and the smaller mailbox providers all run internal reputation systems on senders. The systems are proprietary and the exact algorithms aren't published, but the inputs are well-documented:

• Bounce rate: higher rate = lower trust
• Spam complaint rate: the most heavily weighted single signal
• Engagement rate: opens, clicks, replies; higher engagement = higher trust
• Authentication pass/fail: SPF, DKIM, DMARC results
• Sending volume patterns: sudden spikes look suspicious
• List freshness signals: high bounce rate hints at stale acquisition

Of those inputs, bounce rate is the cheapest signal to compute. Receiving servers know in real time whether a recipient existed; they can roll those rejections up by sending IP/domain over time. A sender whose bounce rate has been creeping up over multiple campaigns triggers internal reputation downgrades that aren't published anywhere but show up as worse inbox placement for everyone.

05Step 4: your sender reputation degrades

"Sender reputation" is the aggregate trust score the receiving providers assign to your sending IP, your sending domain, and (separately) your message-from domain. It's not a single number (different providers maintain different reputations for the same sender) but the directional signal is consistent across them.

When sender reputation degrades:

• Inbox placement drops: messages that would have landed in the primary inbox start landing in the Promotions tab (Gmail) or spam folder
• Delivery latency increases: receivers add deliberate delay to mail from low-reputation senders (anti-spam buffering)
• Engagement-based filtering tightens: borderline subscribers (low historical engagement with you) stop seeing your messages even if they're not technically unsubscribed
• One-click unsubscribe pressure: Gmail's bulk-sender requirements (Feb 2024) include mandatory one-click unsubscribe; low-reputation senders get downranked harder for missing this

The mechanism is gradual. Day one of a reputation downgrade doesn't look any different. By week three, your open rate on the same content is meaningfully lower. By month two, you're investigating why your campaigns underperform and discovering the reputation hit you took weeks ago.

06Step 5: good subscribers stop seeing your email

This is the expensive part. The reputation damage doesn't only affect the bad addresses; those were going to bounce regardless. It affects every valid subscriber on your list.

Concretely: if 5% of your list bounces because they're invalid, and the resulting reputation damage drops inbox placement for the remaining 95% from 92% to 78% of inbox primary, you've lost ~14 percentage points of effective reach across your real subscribers. The math depends on volume, but the pattern is consistent: the cost of sending to bad addresses is paid by your good ones.

This is why "but it's just one campaign" misses the point. The single campaign is the cost; the multi-week reputation damage to subsequent campaigns is the consequence.

07Step 6: recovery takes weeks

Once reputation has degraded, getting it back is slow:

1. Stop the cause first: re-verify the list, drop invalid addresses, fix the acquisition pipeline that was generating them
2. Reduce volume: send only to your most-engaged segment for 2-4 weeks. Engagement signals are what rebuild trust.
3. Monitor: Google Postmaster Tools and Microsoft SNDS show how the major receivers view you. Watch the reputation trend.
4. Don't re-mail the lost subscribers: re-sending to the disengaged segment during recovery extends the recovery window. Wait until reputation has fully recovered before re-engaging them.

The recovery window depends on the depth of the damage. Mild cases (one bad campaign, otherwise healthy sender) recover in 1-2 weeks. Severe cases (recurring hygiene issues over months) can take 6-8 weeks of clean sending. And the reputation that's been damaged at, say, Gmail recovers at a different rate than the reputation at M365. Different providers have different memory.

08How much one bad campaign actually costs

A representative cost calculation, using rough numbers for a mid-volume sender:

• Direct cost of the bad campaign: 5,000 bounces × your ESP's bounce-tracking overhead (negligible) + opportunity cost of the segment you targeted (variable)
• Reputation damage to next 4-6 campaigns: 14-point drop in inbox placement = ~14% of your real audience doesn't see those campaigns = if those campaigns drive $50/recipient lifetime value × 4 campaigns × thousands of affected subscribers, the cost runs into thousands of dollars
• Time cost of investigation and recovery: 4-8 hours of someone's time figuring out what happened + 2-6 weeks of constrained sending during recovery

The pre-send verification that would have prevented this: a few minutes, a few thousand credits ($0 on MailCull's Free tier for under 500 addresses; <$1 on Pro for a typical list). The cost asymmetry is the whole reason verification exists as a category.

09What this looks like in MailCull's evidence chain

For the kind of address that would bounce as 550 5.1.1 if you sent to it, MailCull's verdict pre-send looks like:

[email protected]                 ✗ undeliverable
─────────────────────────────────────────────────────────
syntax_valid              Email format passed RFC 5321 validation
mx_found                  MX record: example-corp-com.mail.protection.outlook.com
smtp_rejected             Server returned 550 5.1.1 (mailbox does not exist)

Confidence: 1.00

The smtp_rejected line surfaces the exact response code the real send would have triggered. The verdict is undeliverable because the protocol-level rejection is decisive. Drop the address pre-send and the bounce never happens; the chain reaction never starts; the reputation never degrades; the good subscribers never lose inbox placement.

That's the value of the evidence chain: not just "this is invalid" but the protocol-level proof that the receiving server already told us so.

10The practical takeaway

Sending to an invalid address isn't just a wasted email. It's the start of a multi-week reputation degradation that costs you reach across your entire list, not just the bad addresses. Pre-send verification is the cheap way to break the chain before it starts.

Start free: 500 credits per month, no credit card. Full SMTP probing on every address; every verdict carries the SMTP reply that would have come back from a real send. The bounce-rate compounding stops the moment you verify.