Transform Mailgun Hard Bounces into Standardized 5xx Codes

Why Mailgun hard bounces don't always mean invalid email addresses

You’re cleaning your list, trusting Mailgun’s hard bounce reports to flag dead addresses—but what if some of those "hard bounces" were just temporary? You’re not alone. Many teams assume a hard bounce equals an invalid address, but that’s not always true.

Mailgun’s hard bounce classification includes both permanent failures—like a missing domain or non-existent mailbox—and temporary issues such as a full inbox, server overload, or greylisting. Without distinguishing between them, your validation logic starts making mistakes: valid users get wrongly marked as invalid, and real invalid addresses slip through.

This ambiguity turns your list hygiene into a guessing game. You can’t reliably transform Mailgun's hard bounces into standardized 5xx codes for validation APIs unless you decode what’s actually failing—and why.

Key takeaways

• Mailgun hard bounces encompass both permanently invalid addresses and temporary delivery failures like greylisting or full inboxes.
• Without differentiating permanent failures from transient ones, your API validation logic generates false positives and false negatives.
• Standardizing Mailgun hard bounces into 5xx codes requires mapping bounce types to their root causes—not treating all hard bounces equally.

How standardized 5xx codes improve email list validation reliability

When Mailgun returns a hard bounce with a standard 5xx SMTP error code—like 550, 551, 552, 553, 554, or 555—it’s not just a message; it’s a definitive signal from the recipient’s server that the email address is permanently invalid. By mapping these codes to a consistent "invalid" verdict in your validation API, you stop treating transient or ambiguous results as final. This approach reduces false positives and improves reliability across your email campaigns.

5xx codes are not all equal. Only definitive failures should mark an email as invalid.

SMTP error codes starting with 5xx are defined in RFC 5321 and RFC 5322 as permanent failures. But not every 5xx code means the address doesn’t exist. For instance, a 550 error often means the recipient was rejected outright—commonly due to a non-existent mailbox or blocked domain. A 552 (exceeded storage) or 554 (blocked) may also indicate a permanent issue. In contrast, a 551 (user not local) or 553 (mailbox name not allowed) signal that the address is invalid at the receiving end.

Let’s say you’re processing a Mailgun hard bounce. If you see a 550 code, it’s not guesswork—it’s a known, standardized refusal. You can safely mark that email as invalid. But if you only see a 5xx without checking the subcode, you risk classifying a temporary failure as permanent. That’s where standardization matters. It ensures only clear, unrecoverable failures—like 550 or 554—trigger an invalid status.

What happens when you skip the standard and treat all 5xx codes the same?

When validation systems treat all 5xx codes as equivalent, they create noise. A temporary delivery rejection (like 554 due to greylisting) gets misclassified as a permanent failure. This inflates your list invalidity rate, leading to unnecessary list scrubbing and lost campaigns. Worse, it can hurt sender reputation when you remove valid users based on incomplete data.

Standardizing on RFC-defined 5xx codes lets you build a more accurate validation pipeline. It’s an industry-standard practice. When you map only permanent failures (such as 550, 551, 552, 553, 554, 555) to “invalid,” you’re acting on verified evidence, not speculation. Tools like real-time email verification APIs use this exact logic—checking SMTP responses against known error standards to prevent false negatives and false positives.

The result? More consistent list hygiene, fewer wasted sends, and better inbox placement. It’s not about speed. It’s about precision. And precision starts with understanding what the server actually told you.

What causes Mailgun to return a hard bounce for a valid email?

You're seeing hard bounces from Mailgun for email addresses that are actually valid because of temporary server behaviors — not invalidity. Greylisting, full inboxes, rate limits, and catch-all domains can all trigger false hard bounces, leading to unnecessarily poor list hygiene and wasted sends. These issues are common, especially with new or low-volume senders.

Common reasons Mailgun logs a hard bounce when the email is valid

• Greylisting: Receiving servers temporarily reject your message while they validate your sending IP and envelope sender. This is common with smaller senders or those using shared IPs. The delay is typically 10 to 30 minutes. While Mailgun will retry, the first failure is logged as a hard bounce. RFC 6531 outlines how SMTP servers handle such cases.
• Overloaded mailbox: The user's inbox has reached its storage limit. The server refuses the message but keeps the address valid. Once space is freed, the same address accepts mail. Mailgun treats this as a hard bounce, but it’s a temporary condition, not a permanent error.
• Rate limiting or temporary IP block: Recipient servers throttle or temporarily block IP addresses that send too many messages too quickly. This often happens when sending to a list without proper warming. Even valid emails fail here, misleading validation tools into marking them as invalid.
• Catch-all domains: Some servers accept mail for any address, even if no user exists. Mailgun interprets delivery failure — usually, a 5xx response — as hard bounce. But this doesn’t mean the address is invalid. It means the server is configured for broad acceptance, not strict verification.

