What Happens When You Email an Address That Doesn't Exist

When you email an address that does not exist, the receiving server usually rejects it during the SMTP conversation with a code like 550 5.1.1, and your sending system returns a bounce message to you. Nothing is delivered. The cost is on your side: every hard bounce raises your bounce rate, sending platforms pause campaigns at around 5%, and mailbox providers treat repeated sends to dead addresses as a sign of a poorly managed list.

This post traces exactly what happens, step by step, and shows where the line between "harmless" and "campaign paused" falls.

The four things that can happen to the message

Which path the message takes depends on what is broken: the domain, the mailbox, or the receiving server's configuration.

What is wrong	What the receiving side does	When you find out	Counts as
The domain does not exist or cannot take mail	Nothing. Your server cannot find anywhere to deliver	Within seconds	Hard bounce
The mailbox does not exist, and the server checks	Rejects at RCPT TO with a 5.x.x code	Within seconds	Hard bounce
The mailbox does not exist, but the server accepts first	Accepts, then fails delivery and sends a bounce notice	Minutes to hours later	Hard bounce
The address is a spam trap or a catch-all inbox	Accepts silently	Possibly never	Not a bounce, but a different risk

Path 1: the domain cannot receive mail

Your sending server looks up the domain's MX record. If the domain does not exist at all, there is nowhere to connect, and your server reports an error.

If the domain exists but has no MX record, RFC 5321 says the address "is treated as if it was associated with an implicit MX RR" pointing at the domain itself. If nothing there accepts mail, the send fails. A domain can also publish a null MX record (RFC 7505) to say outright that it takes no mail. The MX lookup tool shows what any domain publishes.

RFC 3463 gives this case the enhanced status code X.1.2, "Bad destination system address": "The destination system specified in the address does not exist or is incapable of accepting mail."

Path 2: the server rejects the mailbox

This is the common case. Your server connects to the recipient's mail server, announces the sender, and names the recipient with RCPT TO. The receiving server checks its directory and replies with a permanent failure, for example:

550 5.1.1 The email account that you tried to reach does not exist.

That wording is Gmail's, from Google's list of SMTP error codes.

The 5 at the start means permanent. The 5.1.1 is RFC 3463's "Bad destination mailbox address": "The mailbox specified in the address does not exist." Each provider words it differently. Our 550 5.1.1 reference and the guide to what Gmail, Outlook and Yahoo say when a mailbox doesn't exist quote the real messages.

Because the rejection happens before the message body is sent, nothing is delivered. Your sending server or platform then records the failure and, for most setups, sends you a bounce notice. The standard format for that notice is a Delivery Status Notification, defined in RFC 3464, which can report "failed delivery, delayed delivery, successful delivery" and more.

Path 3: the server accepts, then bounces later

Some servers accept every recipient first and check later. Security gateways often work this way, and so do some catch-all configurations. The message gets a 250 OK, so your platform logs it as sent.

Then the server behind the gateway rejects it. RFC 5321 section 6.1 requires that: "If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message." That notice goes to your envelope sender address, minutes or hours later. Your sending tool, if it processes bounce emails, records a hard bounce.

The delay is why a list can look clean on the day you send and show bounces the next morning. We cover this case in depth in verifying emails behind Proofpoint, Mimecast and Barracuda.

Path 4: the message is accepted and nobody reads it

Two things accept mail for addresses no person uses:

• Catch-all domains deliver everything to a shared or unmonitored inbox, or discard it.
• Spam traps are addresses run to catch senders with poor list practices. Some are old addresses that bounced for a long time and were then turned back on.

Neither produces a bounce, so neither shows up in your bounce rate. Spam traps are their own problem.

What happens on your side

The mailbox provider rejected the message cleanly. The consequences land on the sender.

Your sending platform counts it

Every hard bounce goes into your bounce rate, and platforms act on that number.

Platform	What it says
Amazon SES, reputation metrics	"If your bounce rate is 5% or greater, we automatically place your account under review. If your bounce rate is 10% or greater, we might pause your account's ability to send additional email"
Instantly, high bounce auto-pause	"We will automatically pause campaigns when the bounce rate exceeds 5%", enabled by default and adjustable
Smartlead, bounce autopause	Pauses campaigns that exceed a bounce threshold you set, and sends a webhook

More platforms are listed in bounce rate limits by platform.

