Handle Hard Bounces in ESP Switch

Why hard bounces during an ESP switch can break your sender reputation

You just switched ESPs. The migration tool says it’s done. You’re sending your first campaign. Then the bounce rate spikes—3%, 5%, higher. You didn’t notice any invalid addresses before. Now your inbox placement is tanking.

Here’s the truth: hard bounces during an ESP switch aren’t just a data problem. They’re a reputation bomb. When your new provider sends to addresses that were already hard-bounced in the old system, it signals to ISPs that your list is stale or mismanaged. That can trigger blocks, throttling, or worse—permanent deactivation of your sending domain.

It’s like driving through a red light because your old GPS didn’t update the route. You’ve got the right destination, but the signal’s already flagged you as unsafe.

Key takeaways

Failure to migrate suppression lists during an ESP switch exposes your sender reputation to irreversible damage from hard bounces.
Hard bounces during migration are not just a technical glitch—they are a direct signal to ISPs that your email list is not properly maintained.
Preventing post-switch delivery failures starts with auditing and transferring old suppression data, including hard bounces and unsubscribes, to your new ESP.

What is a suppression list, and why does it matter during an ESP migration?

You need a suppression list during an ESP switch because it holds email addresses that have previously failed delivery, been unsubscribed, or triggered complaints. Failing to migrate it means sending to those addresses again—causing hard bounces and triggering spam filters. ISPs notice repeated failed sends to inactive addresses as spam trap behavior, which harms your sender reputation.

Why suppression lists exist in the first place

Every email program tracks delivery failures and user actions. Hard bounces, complaints, and unsubscriptions are signals that a recipient no longer wants your messages—or can’t receive them. A suppression list captures these records so you don’t waste resources re-sending to invalid or unwilling recipients.

Without it, you risk re-engaging with addresses that are permanently unreachable, such as those with non-existent domains or shut-down inboxes. These addresses may even be reserved by ISPs as spam traps. Sending to them, even once, can signal malicious intent. The signal is not just about one bounce—it’s about patterns: repeat attempts to reach known dead or blocked addresses.

The migration risk: how old hard bounces come back

Let’s say you switched from one ESP to another without transferring suppression data. Your new platform starts sending to a list that includes addresses you bounced months ago. Those addresses don’t exist anymore. The sending system sees them as hard bounces, even though they’re just old data.

In ISPs’ eyes, this behavior resembles spam: repeated delivery attempts to inactive or non-existent mailboxes. It’s a red flag. The Internet Society notes that spam detection systems rely on behavioral patterns, including sending to known bad addresses (see RFC 5321 on SMTP transaction rules). If your sending pattern includes old bounces, it reduces your chance of landing in inboxes.

Worse, if one such address is a trap, your entire domain’s reputation can degrade. The damage isn’t limited to a few failed messages—it compounds with each new send to an outdated bounce.

Using a verification tool before migration helps. For example, MailTester’s bulk verification can identify dead or risky addresses before you even consider a switch. It flags hard bounces, catch-alls, and disposable domains so you can clean your list upfront.

The two most common mistakes when migrating suppression lists across ESPs

You assume suppression lists transfer automatically between ESPs—most don’t. You copy raw email addresses from old systems without re-verification, risking fresh bounces on outdated or poisoned addresses. These errors tank sender reputation, increase hard bounce rates, and trigger deliverability filters. Let’s fix that.

Assuming suppression lists transfer automatically

ESP platforms don’t share suppression data by default. Migrating from SendGrid to Mailchimp? The suppression list stays behind. Even if the old system exports a list, it’s not guaranteed to be recognized by the new one.

Industry standards like RFC 5322 don’t mandate cross-platform sync. The responsibility is yours. Without explicit import, old bounces remain in the new system’s tracking, leading to repeated hard failures.

Check your ESP’s documentation carefully. Most require manual import via file or API. Even then, you’ll need to confirm the list was processed correctly—no automatic sync ever happened.

Copying raw addresses without re-verification

Raw suppression lists often contain addresses that are stale, misspelled, or have been poisoned (meant to trigger bounces). Just copying them directly into a new ESP’s suppression list doesn’t remove the risk.

For example, an email like [email protected] might no longer exist or be a disposable domain. But if it’s in your old list, it’ll still appear as bounced in the new system—without correction.