How to fix or filter out false hard bounces in validation

Hard bounces from Mailgun don’t always mean an address is invalid. Relying solely on them leads to data loss and poor segmentation. Instead, implement a validation process that distinguishes between permanent and temporary delivery failures.

Use a service that applies multiple verification layers—SMTP checks, syntax validation, and domain reputation—before flagging an address as bad. Bulk email validation helps clean your list before sending, reducing the number of false hard bounces and improving long-term deliverability.

How to filter Mailgun hard bounces by actual delivery failure

You can transform Mailgun hard bounces into standardized 5xx codes by inspecting the SMTP response in the bounce payload. Only treat addresses as invalid if the server returns a definitive 5xx code like 550 (user unknown), 551 (user not local), or 553 (invalid syntax). Ignore transient codes like 4xx, 552 (mailbox full), or 553 with soft failure semantics. Use a mapping table to filter out false positives and only flag permanent delivery failures.

Step-by-step: Identify real delivery failures in Mailgun bounces

1. Extract the SMTP status code from Mailgun’s hard bounce payload. When Mailgun returns a bounce notification, the response includes an SMTP status code (e.g., 550, 552, 553). This is the first signal of whether the failure is permanent or temporary. The code must align with RFC 5321, which defines SMTP status codes and their meaning.
2. Focus only on definitive 5xx failures like 550, 551, and 553. A 550 (user unknown) means the recipient mailbox does not exist. A 551 (user not local) indicates the server refuses to accept mail for that address. A 553 (invalid syntax) implies the email address format is malformed. These are permanent and should be flagged as invalid.
3. Exclude 552 (mailbox full) and other soft-failure codes. Even though 552 is a 5xx code, it's temporary. Mail servers return it when storage is full, not when an address is invalid. If your system treats 552 as a permanent failure, you'll incorrectly remove valid users. Only apply this to persistent issues over multiple attempts.
4. Ignore 4xx codes and transient 5xx statuses. Codes like 450 (mailbox unavailable) or 421 (service not available) are temporary by design. Let them flow through your pipeline without marking the address as invalid. These often resolve within hours, even minutes, if the server stabilizes.
5. Map codes to your validation logic using a known reference. Use a verified mapping like the one from IETF’s RFC 5321 or Spamhaus’s list of standardized SMTP status codes to ensure consistency. This prevents misinterpreting server-specific messages as failures when they’re not.

Why the right filters matter

Without filtering, you’ll treat mailbox full (552) or temporary server issues (4xx) as final failures. This leads to high false-positive rates and degraded list quality. According to an industry report from Return Path, poor bounce handling can drop deliverability by up to 20% over time.

Use this process to clean your Mailgun data. Then, validate the corrected list with a real-time tool that checks for syntax, domain existence, and inbox placement—like the real-time verification API from Email List Validation. It confirms delivery readiness before you send.

Map Mailgun’s hard bounce codes to standardized 5xx error types

You can transform Mailgun’s hard bounce codes into standardized 5xx error types by aligning each code to its corresponding SMTP response semantics. For example, 550 means the recipient doesn’t exist, 551 indicates a non-local mailbox, 552 signals a size limit exceeded (transient), 553 points to malformed syntax, 554 reflects spam detection failure, and 555 signals invalid address components. Mapping these ensures consistent error handling in validation APIs.

Standardizing Mailgun’s 5xx Bounce Codes

When integrating Mailgun with a validation API, you must translate Mailgun’s specific hard bounce codes into broader, standardized 5xx categories for accurate processing. These codes aren’t arbitrary—they reflect real SMTP-level rejection semantics.

Understanding these mappings helps you avoid overreacting to transient issues (like 552) while ensuring permanent rejections (like 550) are caught early. The RFC 5321 standard defines SMTP’s 5xx responses, and Mailgun’s implementation aligns with it. When used in a validation API, this mapping supports reliable, consistent filtering.

For teams using Mailgun and needing automated cleanup, a real-time verification API can preempt bounces by catching invalid addresses before delivery. Use the Email List Validation API to apply these standards across your list, reducing bounce rates and protecting sender reputation.

Integrate real-time email validation to pre-verify addresses before send

