Integrating Mailgun & SendGrid | Email List Validation

Why mailbox full errors are a silent email deliverability killer

You send a campaign. The open rate is solid. The bounce rate looks fine. But your inbox placement starts dropping—without a single hard bounce in the logs. Sound familiar? The culprit might be something invisible: mailbox full errors.

These aren’t the kind of bounces you catch in real time. A 550 5.2.2 error means the recipient’s mailbox has hit capacity. It’s a permanent rejection, but it often only shows up after multiple delivery attempts—and only after the server has already accepted the message and queued it.

That delay is where the damage happens. Most standard bounce processing misses these signals because they don’t trigger early SMTP rejections. Unless you’re actively monitoring for them via Mailgun and SendGrid bounce webhooks, they go unnoticed for days. And that’s how sender reputation quietly erodes.

Key takeaways

Mailbox full errors (550 5.2.2) appear after delivery acceptance, making them invisible to basic bounce handling.
Without real-time webhook monitoring, these permanent errors accumulate silently, damaging sender reputation over time.
Integrating Mailgun and SendGrid bounce webhooks enables immediate detection of mailbox full errors, preventing wasted sends and inbox placement issues.

How Mailgun and SendGrid Bounce Webhooks can catch mailbox full errors

When a recipient’s mailbox is full, both Mailgun and SendGrid return a 550 5.2.2 permanent failure and instantly notify your system via HTTP POST webhooks. These real-time alerts let you stop sending to affected addresses before your sender reputation suffers from repeated delivery attempts. No polling, no log parsing — just reliable, automated detection.

Instant detection of permanent delivery failures

Mailgun and SendGrid both deliver bounce webhooks within seconds of a failed delivery. If a message hits a 550 5.2.2 error — a clear signal that the mailbox is full — the webhook fires immediately. This speed means you can act before systems start retrying, which can harm your sender reputation.

The 550 5.2.2 code is a standard SMTP response for “mailbox full” errors, defined in RFC 5321. It's a permanent failure, so any retry is wasted. By catching it early via webhooks, you avoid unnecessary retries and protect your domain’s deliverability. This is not a guess — it’s a confirmed rejection from the destination server.

Reliable, automated monitoring without manual work

Unlike scheduled bounce processing or raw log analysis, webhooks give you a consistent, programmatic way to track delivery errors. You don’t need to parse log files every hour or rely on delayed batch reports. Instead, your system receives the event as it happens — with full metadata including email, error code, and timestamp.

This reliability means you can build an automated cleanup process: when a mailbox full error arrives, flag the address and exclude it from future sends. This reduces list decay and improves long-term inbox placement. Tools like Email List Validation help you identify these issues at scale through bulk verification, ensuring your list stays clean before you even send.

For teams using Mailgun or SendGrid, enabling bounce webhooks isn’t optional — it’s foundational. You’re not just monitoring bounces; you’re preventing harm before it starts. And when you pair this with accurate list hygiene, you create a delivery system that’s both responsive and sustainable.

Clean your list before sending with real-time validation to catch invalid, risky, or full mailboxes early — so webhooks don’t have to catch what you could have prevented.

Integrating Mailgun and SendGrid bounce webhooks: a step-by-step process

Set up bounce webhooks in Mailgun and SendGrid by enabling the Bounce event in each service’s webhook settings and pointing both to the same HTTPS endpoint. This allows you to catch mailbox full errors and other delivery failures in real time, so you can remove invalid addresses before they hurt your sender reputation. Use a tool like Email List Validation to clean your list afterward and reduce future bounces.

Step-by-step integration

Log in to your Mailgun account and go to the Domains section. Select the domain you use for sending emails. This ensures the webhook applies only to messages sent from your verified domain, not others.
Navigate to the Webhooks tab under your domain. This is where you define which events trigger HTTP POST requests to your server, including bounces, delivery failures, and spam complaints.
Enable the 'Bounce' webhook and enter your HTTPS endpoint. For example, https://yourapp.com/webhooks/mailgun-bounce. This endpoint must be publicly accessible, respond within 30 seconds, and handle POST payloads. Use tools like MxToolbox to verify your host is reachable.
Repeat in SendGrid by going to Settings > Mail Settings > Bounce Handling. Copy the same HTTPS endpoint and save it. SendGrid does not support domain-specific webhooks like Mailgun, so the endpoint applies globally unless you filter by domain later in code.
Ensure your endpoint uses HTTPS with a valid certificate. Services reject webhooks over HTTP or with self-signed certificates. Use Let’s Encrypt for free, trusted SSL/TLS certificates — a standard practice for secure web services.
Test both integrations using the built-in test buttons in Mailgun and SendGrid’s webhook settings. You’ll receive a sample payload that simulates a mailbox full error or other delivery failure. Validate that your system parses the event correctly and logs or processes it.

