Nothing resembling a list exists. Mandrill sends what your application hands it, and the nearest thing to an audience is the rejection blacklist telling you which addresses it refuses.
Getting the addresses out of Mandrill
The API exports activity and the rejection blacklist. There is no contact list, because the addresses live in your application.
At registration in your product, and with an eye on the Mailchimp account above it. The transactional stream inherits compliance exposure from a marketing list you may not control.
What Mandrill 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
- There is no contact import for transactional sending.
- The rejection blacklist can be queried and managed through the API.
- Sending domains need SPF and DKIM configured in Mandrill before delivery is reliable.
- Subaccounts separate reputation and reporting between applications.
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.
The weekly digest that bounces again on day eight
Suppose your app sends a Monday digest to 50,000 users through Mandrill, and 1,200 of those addresses are dead. The first Monday, all 1,200 hard bounce and land on the rejection denylist. You'd expect that to be the end of them.
It isn't, because denylist entries expire. Mailchimp's developer documentation gives the durations: soft bounces expire after 24 hours, hard bounces after seven days, and unsubscribes and spam complaints after a year. An expired address stays on the list for reference, but the next message to it is attempted again. With a weekly digest, an entry created on Monday morning can lapse just before the following Monday's send. The same 1,200 bounce a second time, then a third.
Mandrill won't remember for you, so the permanent record has to live in your own database. Check the 50,000 once, which is $89 with us, and set a do-not-mail flag your digest job respects.
Why the first bounce is the expensive one
The same documentation explains how reputation is scored. Rejected emails aren't charged and don't affect reputation, and only the first bounce, complaint or unsubscribe for an address is used in the calculation. That sounds forgiving until you remember the expiry. After it lapses, the next attempt is a fresh delivery and can bounce for real again.
Reputation matters here because it sets your hourly quota. Accounts with a poor reputation see the quota grow slowly, and anything over it waits in a backlog. For a password reset, waiting is the failure.
There's a cleaner tool than waiting for bounces. Addresses you add to the denylist by hand never expire, and the rejects API accepts them in bulk, so you can load verified-invalid addresses straight in. Going the other way has a cost: removing an address from the denylist takes what their docs call a small reputation hit. Save that for the customer who fixed a full mailbox and wrote in to say so.
Questions people ask
Where does verification belong with Mandrill?
In your signup flow, before the address reaches your database. There is no list to clean, only application data that was wrong when it was stored.
Should transactional mail share an account with marketing?
It is a risk decision. Shared compliance means one team's list problem can stop the other team's password resets, and a separate provider removes that entirely.
What should happen to unresolvable addresses at signup?
Accept the registration and flag the address. Blocking a signup because a server would not answer a probe loses a customer over someone else's policy.