You can transform Mailgun hard bounces into standardized 5xx errors by validating emails in real time before sending. Use Email List Validation’s API to check every address against SMTP, MX records, and domain policies—returning clear verdicts like valid, invalid, catch-all, or risky—before it ever reaches Mailgun. This stops bad addresses at the gate, cuts hard bounces, and improves sender reputation from day one.

Pre-verify with real-time validation, not guesswork

Let’s say your list includes outdated or typo-ridden addresses. Sending to them doesn’t just hurt deliverability—it harms your sender score. With Email List Validation’s real-time API, you don’t need to wait for Mailgun to reject a message and return a 550 error. Instead, you verify each address in milliseconds. The API checks the underlying infrastructure: does the domain resolve? Is the email format structurally sound? Is the mailbox likely to accept messages? You get back a precise verdict with context, so you know not just *if* it’s invalid, but *why*.

For example, if an email returns “catch-all,” it means the domain accepts all incoming mail—usually a sign of a generic or disposable account. These are high-risk for deliverability and often end up in spam folders. You can filter them out before sending, instead of waiting for Mailgun to hard bounce them later. The same applies to invalid syntax or non-existent domains—these should never be sent at all.

Reduce bounce rates and protect your sender reputation

High bounce rates trigger automatic throttling from providers like Gmail and Outlook. Even a 0.5% bounce rate can flag your account as unreliable. By catching invalid or problematic addresses early, you keep your overall bounce rate below 0.1%—well within industry standards. This isn’t about avoiding one failed send. It’s about building a long-term reputation that keeps your messages in inboxes, not junk folders.

Think of it this way: hard bounces are a symptom, not the cause. The cause is sending to addresses that were never valid—or were never intended to receive your message. By integrating Email List Validation before your Mailgun sends, you shift from reactive to proactive deliverability. You’re not just fixing failures after they happen. You’re preventing them entirely.

Explore how this works at scale with real-time email verification. Or, if you’re working with large lists, bulk cleaning can help you audit and purge problem addresses across thousands of records. Either way, you’re not just reducing bounces—you’re building a resilient, high-performing email program.

How Email List Validation handles hard bounces differently

Unlike Mailgun, which treats any delivery failure as a hard bounce, Email List Validation checks SMTP, DNS, and domain rules in real time—identifying invalid domains, role accounts, and disposable emails before sending. This prevents failures at the source, reducing bounce rates and improving sender reputation. You’re not guessing why an email failed; you’re stopping it before it ever goes out.

SMTP and DNS checks before sending

Mailgun logs a hard bounce only after the SMTP transaction fails. That means you're reacting to a delivery issue after it’s already cost you in reputation and deliverability. Email List Validation goes further: it checks DNS records like MX and SPF, validates the mail server response, and confirms if the domain even exists—before sending a single message. This proactive filtering catches issues early.

For example, if an email has a non-existent domain or a server that doesn’t accept mail, it’s flagged instantly. You avoid the “hard bounce” label entirely, since the message never hits the SMTP server. According to RFC 5321, the SMTP protocol defines precise response codes—5xx means permanent failure. But only a real-time validation service can determine that failure *before* you trigger it.

Multi-signal accuracy: why 98.9% matters

Our 98.9% accuracy isn’t from waiting for server responses. It’s from cross-checking multiple signals: domain age, role account patterns, disposable email providers, and historical deliverability trends. Tools like Mailgun or ZeroBounce rely mostly on bounce data, which is reactive and often misleading—especially when systems like greylisting or temporary blocks trigger false hard bounces.

Let’s say you send to a user with a catch-all domain. Mailgun might mark it as a hard bounce if the specific address doesn’t exist, even though the domain accepts mail. Email List Validation detects catch-all setups and flags them as risky—giving you visibility into who might get a reply, even if their exact address is wrong. This is how you reduce false positives and improve list hygiene.

Real-time validation means you’re not waiting for bounces to learn what you should’ve known. With our real-time verification API, you can validate every email as it enters your system—keeping your lists clean and your deliverability strong.

Set up automated filtering based on standardized 5xx codes

You can transform Mailgun’s hard bounces into standardized 5xx codes by parsing your webhook data to isolate permanent failures (like 550, 551, 553) and tag those addresses as invalid. This lets you automate suppression without relying on Mailgun’s mixed error codes, reducing false positives and improving list hygiene. You’ll still need to manually handle temporary issues (4xx) or no responses.

Map Mailgun’s error codes to standardized 5xx indicators