Common Gotchas and Real-World Checks

Even after setup, webhooks may fail silently. Check logs in both Mailgun and SendGrid dashboards for delivery status or webhook errors. You’ll see 5xx errors if your server drops requests, or 4xx if the endpoint is unreachable.

Mailbox full errors (SMTP 552) are a common bounce type that signals a hard failure. They typically require immediate removal of the address. Use real-time email verification to flag such addresses before sending — reducing the chance they’re even sent in the first place.

Always validate responses with the SMTP RFC 5321. It specifies how servers should handle overflow conditions, including full mailboxes. Understanding the underlying protocol helps you interpret bounce codes correctly in your application logic.

What to do when a mailbox full error is detected via webhook

When a mailbox full error (SMTP 550 5.2.2) is flagged via your Mailgun or SendGrid webhook, immediately mark the email as invalid in your database and cease all future sends. This prevents reputation damage from repeated delivery attempts and maintains sender health. Use the error code, timestamp, and sender IP for audit trails and troubleshooting.

Act quickly to preserve sender reputation

Mailbox full errors are hard bounces — they signal a permanent delivery failure. Each attempt to resend to a full inbox increases your sender score penalty. ISPs like Gmail and Outlook use retry patterns to assess sender behavior; repeated retries on blocked addresses can trigger throttling or blocklisting. Let’s be clear: no retry is ever justified here.

Once the webhook triggers, update your systems in real time. Flag the address as "invalid" or "risky" in your email database. If you’re using automation platforms like Mailchimp, HubSpot, or Klaviyo, ensure your integration pushes this status update to your CRM or marketing system. This keeps user records aligned and prevents re-engagement campaigns from targeting unreachable inboxes.

Log everything for transparency and compliance

Don’t rely on memory. Store the full context: the exact timestamp of the error, the error code (550 5.2.2), the originating sender IP, and the domain and email address. This data is critical for diagnostics, compliance, and building internal knowledge — especially when auditing deliverability issues or responding to carrier reports.

The SMTP 550 5.2.2 code is defined in RFC 5321, which states it means "mailbox full" and must be treated as a permanent failure. You can verify this in the official specification via IETF RFC 5321. Treat this signal with the same gravity as a syntax error or a blocked domain.

For deeper inbox health checks, consider testing with real user inboxes using inbox placement services. Email List Validation’s inbox placement solution can help identify which messages land in spam folders or fail at delivery — before they reach your audience.

Using Email List Validation to improve list hygiene with webhooks

You can reduce mailbox full errors by combining Mailgun and SendGrid bounce webhooks with proactive list cleaning. Use Email List Validation’s real-time API to verify new addresses before sending, and run regular bulk checks to remove invalid or risky emails. When multiple bounces occur from the same domain, use the in-app AI assistant to spot root causes like shared mailboxes or high usage. This layered approach stops issues before they hurt deliverability.

Prevent mailbox full errors with proactive verification

Integrate Email List Validation’s real-time verification API into your signup or onboarding flow to check every new address before sending.
Filter out high-risk domains or known disposable addresses before they trigger delivery failures, reducing the chance of hitting mailbox limits.
Combine API results with webhook data from Mailgun and SendGrid—valid addresses flagged by API but still bouncing? That’s a red flag for high usage or full inboxes.

Diagnose domain-wide issues with historical data

