Mailgun's mailing lists are a convenience feature and most accounts barely use them. What you actually hold is a database table and a suppression list, and reconciling those two is the job that resembles list cleaning here.
Getting the addresses out of Mailgun
Mailing lists have an export option, and the API returns members programmatically. For application-driven sending, the source of truth is your own database.
At the point of capture in your application. Mailgun's logs will tell you what happened afterwards in unusual detail, and detail after the fact is diagnosis rather than prevention.
What Mailgun does with the file you bring back
The import rules decide what a re-import actually changes, which is worth knowing before you upload.
The short version
- Mailing list members upsert on address through the API.
- Suppressed addresses stay suppressed independently of list membership.
- Log retention varies by plan, so pull bounce detail before it ages out if you need it for analysis.
- Mailgun sells its own validation service, which is worth knowing when comparing what a verification step costs you.
The mistake to avoid
Some addresses come back unresolved, and that is a fact about the receiving server rather than a gap in the check. We label those and never bill for them. What that means, and why roughly 28% of business addresses land there, is set out on our page about catch-all domains.
Three sending domains and three bounce lists
Say your application sends receipts from mg.yourapp.com, product news from news.yourapp.com and invoices from a third domain set up by the finance team. Mailgun organizes suppressions per domain, and its help center explains the reasoning: a suppression reflects a proven interaction with a specific send.
What follows from that is easy to miss. An address that hard bounced on the news domain is still open for delivery on the other two, and the first receipt sent there bounces again. Suppose your users table holds 85,000 addresses, the news domain's bounce list holds 2,900 and the receipts domain holds 640. Pull both through the API, take the union, and you might find 3,200 distinct dead addresses, most of which only one domain knows about.
Flag all 3,200 in your own database so every sender skips them. After that, check the remaining 81,800, which fits our 100,000 tier at $139 with spare credits that don't expire.
Deleting a suppression is an instruction to try again
In the control panel each bounce entry shows the address, the date and the error the receiving server returned, with a delete button beside it. Mailgun's documentation is direct about what deleting does: new messages to that recipient will attempt delivery instead of being suppressed. Clearing the list to start fresh re-tests every dead address against your reputation.
When a suppressed address is mailed, the log shows a failure reading Not delivering to previously bounced address. Search your logs for that phrase. A high count means your application keeps trying people Mailgun already gave up on, which tells you the bounce webhook isn't writing back to your users table.
Whether those dropped messages count toward your monthly volume is worth confirming on your own invoice. We couldn't find a statement from Mailgun that settles it.
Questions people ask
Should I verify addresses before sending through Mailgun?
For any list you did not collect yourself, yes. For application-driven sending, verify at signup instead, because there is no list to clean.
How does verification differ from Mailgun's own validation?
Both check the address before you send. What matters is what each does with the addresses nobody can resolve. We report coverage alongside accuracy and do not bill unknowns, and any vendor's single accuracy figure is calculated after the unknowns leave the denominator.
What should happen to an unknown result at signup?
Accept the registration and flag the address. Turning away a real customer because a server would not answer a probe is the wrong trade.