Before importing, verify every address. Use a tool like MailTester’s bulk verification to check validity, catch-all status, and inbox placement risk. You’ll catch poisoned or invalid entries that would otherwise harm deliverability.

Remember: a suppression list isn’t a static file. It’s a high-risk asset if unverified. Best practice? Purge old entries, re-validate, and import only clean, active data.

Check if your new ESP supports suppression list import via file or API.
Never assume a raw export from an old system is safe to upload.
Run all addresses through a real-time verification tool before adding to any new list.
Filter out catch-all domains, disposable emails, and role accounts before migration.
Test with a small batch first to confirm bounces don’t reoccur.

How to prepare your suppression list before migrating to a new ESP

You should export your suppression list from your old ESP in a clean, structured format—email, timestamp, and bounce reason—then clean it by removing duplicates, normalizing case, and trimming whitespace. Follow up by verifying every address with a high-accuracy email validation tool to eliminate outdated, invalid, or catch-all entries before import.

Step 1: Export your suppression list in a clean, standardized format

Start by exporting your suppression list directly from your current ESP. Ensure it includes at minimum three columns: the email address, the timestamp of the suppression event, and the bounce reason (e.g., "hard bounce," "user unknown," "mailbox full"). This data is critical for auditing and compliance. Some platforms, like Amazon SES or SendGrid, allow exports with this metadata; if yours doesn’t, check the documentation for programmatic access.

Step 2: Clean duplicates and normalize formatting

Many systems treat email addresses with different cases—like [email protected] and [email protected]—as distinct. This leads to unnecessary suppression or double entries. Use a script or spreadsheet function to standardize everything to lowercase. Also, remove duplicate entries—especially those with the same email but different timestamps or reasons. This reduces noise and prevents false positives during migration.

Verify every email using a real-time, high-accuracy service. You can't trust your old ESP’s internal list to be reliable—many hard bounces are outdated or misclassified. Use a service like MailTester’s bulk email verification to validate every address against current SMTP, MX, and DNS records. This catches invalid domains, catch-all setups, and disused accounts before they cause deliverability issues at scale.
Focus on hard bounce codes. Not all bounces are equal. Only suppress addresses that returned 5xx SMTP error codes (like 5.1.1, 5.2.2) indicating permanent delivery failure. Let your verification tool flag these so you can review and retain only valid hard bounces.
Filter out role accounts and disposable domains. Some suppression lists include admin@, sales@, or tempmail.com addresses that aren't legitimate recipients. Use the same verification system to filter out these risky or disposable domains. This prevents accidental suppression of addresses that might still be valid or useful.

After verification, export the filtered list with only valid, confirmed hard bounces and discard the rest. This ensures your new ESP receives a clean, accurate signal—reducing the risk of being flagged for spam or blocked by inboxes.

Industry best practices from RFC 5321 and RFC 5322 emphasize that email senders must maintain accurate address records. A clean suppression list isn’t just about compliance—it improves sender reputation by avoiding repeated delivery attempts to invalid addresses.

When you’re ready, use the MailTester integrations with platforms like Klaviyo, HubSpot, or SendGrid to automate ongoing suppression list hygiene after migration.

How MailTester helps eliminate hard bounces before they impact your new ESP

You can prevent hard bounces during ESP migration by verifying your list before switching. MailTester’s bulk verification flags invalid, catch-all, and risky addresses—keeping your suppression list clean and reducing the risk of damaging sender reputation on your new platform. With 98.9% accuracy, it stops the vast majority of problematic addresses before they ever hit a new ESP’s system.

Identify problems before the migration

Before you even begin the switch, MailTester runs a full bulk verification on your list. It checks each address against real-time SMTP and DNS responses, catching invalid emails, disabled accounts, and domains that silently reject mail. This isn’t guessing—it’s a technical validation process that mirrors how real email servers behave. The result? A clean list, fewer hard bounces, and a smoother onboarding to your new ESP.

Let’s say you’re moving from an old system to SendGrid. If your suppression list includes stale or improperly formatted addresses, those will be flagged and removed by MailTester. This reduces the risk of triggering rate limits or being marked as a spam source immediately after launch. By catching these issues early, you avoid the worst scenario: sending to a list that gets rejected by the new platform’s filters.

Sync verified data directly with your ESP

MailTester integrates directly with SendGrid, Mailchimp, HubSpot, and Klaviyo—so you don’t have to manually clean or re-upload your list. After verification, you can sync the filtered, validated data right into your new email service provider. This preserves your suppression list integrity and prevents new bounces from the start.