Run monthly bulk cleanups using Email List Validation’s bulk list verification tool to remove invalid, catch-all, or role-based addresses that may be causing delivery blocks.
When the same domain repeatedly fails, use the in-app AI assistant to analyze patterns—common signs include too many role-based accounts (e.g. sales@, info@) or shared team mailboxes near capacity.
Correlate these results with bounce webhooks: recurring 5xx errors from one domain suggest system-level limits, not individual account issues.
For context, RFC 5321 outlines SMTP error codes—552 (exceeded storage limit) is a standard signal of a full mailbox. Monitoring this helps distinguish temporary limits from permanent failures.
Use your findings to segment or pause sends to domains with known constraints, improving sender reputation and inbox placement over time.

Proactive list hygiene doesn’t just reduce bounces—it prevents your IP from being tagged as spam due to high failure rates. Consistent verification is a cornerstone of sustainable email deliverability.

How to avoid false positives and over-reacting to bounce events

You don’t need to purge an email address just because it returned a 550 5.2.2 error once. Many such bounces are transient—especially from large providers like Gmail or Outlook—and resolving them correctly requires context. Correlate webhook data with historical delivery patterns, retry logic, and domain-level signals before taking action. Let’s break down how to do that.

Not all 550 5.2.2 errors are permanent

That 550 5.2.2 error—“mailbox full”—is often temporary, especially at providers with aggressive throttling or auto-cleanup policies. A single failure doesn't mean the address is dead. According to RFC 5321 (the SMTP standard), error codes like 550 5.2.2 are categorized as “permanent” at the protocol level, but real-world delivery systems often treat them differently based on volume and frequency. Some providers automatically retry or adjust queue behavior, making a single failure misleading.

For example, Gmail may reject a message with a 550 5.2.2 response if the recipient’s inbox hits quota, but that condition can resolve within hours. If you act on that single signal, you risk removing a valid address from your list based on a short-term constraint. Instead, treat it as a warning—not a death notice.

Use thresholds and cross-check signals

Let’s say a single address fails via SendGrid’s bounce webhook with a 550 5.2.2 error. If it’s the first time and no other addresses from that domain are failing, it’s likely a transient issue. But if three addresses from the same domain fail over a 24-hour span, that’s a red flag.

Set a threshold: only flag or remove addresses after a second or third failure within a short window—say, 48 hours. Use domain-level bounce rates as a secondary trigger. If the domain’s overall fail rate is low, a single failure is probably harmless. But if multiple addresses from that domain report the same error type, act with caution.

Also, consider sender reputation. If your IP or domain has a solid track record, temporary bounces are less likely to cause long-term harm. Tools that analyze historical performance—like our real-time email verification API—can help distinguish truly invalid addresses from those that just had a bad day.

Finally, avoid automatic removals based on one event. Instead, log and monitor. If you see repeated failures from the same address or domain, that’s when you adjust your suppression list. Over-reacting wastes capacity. Under-reacting risks deliverability. The sweet spot is data-driven, not event-driven.

What Email List Validation offers beyond webhook integration

While webhook integration with Mailgun and SendGrid helps you catch mailbox full errors in real time, Email List Validation goes further by verifying email addresses at the SMTP level—checking if the inbox actually exists, catching all catch-all addresses that falsely appear deliverable, and reducing false positives. You’re not just reacting to bounces; you’re preventing them before they happen.

Real-time SMTP checks catch what webhooks miss

Webhooks tell you when a message fails, but they don’t confirm whether an address was ever valid. Email List Validation runs full SMTP probes to verify inbox presence before you send. This means it detects catch-all domains—common in large domains like gmail.com, where any address appears deliverable but rarely receives mail. These addresses may pass SMTP checks, but they’re effectively unusable for outreach.

According to RFC 5321, the SMTP protocol itself doesn’t distinguish between a genuine inbox and a catch-all, which is why a deeper check is needed. That’s where our service steps in—by simulating a real email delivery process, we can flag addresses that look fine on paper but aren’t actually usable.

Inbox placement and address recovery

Beyond detecting inactive addresses, you can use our inbox-placement testing service to simulate delivery from your domain. It checks whether messages end up in the inbox or get filtered into spam, giving you actionable insight into your sender reputation and message content.

Many bounces from mailbox full errors aren’t immediate. Some addresses remain valid but temporarily over capacity. Our 98.9% accuracy rate helps you distinguish between these temporary issues and truly dead addresses. You’re not losing valid contacts due to outdated data.