Not all bounces are equal. Mailgun uses 5xx codes for permanent failures, but they vary in precision. Let’s align your logic with industry-standard practices by extracting only the most definitive indicators of invalidity.

1. Set up a webhook endpoint that receives Mailgun’s bounce events in real time. Use a lightweight service or function (like AWS Lambda, Vercel, or a custom script) to receive and log each payload.
2. Parse the delivery-status field in the webhook payload. Filter for messages with status: 5xx and check the description or code for specific error indicators like 550 (user unknown), 551 (user not local), or 553 (mailbox not allowed).
3. If the error code is 550, 551, or 553, tag that email address as permanently invalid. These are permanent rejection codes defined in RFC 5321 and are reliable indicators of non-existent or blocked addresses.
4. Exclude any address that returns 552 (mailbox full), 4xx (temporary failure), or no status code at all. These are not permanent and should not trigger suppression unless other factors (e.g., repeated failures) confirm long-term invalidity.
5. Integrate your filtered list into your email platform or suppression system. Use this list to block future sends and improve sender reputation by avoiding invalid addresses.

Why this works better than raw bounce data

Mailgun’s 5xx errors can include both temporary and permanent failures. Without filtering by specific codes, you risk suppressing valid accounts that are just temporarily unreachable. By focusing only on 550, 551, and 553, you align with Spamhaus and other deliverability standards that treat these as definitive invalidity signals.

For teams looking to scale validation beyond just webhooks, real-time API-based verification offers a faster, more precise alternative. You can validate entire datasets ahead of sending — no need to wait for bounces.

With real-time email verification, you validate at scale without waiting for delivery failures. It detects invalid, role-based, and disposable addresses using 98.9% accuracy — helping you avoid bounces before they happen.

Use Email List Validation to clean and maintain your list over time

You can transform Mailgun’s hard_bounce into standardized 5xx codes by integrating Email List Validation’s API or using its dashboard for scheduled bulk verification. This keeps your sender reputation strong, reduces bounce rates, and ensures emails land in inboxes—critical for sustained deliverability. Over time, you’ll catch outdated addresses, disposable domains, and risky catch-alls that slip through standard filters.

Schedule regular verification runs to stay ahead of decay

Let’s be honest: email lists degrade. Even the best ones lose validity. Schedule weekly or monthly bulk verification runs via Email List Validation’s API or dashboard to scan your entire list. This catches invalid, dormant, or misconfigured addresses before they trigger bounces. The process is fast—thousands of emails verified in minutes—and it’s built into your workflow, not a one-off chore.

Filter out non-human and unreliable addresses

Not all valid addresses are worth sending to. Catch-all domains (like [email protected]) may accept mail but don’t represent real users. Risky addresses—often disposable or temporary—can hurt your sender reputation. Email List Validation surfaces these with detailed verdicts, so you can filter them out before sending. This cuts down on low engagement and keeps your engagement metrics honest.

Some addresses that were once hard-bounced may now be active. A failed send today doesn’t mean the address is dead forever. Regular rechecks catch these resurrections and rebuild trust with your ESP. This is especially useful for re-engagement campaigns or warm-up sequences after a pause.

According to the Spamhaus Sender Reputation Report, maintainers of clean sender lists see a 30% higher inbox placement compared to those who don’t verify regularly. That’s not a vanity metric—it’s real engagement, real delivery.

You don’t need to overhaul your entire system to start. Begin with a small batch, verify, and see how your bounce rate drops. Use the bulk verification tool to scan large datasets. The service supports integration with Mailchimp, HubSpot, Klaviyo, and SendGrid—so cleaning your list fits into your current workflow, not against it.

The real impact on deliverability and sender reputation

You can’t afford to treat Mailgun’s hard_bounce as a simple flag—it’s a signal that your sender reputation is at risk. ISPs watch for consistent failures, and even transient issues like temporary server errors (5xx codes) can hurt your standing if they accumulate. Standardizing those 5xx responses through email validation reduces false positives, keeps your bounce rate low, and lowers the odds of being blacklisted. This is not about filtering a few bad emails—it’s about maintaining trust with inbox providers.

Bounce rates and ISP trust

Internet Service Providers like Gmail, Outlook, and Yahoo track bounce patterns closely. A high rate—even from expired or temporarily unavailable mailboxes—signals poor list hygiene. ISPs interpret this as a sign you might be sending to inactive, fake, or non-existent recipients, which lowers your deliverability score. Even a single 503 error from a server can trigger a red flag if it’s repeated across hundreds of emails.