When you’re using a real-time verification API, you can also test individual addresses as they’re added or updated, which is vital for ongoing list hygiene. The API is designed to integrate smoothly into your workflows—for example, validating user sign-ups at the point of entry, or cleaning a list before a major campaign. You’re not just migrating a list; you’re upgrading its quality.

For details on how this works, see how bulk verification can improve your deliverability or explore integration options with your existing tools. Accuracy isn’t about confidence—it’s about the system actually working. With MailTester, you’re not relying on heuristics; you're using validated data to build a clean, compliant list.

Industry standards like RFC 5321 and practices from providers like Spamhaus emphasize the importance of list quality. Every hard bounce you avoid is a step toward better inbox placement and stronger sender reputation.

Why verifying a suppression list is not redundant—just because the email failed before

Just because an email bounced doesn’t mean it’s invalid. A hard bounce could stem from a full inbox, a temporary server issue, or a spam filter—none of which mean the address is dead. If you blindly purge your list based on old bounces, you might discard valid contacts who just had a one-time delivery hiccup. Verifying ensures you’re not penalizing legitimate users who only failed once.

Not all bounces mean the address is gone

Transient issues like a recipient’s mailbox being full or an IP being temporarily blacklisted can cause hard bounces. These errors don’t reflect the current state of the email address. The same address might now be fully operational, especially if the server issue has resolved. Relying solely on bounce history can lead to over-migration of clean contacts.

According to RFC 6521, SMTP servers should reject messages with a temporary error code (e.g., 4xx) when delivery is delayed but not permanently blocked. Hard bounces (5xx) are only appropriate when delivery fails permanently. Yet many systems treat all failures as permanent, leading to premature removals.

Some addresses were once valid—but not anymore

Even if an address bounced, it may have been valid years ago. Domains can shut down, employees leave, or roles go unmanaged. These addresses are no longer reachable, but you can’t tell just by the bounce. You must verify the current status to know whether to suppress or retain.

Using a real-time verification service like MailTester’s bulk verification checks current deliverability and syntax validity. It confirms whether an address is still active, catches disposable domains, and identifies catch-all addresses that accept all emails—common in old or poorly managed databases.

Let’s say you’re migrating from an old ESP and importing your suppression list. Even if an address bounced in the past, a current verification might show it’s active again. Or it might reveal that a previous bounce was due to a blocked domain—one that now has proper authentication and delivers fine. Without re-verifying, you’re guessing.

You aren’t just cleaning a list—you’re protecting your sender reputation. Over-suppression reduces engagement. Under-suppression risks spam traps and complaints. Verification gives you the clarity to decide: remove only what must be removed, keep what can be saved.

What to do with addresses MailTester flags as 'catch-all' or 'risky' in a suppression list

When MailTester marks an email as 'catch-all' or 'risky', exclude it from your suppression list migration. Catch-all domains accept all mail regardless of validity—sending to them wastes resources and can harm your sender reputation. Risky addresses may have temporary failures or known delivery issues; including them in campaigns risks bounces and lower inbox placement. Use MailTester’s real-time verification API during list uploads or syncs to filter these out dynamically before they hit your ESP.

Catch-all domains: hidden risks in suppression lists

Catch-all domains aren’t exceptions—they’re a common misconfiguration where mail servers accept messages for any address, even non-existent ones. This can create false positives in your list: an address appears valid but receives no real delivery. Sending to these addresses floods the receiving server, increasing the chance of your messages being flagged as spam or ignored. The SMTP standard (RFC 5321) clearly defines how mail should be routed, but it doesn't mandate catch-all handling—so their presence is a sign of weak domain hygiene.

Risky addresses: don’t gamble with reputation

When MailTester marks an address as 'risky', it means the inbox is likely to deliver erratically—due to throttling, temporary DNS errors, or known spamtrap links. These often originate from disposable email providers, outdated lists, or misconfigured mailboxes. Even if they don't hard bounce, they can trigger soft bounces or delay delivery, which erodes your sender reputation over time. Since these issues rarely resolve spontaneously, keeping them in future campaigns is a poor use of your sending capacity.

Instead, use MailTester’s verification API during your ESP migration to catch these early. Integrate it with your data pipeline so every batch uploaded or synced gets real-time validation. This stops catch-all and risky addresses from ever making it into your suppression list or campaign send queue. You’ll reduce waste, avoid blocklist risk, and improve long-term deliverability—even during complex transitions like an ESP switch.

