There is rarely a list to export at all. SendGrid's marketing contacts are a small slice next to the transactional volume, and the real inventory of addresses lives in your application's users table where nobody thinks of it as a mailing list.
Getting the addresses out of SendGrid
Marketing, Contacts, then Export, or the Contacts API for a programmatic pull. Transactional recipients live in your own database rather than in SendGrid.
At registration, in code. A nightly batch over your users table is a reasonable second pass, and neither replaces a check in the signup handler where the typo can still be corrected by the person who made it.
What SendGrid 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
- The Marketing Contacts API upserts on email address.
- Suppressed addresses stay suppressed regardless of what you import, and the suppression is per subuser rather than global.
- Custom fields are supported, so a verification verdict can be stored alongside the contact.
- For transactional mail the import model does not apply at all: verify at signup in your application instead.
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.
6,200 bounced contacts still taking up storage
Suppose your SendGrid Marketing Campaigns account stores 75,000 contacts and your bounce suppression list has grown to 6,200 addresses. You might assume a suppressed contact stops counting. SendGrid's support pages say the two things aren't linked: suppression lists don't count toward contact storage, and they aren't the same records as your marketing contacts. A bounced address sits on the suppression list and in your contacts, and the contacts copy still uses storage.
Storage is also counted cumulatively. Their contact storage article says a contact held at any point in the calendar month counts as one unit of usage for that month, so deleting on the 28th doesn't help until the month turns over.
SendGrid publishes a guide for removing suppressed addresses from contacts, and that's the first pass. A verification check on the remaining 68,800 finds what hasn't bounced yet. Our 100,000 tier is $139, and what comes back unknown isn't charged.
Look for a setting called bounce purge
Under Settings, then Mail Settings, there's an option named Bounce Purge. When enabled, it deletes addresses from your bounces and blocks suppression lists on a schedule you set. A past developer may have switched it on to stop the lists growing. Once an address is purged, SendGrid will try delivering to it again, and you take the bounce again.
SendGrid's own guidance is that the setting shouldn't be used unless you have a business reason to retry previously bounced addresses. Check whether it's on, and check each subuser, since suppressions are separate for each one.
Purging doesn't touch marketing contacts, so it won't free any storage. If it has been running for a year, your suppression list is much shorter than your real bounce history. In that situation the list can't serve as a record of known-bad addresses, and a fresh check of the users table is the only way to rebuild one.
Questions people ask
Where should verification sit in a SendGrid setup?
At signup in your application, before the address is written to your database. Cleaning a list afterwards does nothing about the transactional mail your code is already sending.
Should I verify at every signup?
For a real-time check, yes, and set a timeout so a slow response never blocks a registration. An address you cannot resolve should still be accepted and flagged rather than rejected.
What about catch-all addresses at signup?
Accept them. A catch-all result means nobody can confirm the mailbox, and rejecting a signup on that basis turns away real customers at business domains.