Reducing your bounce rate in Mailgun

Written for developers who want SMTP and API sending with deep logs.

Mailgun
Their stated thresholdMailgun's guidance points at keeping bounce rates under 5%, and their compliance team reviews accounts that sit above it.
What happens if you cross itMailgun can suspend sending on an account with sustained high bounce or complaint rates, and their review is stricter for accounts on shared IP pools.
Where the bounce data livesSending, then Suppressions, with separate Bounces, Unsubscribes and Complaints tabs. Logs holds the full SMTP exchange per message, with retention depending on your plan.
How bounces are classifiedMailgun records the receiving server's actual response code and text against each bounce, so you can distinguish a 550 no such user from a 550 policy rejection rather than seeing both as a hard bounce.

Bringing the rate down

Each step is an action inside Mailgun, in the order worth taking them.

  1. Read the SMTP response text in the logs

    Mailgun keeps the whole exchange. A 550 naming a nonexistent mailbox and a 550 naming a blocklist are completely different problems, and only the logs distinguish them.

  2. Group bounces by receiving domain

    Concentrated on one domain means a reputation problem with that receiver. Spread evenly means a list quality problem. This single split decides the rest of your work.

  3. Set up webhooks for bounce events

    Mailgun posts events to your endpoint. Without that, your application keeps sending to an address Mailgun has already suppressed, and the send is counted as a failure each time.

  4. Check the suppression list before sending

    The suppression API tells you whether an address is already suppressed. Querying it before a campaign avoids attempting sends Mailgun will drop anyway.

  5. Verify at the point the address enters your system

    For API-driven sending, the list is your database. Checking at signup moves the failure from your reputation to a validation result.

The mistake people make here

A bounce report mixes two causes that need opposite responses: addresses that do not exist, and receivers refusing mail they could have delivered. The first is fixed by checking the list. The second is a sending problem and no amount of cleaning will move it.

Questions people ask

Why are Mailgun's bounce logs more useful than a bounce report?

Because they include the receiving server's exact response. A hard bounce label collapses a nonexistent mailbox and a policy rejection into one category, and those need opposite responses.

Does Mailgun stop sending to a bounced address automatically?

Yes, it adds the address to your suppression list and drops later attempts. The first send already happened and already counted.

How long are logs kept?

It depends on your plan. Pull the detail you need for analysis before the retention window closes, because the summary that survives is much less useful.

Check the list before the next send

100 free checks a month, no card, and the addresses nobody can resolve come back labeled rather than guessed at.