How to validate a suppression list using the MailTester bulk verification API

You can validate a suppression list by uploading it to MailTester via CSV or API, then using the verification endpoint with a check parameter to assess each address. Filter results for 'invalid', 'catch-all', or 'risky' statuses—these should be excluded before migrating to a new ESP, as they risk hard bounces, reputational damage, and delivery issues.

Prepare your suppression list as a clean CSV file with one email address per row. Remove duplicates and ensure no personal identifiers are included. A clean source file reduces noise during verification.
Upload via CSV or API to MailTester’s bulk verification tool. Use the bulk verification page for a quick upload, or integrate directly using the verification API for automated workflows in your migration pipeline.
Initiate verification with the check parameter in the API request. This triggers checks for syntax, domain existence, MX records, and mailbox status—deliverability signals that identify invalid or non-receptive addresses.
Review results for 'invalid', 'catch-all', or 'risky' statuses. An 'invalid' address fails basic syntax or domain checks. A 'catch-all' mailbox accepts all emails regardless of recipient, leading to high bounce rates. A 'risky' address has a low inbox placement likelihood or known spam associations. These statuses indicate poor deliverability and should be withheld from your new ESP’s sending list.
Export and filter the validated data to exclude all addresses marked as invalid, catch-all, or risky. This refined list ensures only valid, responsive inboxes remain—reducing bounce rates and protecting sender reputation.

Why this step matters

Ignoring suppression list validation increases the risk of hitting hard bounces during ESP switch. According to industry standards, even a 0.1% bounce rate can trigger sender reputation penalties. A clean suppression list protects your new ESP’s sending health and maintains consistent inbox placement. Services like Spamhaus and MXToolbox confirm that sender reputation is influenced by consistent bounce and complaint data, not just volume.

MailTester’s 98.9% accuracy rate—verified across real-world sender environments—means you’re not just filtering noise; you’re identifying real delivery risks before they harm your new ESP’s reputation. You can test the integrity of your list at any point using the same API endpoints or by checking individual addresses with the email checker.

The real-time verification API: a tool for ongoing list hygiene during ESP transitions

You can prevent hard bounces during an ESP switch by validating every new email address in real time—before it hits your list. Integrating the API into your CRM or data pipeline ensures only valid, deliverable addresses are added, catching risky, outdated, or dormant addresses before they become problematic. This keeps your new ESP’s reputation intact from day one.

Verify new addresses before they enter your system

When you’re migrating your list, new sign-ups keep arriving. Let’s be honest: even well-maintained lists can gather bad addresses over time. The real-time verification API checks each incoming address instantly against DNS, SMTP, and mailbox validity. Use it at the point of entry—whether it’s a form submit, API call, or sync from your CRM—to reject invalid, typo-ridden, or disposable emails before they ever join your database.

This isn’t just a one-time fix. It’s a continuous safeguard. You’re not just purging old junk—you’re stopping new junk at the door. The API respects sender reputation by avoiding test sends that look like spam, using only standard, traceable checks. It’s an industry-standard practice backed by tools like RFC 5321, which outlines SMTP behavior and mailbox validation logic.

Stop dormant addresses from becoming hard bounces

Soft bounces—temporary delivery failures—are often ignored, but they can evolve into hard bounces if the address never recovers. Let’s say an old customer hasn't opened an email in 18 months. You might still be trying to reach them. The API can detect these dormant or inactive addresses during uploads, flagging them as risky before you send anything.

During list migration, this prevents your new ESP from inheriting poor quality. High bounce rates during onboarding hurt domain reputation, especially with providers like Gmail and Outlook that track long-term engagement. By catching these issues early, you avoid triggering auto-blocks or sending throttles.

Use the API during every bulk upload. Run a test on a small sample first. Then scale it across your entire workflow. With MailTester’s real-time verification API, you get 98.9% accuracy with no expiry on credits, making it a reliable, long-term solution for ongoing hygiene during and after ESP transitions.

After migration: how to monitor for residual hard bounces using inbox-placement testing

After switching ESPs, send test emails through MailTester’s inbox-placement tool to verify whether your curated list reaches primary inboxes across Gmail, Outlook, and Apple. If deliverability drops, it often means your suppression list still contains outdated or invalid addresses. Re-verify the list using MailTester’s real-time email checker to catch any remaining hard bounces before they harm sender reputation.

