Every bounced email is a signal to Gmail, Outlook, and Yahoo that your list quality is poor. Migomail processes SMTP bounce responses in real time — classifying hard bounces, soft bounces, and blocks, suppressing permanently undeliverable addresses immediately, and giving you the analytics to understand exactly why emails are bouncing.
A bounce rate above 2% signals to mailbox providers that you are sending to low-quality, outdated, or purchased lists. Migomail processes every SMTP response, classifies every bounce, and takes the right action automatically — in under 60 seconds.
Every SMTP delivery response — success, temporary failure, or permanent failure — is processed by Migomail within 60 seconds of receipt. Bounce events are classified, subscriber records are updated, and suppression decisions are made automatically. There is no nightly batch job and no manual list management step between the bounce event and the suppression action.
Hard bounces — permanent delivery failures caused by a non-existent email address, invalid domain, or permanently rejected mailbox — are suppressed immediately on first occurrence. The address is moved to the global suppression list and excluded from all future sends automatically. Hard bounce addresses are never retried — retrying them wastes sends and increases your overall bounce rate.
Soft bounces — temporary failures caused by a full mailbox, temporarily unavailable server, or rate limiting — are retried automatically using an exponential backoff schedule. Migomail retries soft bounces at increasing intervals (15 minutes, 1 hour, 4 hours, 24 hours) and suppresses the address only after crossing a configurable failure threshold (default: 5 soft bounces within 30 days).
Migomail classifies every bounce using the full SMTP status code — the 3-digit code (e.g., 550, 421, 452) and the enhanced status code (e.g., 5.1.1, 4.2.2) — to determine the exact reason for the bounce and the correct action. The classification database covers 50+ unique bounce scenarios across all major mailbox providers.
Provider-level blocks — where Gmail, Outlook, or Yahoo is refusing to accept mail from your domain or IP based on reputation signals — are a different problem from address-level bounces and require a different response. Migomail classifies provider blocks separately, alerts you immediately with the provider, the block reason, and a recommended remediation action.
A dedicated bounce analytics dashboard shows your bounce rate over time — split by bounce type (hard, soft, block) and by SMTP code. Trend charts let you identify sudden spikes (which indicate a list quality problem) and gradual increases (which indicate natural decay). Per-campaign bounce analysis shows which specific campaign or list segment is generating elevated bounces.
If you are migrating from another platform and have a historical bounce list you want to carry forward, you can import it into the Migomail global suppression list — so hard-earned suppression history is not lost in the migration. Import accepts a CSV of email addresses with optional bounce reason and date fields.
All bounce-suppressed addresses feed into the same global suppression list that handles unsubscribes, complaints, and manual suppressions. The suppression check happens at send time — so a hard-bounced address that is later re-added to a list through an import or form submission is automatically excluded from the next send without any manual intervention.
Every bounced email generates a structured SMTP response from the receiving mail server. Migomail reads and classifies this response within 60 seconds to determine whether the bounce is hard (permanent), soft (temporary), or a provider block.
The 3-digit SMTP status code is the primary classification signal. Codes starting with 4 (4xx) are temporary failures — retry eligible. Codes starting with 5 (5xx) are permanent failures — the address should be suppressed. Codes starting with 2 (2xx) are delivery successes.
The enhanced 3-part status code (e.g., 5.1.1) provides more specific failure detail. The first digit matches the SMTP code class (4 or 5). The second digit identifies the subject (1=addressing, 2=mailbox, 3=mail system, 4=network, 7=policy). The third digit provides the specific reason.
A hard bounce indicates a permanently undeliverable address — the mailbox does not exist, the domain does not accept mail, or the address has been permanently deactivated. Migomail suppresses hard bounces immediately on first occurrence and never retries them.
A soft bounce indicates a temporary failure — the mailbox is full, the server is temporarily unavailable, or the recipient server is rate-limiting incoming mail. Migomail retries soft bounces using exponential backoff: 15 min → 1 hour → 4 hours → 24 hours. After 5 soft bounces within 30 days, the address is suppressed.
A provider block (5.7.x codes) is not an address-level failure — it is a reputation-level rejection affecting your entire sending domain or IP at that provider. Migomail classifies blocks separately from bounces, fires an immediate alert, and provides the specific remediation steps for the provider and block type.
Bounce rate is one of the primary signals mailbox providers use to assess list quality and sender behaviour. Different bounce rate levels trigger different responses — from no impact to permanent blacklisting. Know where you stand.
Not all bounces are the same problem. Treating a soft bounce the same way as a hard bounce wastes deliverable addresses. Treating a provider block the same as an address bounce misses the real issue. Migomail handles all three correctly.
Migomail's bounce processing pipeline handles the full journey from SMTP response to suppression — automatically, within a single minute of each delivery attempt.
These are the measured deliverability changes from a real Migomail customer account that implemented proper bounce management after letting bounces accumulate. 45-day before/after comparison, same list, same sending frequency.
Feedback from email managers, deliverability leads, and marketing operations teams who used Migomail's bounce management to recover from deliverability problems.
We had been re-sending to hard-bounced addresses for 18 months because our previous platform was not properly suppressing them. We knew something was wrong — our bounce rate was 3.1% — but we did not realise the platform was retrying addresses it should have permanently suppressed. After migrating to Migomail and running the bounce analytics, we identified 47,000 addresses that had bounced with 5.1.1 codes and were still in our active list. After suppressing them, our bounce rate dropped to 0.31% in 3 campaigns and our Gmail inbox placement went from 68% to 94.7% within 6 weeks. Those 47,000 addresses had been invisibly destroying our deliverability for over a year.
The SMTP code breakdown in Migomail's bounce analytics is the feature that changed how I diagnose deliverability problems. Before this, I knew my bounce rate was high — I had no idea why. Was it bad addresses? A list quality problem? A domain issue? After switching to Migomail, I opened the bounce analytics and saw that 78% of my hard bounces were 550 5.1.2 codes — "bad domain." That told me immediately that I had a batch of addresses with typos in the domain part — things like "gmail.cm" instead of "gmail.com" — from a specific sign-up form that was not validating email format. One lookup in the analytics, one fix to the form, problem solved. Without the SMTP code breakdown, I would have been guessing at the cause for weeks.
The distinction Migomail makes between soft bounces and hard bounces saved us a significant number of deliverable addresses that we would have permanently suppressed on our old platform. Our old system treated any bounce as a hard bounce if it saw a 550 code — even though some of those 550 responses were temporary server configurations that cleared within 24 hours. Migomail correctly retried those addresses, and approximately 12% of what we thought were permanent bounces resolved on the second or third attempt and delivered successfully. At our list size, that is several thousand additional deliverable addresses we would have incorrectly suppressed.
"Switching to Migomail cut our email costs by 40% and our inbox placement jumped to 98.7%. The onboarding team set up DKIM, SPF, and DMARC in a single call — and our campaigns have been running flawlessly ever since."
Rahul Menon
Head of Growth, SaaS Platform — India
Common questions about email bounce management and suppression.
A hard bounce is a permanent delivery failure — the email address does not exist, the domain does not exist, or the mailbox has been permanently deactivated. Hard bounces return 5xx SMTP codes with enhanced codes like 5.1.1, 5.1.2, or 5.1.3. They should be suppressed immediately and never retried. A soft bounce is a temporary delivery failure — the mailbox is full, the recipient server is temporarily unavailable, or the sender is being rate-limited. Soft bounces return 4xx codes (temporary) or occasionally specific 5xx codes that indicate the failure may resolve. They should be retried at increasing intervals before being permanently suppressed.
Within 60 seconds of receiving the SMTP rejection response. Migomail's bounce processing pipeline captures the SMTP response, classifies it against the bounce code database, updates the subscriber record, adds the address to the global suppression list, and recalculates campaign analytics — all within one minute of the delivery failure. There is no batch processing window and no overnight job — suppression is immediate.
By default, Migomail retries soft bounces four times using exponential backoff: 15 minutes after the first failure, 1 hour after the second, 4 hours after the third, and 24 hours after the fourth. If all four retries fail, the address is suppressed. Additionally, if an address accumulates 5 soft bounce events within a 30-day period (across multiple campaign sends), it is suppressed regardless of whether the individual retry sequence completed. Both thresholds are configurable in your account settings.
A provider block is a reputation-based rejection by a mailbox provider — Gmail, Outlook, Yahoo — that refuses to accept mail from your domain or IP address based on a policy decision, not because of a specific recipient address. Provider blocks generate 5.7.x SMTP codes (policy violations) rather than 5.1.x codes (addressing failures). They affect all sends to that provider, not just one recipient. Migomail classifies provider blocks separately from address-level bounces, fires an immediate alert, and provides specific remediation guidance for the block type and provider.
Below 0.5% is the target for a healthy email programme. Between 0.5% and 1% is acceptable but warrants investigation. Above 1% begins to affect Gmail inbox placement. Above 2% triggers systematic spam folder routing at most major providers. Above 5% risks IP/domain blacklisting. Migomail's bounce analytics dashboard shows your current bounce rate prominently, with a colour-coded severity indicator so you always know where you stand relative to safe thresholds.
Yes. If you are migrating to Migomail from another platform and have a CSV of hard-bounced addresses from your previous sending history, you can import it directly into the Migomail global suppression list. This preserves your bounce suppression history and prevents you from sending to addresses that bounced on your previous platform. The import accepts a CSV with at minimum an email address column, and optionally a bounce reason and date column.
No — and this is an important distinction most email platforms get wrong. Not every 550 response is a permanent hard bounce. For example, 550 5.7.1 is a policy rejection (provider block), not an address-level failure, and suppressing the address does nothing to fix the underlying problem. 550 responses associated with full mailboxes or temporary server configurations may resolve within 24 hours. Migomail reads the full enhanced status code (5.1.x, 5.2.x, 5.7.x, etc.) alongside the 3-digit code to determine the correct classification — distinguishing between address failures that warrant permanent suppression and policy rejections that require a different response.
Use the bounce analytics dashboard, which shows bounce rate and bounce code breakdown per campaign. Switch to the "by campaign" view to rank your recent campaigns by bounce rate — the campaign with the highest bounce rate is the source. Then open the campaign detail to see which recipient domain or list segment has the highest concentration of 5.1.x codes. Common causes of sudden bounce rate spikes include a new imported list segment with poor quality addresses, a sign-up form without email validation, a re-send to an old segment with high natural decay, or a purchased list.