Amazon SES also explains why it cares: "Email providers interpret a high bounce rate as a sign that a sender isn't properly managing their recipient list, and that the sender might be sending unsolicited email." It counts only hard bounces, "when an email is sent to an address that doesn't exist".

Mailbox providers read it as a list-quality signal

The big mailbox providers say the same thing in their sender guidance:

• Yahoo, sender best practices: under "Remove invalid recipients", it says sending to users who are not reading your mail "will harm your delivery metrics and reputation" and advises: "Remove invalid recipients from your list promptly."
• Microsoft, in its announcement of Outlook's requirements for high-volume senders: "Remove invalid addresses regularly to reduce spam complaints, bounces, and wasted messages."
• Google, email sender guidelines: "If messages start bouncing or start being deferred, reduce the sending volume until the SMTP error rate decreases."

None of them publishes a formula for how bounces feed into filtering. What they agree on is the direction: repeated sends to dead addresses mark a sender as careless with their list.

Cold email feels it fastest

A marketing platform sending 100,000 messages can absorb a few hundred bounces. A cold email setup sending 40 messages a day from each of five inboxes cannot. The arithmetic below shows why.

Worked example: the same list, before and after verification

A team sends 1,000 first-touch emails a day across 20 inboxes, 50 per inbox. The list is a six-month-old export. The invalid rates are illustrative. Measure your own by verifying a sample.

	Unverified list	Verified list (invalid removed, risky capped)
Share of addresses that hard-bounce	8%	1%
Hard bounces per day	80	10
Hard bounces per inbox per day	4	0.5
Campaign bounce rate	8%	1%
Instantly default auto-pause (above 5%)	Paused	Not paused
Amazon SES review line (5%)	Over	Under

With the unverified list, every inbox carries four hard bounces a day, every day, and the campaign is over a 5% pause line before the first follow-up. With the verified list, the same volume runs at 1%.

The money is the smaller part. 80 wasted sends a day is 80 prospects who were never going to reply. The bigger cost is the pause, the investigation and the days of reduced volume afterwards.

Measure your own invalid rate before you send

You do not need to guess the invalid share of a list. Verify it, or at least a random sample of it, before the first send.

1. Sort the list randomly and take 500 rows. The first rows of an export are often the freshest, so do not take them.
2. Verify the sample and count invalid results.
3. Read the result as a range. With 500 rows, 20 invalid (4%) gives a 95% range of about 2.6% to 6.1%.
4. If the top of the range is near your platform's pause line, verify the whole list before sending anything. In practice, verify the whole list anyway. It costs less than one paused campaign.

A sample tells you how bad the list is. Only a full verification tells you which addresses to remove.

What does not happen

A few myths, cleared up.

• The recipient's company is not notified. There is no recipient. The receiving server logs the rejected attempt like any other.
• One bounce does not blacklist you. Typos happen on every list. Patterns, not single events, drive platform pauses and provider filtering.
• The bounce is not "just a soft fail you can retry". A 5.x.x code is permanent. Retrying the same dead address only adds another bounce. Soft bounces (4.x.x) are temporary and handled differently.
• A verifier does not "send a test email". An SMTP check stops before any message is sent.

What to do about it

1. Verify before every first send, and before re-mailing any list more than a few weeks old. Remove invalid results. Treat risky results (catch-all and unverifiable) as their own segment, capped by your bounce budget. The catch-all decision framework shows how.
2. Suppress every hard bounce at once, in every tool, and keep it on a master suppression list so it cannot return in the next export.
3. Watch bounces per inbox, not just per campaign. Concentrated bounces on a new inbox or domain do more damage than the same number spread across many.
4. If you have already sent and bounces spiked, follow a recovery plan rather than pushing on.

SimpleVerifier checks each address against the receiving mail server without sending anything, and returns valid, risky or invalid. Anything it cannot confirm, including catch-all and unverifiable mailboxes, comes back risky, never valid. Pay-as-you-go packs are $9 for 2,500 addresses or $19 for 10,000, and Pro is $29.99 a month for unlimited checks with the API. See pricing, or try a single address with the email checker.

The short version

An email to a dead address is rejected, usually instantly with 550 5.1.1, sometimes hours later as a bounce notice. Nothing is delivered and nobody is notified. The damage is to you: every hard bounce lifts your bounce rate, platforms pause at around 5%, and Yahoo, Microsoft and Amazon all treat invalid recipients as a sign of a badly managed list. Verify before you send, and suppress every bounce for good.