Run inbox-placement tests post-migration

Send a test batch to a diverse set of inboxes using MailTester’s inbox-placement service. Include addresses from major providers—Gmail, Outlook, Yahoo, Apple Mail. This simulates real-world delivery conditions across different filtering systems.
Check if messages land in primary inboxes rather than spam or junk folders. Low inbox placement rates signal that your list includes addresses that are flagged, suppressed, or invalid—common after migration if suppression lists weren’t cleaned thoroughly.
Compare results with pre-migration benchmarks if available. A sudden drop in primary inbox delivery often correlates with residual hard bounces caused by outdated suppression lists. Monitoring this helps pinpoint issues early.

Re-verify your final suppression list

Hard bounces after migration often mean your suppression list still holds addresses that were once valid but are now inactive, blocked, or catch-all. Even a single invalid address can hurt deliverability, especially if sent to in large volumes.

The 3 steps described in “Run inbox-placement tests post-migration”, in order.

Use MailTester’s bulk verification tool to re-scan your final suppression list. It checks for syntax, domain validity, mailbox existence, and known blocks.
Filter results by verdict: exclude any marked as “invalid” or “risky” and ensure you’re not blocking valid users unintentionally.
Re-import your cleaned list into your new ESP. This step protects sender reputation and aligns your list with best practices—such as those outlined in RFC 5321, which governs SMTP behaviors including bounce handling.

Even after migration, a poor suppression list can silently degrade inbox placement. Regular testing and re-verification are not optional—they’re essential for maintaining sender trust.

Conclusion: Protect sender reputation by treating suppression list migration as a verification step, not a copy-paste task

Switching ESPs doesn’t eliminate hard bounces—it just moves the risk to your new provider. Old suppression lists often contain outdated, invalid, or inaccurate entries that can trigger bounces and harm deliverability from day one.

Verifying your suppression list before migration is not optional. It’s the only way to ensure that only valid, up-to-date addresses are passed on. This step prevents send volume loss, reduces spam complaints, and maintains your sender reputation.

With MailTester’s 98.9% accuracy and real-time integrations across Mailchimp, HubSpot, Klaviyo, and SendGrid, you can verify your list in bulk and catch issues before they impact your new ESP. This approach helps prevent up to 99% of avoidable bounces.

Sources

Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Does MailTester verify emails on suppression lists?

Yes. MailTester checks every email in a suppression list for validity, catch-all status, and risk level, helping you cleanse old bounces before migration.

Can I verify suppression lists directly in Mailchimp or Klaviyo?

Yes—the MailTester app integrates directly with Mailchimp, Klaviyo, HubSpot, and SendGrid to verify suppression lists before and during migration.

What happens if I migrate a suppression list without verifying it?

Old addresses that are invalid or catch-all may still deliver as hard bounces, damaging sender reputation and hurting inbox placement in the new ESP.

How accurate is MailTester’s email verification?

MailTester achieves 98.9% accuracy across bulk and real-time verifications, using SMTP checks and domain-level analysis to determine address health.

Do purchased credits expire on MailTester?

No. Your purchased verification credits never expire, allowing you to plan list hygiene tasks without time pressure.

Can I test inbox placement with MailTester after switching ESPs?

Yes. MailTester offers inbox-placement testing to confirm whether messages land in primary inboxes across major providers after migration.

How many free verifications does MailTester offer?

You get 100 free verifications to start, with no expiry on any purchased credits.

Why is hard bounce prevention critical during ESP switches?

Hard bounces signal poor list hygiene to ISPs, risking blacklisting and reduced deliverability in your new ESP.

What’s the difference between a hard bounce and a soft bounce?

A hard bounce is permanent (e.g., invalid email or domain), while a soft bounce is temporary (e.g., full inbox). Hard bounces impact sender reputation more severely.

How does MailTester handle disposable domains in suppression lists?

MailTester detects and flags disposable email domains during verification, helping you exclude them from your suppression list before migration.

Can I use MailTester’s AI assistant to interpret verification results?

Yes. The in-app AI assistant helps explain verification verdicts and suggests cleanup actions, like removing catch-all or risky emails.

What’s the best practice for integrating MailTester during an ESP migration?

Run a full list verification on the suppression list before migration, then use the API in your ESP to validate all new addresses entering your system.