For outreach campaigns, our email finder helps replace unverified or old addresses with validated ones—perfect for re-engagement or cold outreach. It’s not just about avoiding bounces; it’s about improving deliverability at scale.

“You don’t need to know every error—just the ones that matter. Validity isn’t binary. It’s a spectrum of likelihood.”

Best practices for monitoring bounce webhooks at scale

You need a dedicated, scalable backend to process incoming bounce webhooks from Mailgun and SendGrid without overloading your app server. Always log raw payloads, headers, and source IPs for debugging. Set up threshold-based alerts—like 5 mailbox full errors in an hour—to catch domain-wide issues early. Preserve all verified events indefinitely; historical data shapes better list hygiene and sender reputation decisions.

Handle webhooks with dedicated, ephemeral infrastructure

Route all bounce webhooks to a purpose-built service like AWS Lambda or a Vercel Function—never rely on your application server directly.
These services scale automatically and handle bursts without downtime, which is common during large email sends or mail server issues.
Each function should validate the webhook signature (using HMAC or similar) before processing—this prevents spoofing and ensures data integrity.

Log, alert, and archive with purpose

Store every inbound event in a searchable log with full context: raw JSON, HTTP headers, and the sender’s IP address. This aids in diagnosing false positives or malicious actors.
Use a time-series database or indexed storage to track patterns—e.g., repeated mailbox full errors from a specific domain often indicate a server misconfiguration.
Set up alerts when mailbox full errors exceed a threshold (e.g., 5 within 60 minutes) to detect potential issues before they impact deliverability.
Never delete historical event data. Over time, this archive helps you identify trends—like declining domain health or increasing role account use—enabling proactive list cleaning.
For validation before sending, use tools that verify email syntax, syntax, and delivery risk: clean your lists with real-time scanning.

Mailbox full errors are rare but signal a deeper delivery issue when they appear in clusters. According to the IETF’s RFC 5321, SMTP servers will reject new emails when the recipient’s inbox reaches capacity, which can harm sender reputation if ignored. Monitoring these signals at scale is not optional—it’s how you sustain long-term deliverability. This standard underpins the actual behavior of bounce handling in production email systems. Stay informed, stay logged, and stay ahead.

Common pitfalls in webhook-based bounce monitoring

You’re sending emails through Mailgun and SendGrid, and you've set up bounces via webhooks—great. But if your endpoint isn’t secured, your system may silently drop events, or worse, become a target for abuse. Ignoring the distinction between soft and hard bounces can purge valid addresses prematurely. Missing signature validation leaves you open to spoofed events. And skipping endpoint testing? You’ll have no idea if messages are being lost. These are real, avoidable risks that undermine deliverability.

Security and trust: don’t assume your endpoint is safe

Running an open webhook endpoint without authentication invites abuse. Anyone can flood your system with fake bounce data, leading to resource exhaustion or DDoS-style behavior.
Mailgun uses HMAC signatures; SendGrid uses JWT. Never skip signature verification—this is how you ensure the event originated from the provider, not a malicious actor.
Even if your endpoint is private, use the provider’s signature verification. Per RFC 2104 (HMAC) and RFC 7519 (JWT), signature validation is a standard defense against spoofing and replay attacks.

Hard and soft bounces serve different purposes. Ignoring soft bounces (like "mailbox full") can cause you to drop addresses that might still be recoverable—especially after a temporary issue subsides.
Don’t assume your endpoint is reachable. A misconfigured firewall, misnamed route, or untested routing can silently drop all events. Test with real test payloads before going live.
Use tools like Mail-Tester or MXToolbox to send controlled bounce events and confirm your endpoint receives them correctly.
Store logs of each received event and flag any unverified or malformed data. This helps track failures and build a reliable audit trail.

Don’t wait for an inbox placement drop to realize you’ve been ignoring bounces. A real-time email verification API lets you catch many of these issues before they even hit your sender platform. Verify addresses on the fly to ensure your list stays healthy and your webhook data remains meaningful.

How to test and verify your integration is working correctly

Simulate mailbox full errors using Mailgun and SendGrid’s built-in test features to confirm your bounce webhook receives and processes payloads correctly. Check your endpoint logs for 200 responses, validate bounce type and error codes, and test with manual payloads to ensure reliable detection before real failures occur.

