Bounced From My Cold Inboxes, Delivered From My Gmail: What It Means

If the same address bounces from your cold email inboxes but accepts a test from your own mailbox, the address is real and the receiving server is refusing the sender. That usually means the sending IP, domain, tenant or volume is the problem, not your list. Read the bounce code to confirm it, then fix the sending side, because these bounces count against you just like bad addresses do.

A common version of this complaint: someone buys new inboxes, warms them, launches to a list verified the usual way, sees a 20-25% bounce rate, and then sends from a personal Gmail to a few "undeliverable" addresses that all go through. Support says the addresses were bad. The test says otherwise. Both can't be right, and the bounce messages will tell you which one is.

Step 1: Read the code, not the count

Export the bounces with the full SMTP reply and group them by enhanced status code. RFC 3463 defines the classes:

Code	What it says	What it points at
5.1.1	Bad destination mailbox	The address
5.1.2	Bad destination system (domain doesn't exist or has no mail route)	The domain on your list
5.7.x	Security or policy: blocked, unauthenticated, reputation	The sender
5.4.1 from Microsoft	Directory-Based Edge Blocking: the tenant has no such recipient	The address, despite the wording (Microsoft)
4.x.x	Temporary, try later	Often throttling of the sender

Paste a batch into the bounce message analyzer or the Bounce Doctor to sort them. Watch the text as well as the code: rejections that mention your IP address, your domain, a blocklist or "policy" are about you even when the code is generic.

Step 2: Run the comparison test properly

1. Pick 5-10 addresses that bounced with codes other than 5.1.1.
2. Send one plain message to each from a mailbox with a long, clean history: your own work account, not a new domain.
3. Wait an hour, then check for bounces.

If they go through, the addresses exist and the earlier rejections were about the sender. Keep the test small. Pushing cold volume through your main mailbox to prove a point puts the account you depend on at risk.

Step 3: Find what the receiver doesn't trust

• Shared or reseller infrastructure. Budget inbox resellers and some done-for-you sellers send from shared servers. Look up the sending IP from a test message's headers in the IP blacklist check. Our post on pre-warmed inboxes lists what to ask before buying.
• Authentication. A missing or misaligned DKIM or DMARC on a new domain shows up as 5.7.26-style rejections at Gmail and 5.7.509 at Microsoft. Check every domain with the bulk email authentication checker.
• Gateways. If the rejections cluster on companies behind Mimecast, Proofpoint or Barracuda, those filters may block unknown senders by policy. See cold email to enterprise companies.
• Volume and age. New domains sending at full volume look like what they are. Ramp slowly.

Step 4: Decide what to do with the list

Addresses that bounced with 5.1.1, or with Microsoft's 5.4.1, go on your suppression list. Addresses refused for sender reasons are still valid: hold them, fix the sender, and retry later from healthy infrastructure. Don't delete good contacts because the sending setup failed. Our post on verified emails that still bounce covers the other causes, from time between check and send to catch-all domains.

Verify so the list is out of the question

When the list is verified close to the send, any spike that follows is easy to diagnose: it isn't the data.

1. Upload the list on the verify page. Every address gets a live mailbox check, and valid, risky and invalid download as separate files.
2. Send to the valid file.
3. Re-check anything older than about 30 days before the next campaign.

Where SimpleVerifier fits

The analyzers above are free. For mailbox checks, the first 100 are free with a Google sign-in on the verify page. Starter is $9 a month for 2,500 checks, and Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off. See pricing.