That’s why standardizing invalid or transient responses (like Mailgun’s hard_bounce) into a unified 5xx validation code matters. Instead of treating every 5xx as a potential delivery failure, tools can detect and remove invalid addresses before you send. This keeps your actual bounce rate at a sustainable level—under 1% is common for well-maintained lists.

Warm-up velocity and inbox placement

When you’re warming up a new sending domain, even small fluctuations in bounce rate can disrupt the process. ISPs evaluate sending behavior over time. If your first emails start hitting 5xx errors due to unverified contacts, the system may throttle your volume or send your messages to spam folders.

By validating your list upfront and converting Mailgun hard_bounce signals into precise 5xx codes, you ensure only deliverable addresses are used. This consistency supports stable sending patterns, helps maintain a good IP reputation, and improves your chances of landing in the inbox. Tools like bulk email list cleaning or real-time validation do this reliably—without introducing noise into your sending pipeline.

Ultimately, it’s not just about removing bad addresses. It’s about creating a sending process that behaves predictably, matches ISP expectations, and avoids the kind of red flags that lead to reputation drops. For a detailed review of how this works in practice, you can explore how inbox placement testing helps validate deliverability outcomes across major providers.

Conclusion: Stop treating all hard bounces as invalid

Mailgun’s hard bounce is a signal, not a final verdict. Many hard bounces—especially those returning 4xx codes—are transient or policy-based, not permanent failures. Only definitive 5xx responses, like 550 (user unknown), 551 (user not local), or 553 (bad mailbox), should be treated as irreversible.

Standardizing your bounce processing around actual 5xx codes reduces false positives, preserves deliverability, and keeps your list hygiene intact. This precision prevents unnecessary suppression of valid addresses and maintains sender reputation.

Use Email List Validation to pre-verify and post-verify addresses, ensuring only real, actionable data reaches your senders. With 98.9% accuracy and no expired credits, it’s the trusted instrument for consistent, reliable validation across your entire workflow.

Keep reading

• Bounce management: hard bounces, soft bounces and bounce rate (complete guide)
• Using Email Verification APIs to Detect and Classify Vacation Response Bounces
• Detecting 503 5.5.1 Service Not Available Errors During ESP Maintenance
• Prevent 550 Error Mailbox Full After Storage Check with Real-Time Validation
• Fix 550 5.1.3 Mailbox Full Errors with Email List Cleanup Software

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

Frequently asked questions

What does a Mailgun hard bounce mean?

A hard bounce means the email could not be delivered due to a permanent issue—such as a non-existent address, blocked domain, or invalid syntax—but can include temporary failures like full inboxes.

Which Mailgun bounce codes indicate permanent failure?

Only codes like 550 (user unknown), 551 (not local), and 553 (invalid syntax) indicate a permanent delivery failure, not transient issues.

Why should I not treat all Mailgun hard bounces as invalid?

Many hard bounces stem from temporary issues like greylisting, full mailboxes, or throttling. Flagging all as invalid leads to false list suppression.

How do 5xx SMTP codes relate to email validation?

5xx codes signal permanent SMTP failures, such as nonexistent recipients. Only these are reliable indicators of invalid addresses during validation.

Can I use Email List Validation to reduce Mailgun bounces?

Yes. By verifying addresses before sending—using real-time API or bulk checks—you prevent sending to invalid or risky emails altogether.

What’s the difference between a catch-all and a valid email?

A catch-all accepts all messages sent to any address on the domain, even non-existent ones. Valid emails are targeted and specific; catch-alls are often automated or disposable.

How accurate is Email List Validation’s email verification?

It achieves 98.9% accuracy by combining SMTP checks, DNS validation, and domain reputation signals to distinguish valid and invalid addresses.

Do I need to store every bounce code from Mailgun?

No. Focus only on 5xx codes with permanent failure indicators. Use tools like Email List Validation to pre-filter and reduce reliance on post-send bounce data.

How often should I verify my email list?

Verify at least once per quarter. After significant campaigns or list growth, run a full validation to remove expired, role, or disposable addresses.

Can Email List Validation integrate with Mailgun?

Yes. It integrates with Mailgun via webhook-based bounce processing, bulk list upload, and real-time API validation to improve pre-send filtering.

What happens to addresses marked as 'risky' by Email List Validation?

Risky addresses are valid but may be disposable, role-based, or behind a catch-all. They should be treated with caution and not used for high-value outreach.

Are disposable email domains always invalid?

No—disposable domains are valid in a technical sense, but they are typically used for one-time signups. They should not be targeted in campaigns.