Test the webhook endpoint with built-in simulator tools

Use Mailgun’s webhook tester to send a simulated bounce event that includes a "mailbox full" error code. This mimics real-world delivery failures without sending actual emails.
Similarly, trigger a test bounce from SendGrid’s event webhooks testing tool with a bounce type that includes a 552 status code, indicating mailbox full.
Inspect your server logs or endpoint monitoring tool to confirm the HTTP request was received and responded with a 200 status. A non-2xx code will cause the provider to retry or drop the event entirely.

Validate event data and handle edge cases

Confirm your system logs the event with the correct bounce type (e.g., "blocked", "exceeded_quota", or "mailbox_full") and the exact SMTP error code (commonly 552 in mailbox full cases).
Use Postman or curl to manually send payloads that emulate both successful deliveries (200 status) and failures (5xx codes), ensuring your system parses and reacts to each correctly.
Test with different email domains known to enforce strict mailbox quotas. Real-world variations in bounce handling are common—some servers return 552, others 550 or 554. You’ll need to handle these reliably.
Verify that your integration logs the timestamp, sender, recipient, and full event payload. This helps diagnose configuration drift or missed events later.

For broader email health, use a tool like bulk email verification to pre-screen lists and reduce the chance of mailbox full errors caused by invalid or high-volume lists. Catching issues before sending improves deliverability and reduces strain on your infrastructure.

Conclusion: proactive monitoring protects sender reputation

Mailbox full errors are among the most damaging delivery failures — they signal permanent rejection and harm sender reputation fast. Ignoring them means sending to accounts that can’t receive messages, leading to wasted sends and higher bounce rates.

The 3 steps described in “Test the webhook endpoint with built-in simulator tools”, in order.

By integrating Mailgun and SendGrid bounce webhooks, you gain real-time visibility into permanent delivery failures. This allows immediate action, such as removing invalid addresses before they impact deliverability.

When combined with Email List Validation’s bulk verification and real-time API, you ensure your list remains clean and compliant. The result is fewer bounces, improved inbox placement, and a sender reputation that stays strong over time.

Keep reading

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 mailbox full error 550 5.2.2 mean?

It means the recipient’s mailbox has reached its storage limit and cannot accept new messages. It’s a permanent error requiring you to stop sending to that address.

How soon do SendGrid and Mailgun send bounce webhooks?

Both services deliver webhooks within seconds of the SMTP rejection, typically under 30 seconds for standard failures.

Can I use Email List Validation with Mailgun and SendGrid webhooks?

Yes — the service integrates with both platforms through its API and can enhance your webhook data by verifying addresses in real time.

Do all bounce webhooks include the error code?

Yes — both Mailgun and SendGrid include the SMTP error code (e.g. 550 5.2.2) in the JSON payload for each failure event.

How often should I clean my email list using Email List Validation?

Clean lists monthly or after any major campaign to maintain deliverability and reduce bounce rates.

What’s the difference between a hard bounce and a mailbox full error?

A mailbox full error is a type of hard bounce — it’s permanent. But not all hard bounces are mailbox full; some are invalid addresses, blocked domains, or rejected by policy.

Do I need to pay to use Email List Validation’s API?

You get 100 free verifications to start. Purchased credits never expire, so you only pay for what you use, with no time pressure.

Can Email List Validation detect disposable email addresses?

Yes — the service identifies known disposable domains during bulk and real-time validation.

What happens if I ignore mailbox full errors in my webhook logs?

Continued sends to full mailboxes count as delivery failures, harming sender reputation and increasing the risk of being blocked.

Is a 98.9% accuracy rate accurate for Email List Validation?

Yes — the service achieves 98.9% accuracy in detecting valid, invalid, catch-all, and risky email addresses through multiple verification layers.

How do I secure my webhook endpoint?

Use HTTPS, validate the incoming signature (HMAC for Mailgun, JWT for SendGrid), limit access via IP whitelist, and log all traffic.

Can I use the Email List Validation AI assistant with bounce data?

Yes — the in-app AI assistant can help interpret patterns in failure data and recommend cleansing actions based on real-time results.