Verify a Datagma Export Before You Send

What Datagma says

From Datagma's pricing page, read 9 November 2026:

• "1 credit = 1 verified email. 30 credits = 1 mobile phone."
• "You only pay when we find a verified email or phone. No match = no credit used."
• Credits are one shared pool for emails and phones, per account rather than per seat.
• "Unused credits roll over for up to 12 months on paid plans."
• The Free plan includes 100 credits a month. Regular, Popular and Expert list "CatchALL emails FREE," and the page says catch-all emails don't count.

The page doesn't explain how verification is done or define a catch-all email. We're not drawing conclusions about method. We're pointing out what any export from any finder has in common: some rows can't be confirmed by an outside check.

Why catch-all rows need their own handling

A catch-all domain's mail server accepts mail for any address at that domain, real or not, at the moment of the check. Some of the mail is delivered to a person and some is bounced or dropped later. A finder can tell you the address fits the company's pattern, and a verifier can tell you the domain is catch-all, but neither can see inside the mailbox.

That has a billing consequence: it is reasonable for a vendor not to charge for something it can't confirm. It also has a sending consequence: if you load every catch-all row into one big wave, the bounces arrive together. Read more at catch-all emails: what to do, and see how we score them at catch-all scoring.

Why other rows can still bounce

• Age. A reveal done last month and exported today.
• Job changes. The mailbox existed, the person left (email valid but person left the company).
• Mixed files. A Datagma export merged with another tool's file.
• Phones versus emails. The shared credit pool covers phones too. A file that mixes both needs the phone columns handled separately from the email check.

The send-day routine

1. Export and mark the source

Keep email, name, company, domain and a source column. Add the export date.

2. Clean

• Remove duplicate emails across your files.
• Limit contacts per company.
• Tag catch-all domains with the bulk catch-all checker.

3. Verify

Upload at /verify for a live SMTP check on each row.

Result	Action
Valid	Main sequence
Risky (catch-all)	Second wave, best grades first
Risky (role, disposable, full)	Drop for outreach
Invalid	Suppress
Unknown	Re-check tomorrow

4. Send in waves

Valid first. Catch-alls the next day, a small batch. Pause when hard bounces pass your platform's line; bounce rate thresholds by platform lists them.

5. Track by source

Record bounce rate per source in a sheet. After a few campaigns you will know how much weight to give each tool, from your own data. Bounce rate by source can help.

What to do with each group after the check

Valid rows go to the main sequence with the verification date kept in a column.

Catch-all rows get the smaller wave. Send the best-graded first, stop if bounces rise, and keep the weakest for another campaign.

Role, disposable and full-mailbox rows are poor outreach targets: role addresses rarely reach a decision maker, disposable ones vanish and full mailboxes defer or bounce.

Invalid rows belong in a permanent suppression file merged into every future import (cold email suppression lists).

Unknown rows mean the server was slow to answer. Retry them tomorrow.

Free reveals are not free sends

Because catch-all emails don't cost credits, it is tempting to export them all. The cost shows up later, in a sender reputation hit if they bounce together. Take the free reveal, then decide row by row what is worth risking on a domain you rely on. A flat-rate check makes that decision cheaper; see the bulk email verifier page and unlimited email verification.

Mistakes that turn a good Datagma export into a bounce problem

1. Verifying once and sending for weeks. A check is a snapshot. If the campaign runs over several weeks, re-check the rows you haven't mailed yet before each batch.
2. Loading everything into one step. Even a clean list should go out in waves. If something is wrong with a domain or a segment, a wave catches it before the whole file is gone.
3. Merging suppression files too late. Add your suppression list before you verify, not after, so you never spend a check on someone you can't mail.
4. Treating risky as valid. Risky means the server wouldn't confirm the mailbox. It is a decision to make with a smaller batch, not a pass.
5. Ignoring the first bounce messages. The first few bounces tell you whether the problem is the list, the domain or the content. Paste them into the bounce message analyzer before you send more.
6. Skipping authentication. A clean list on a domain with failing SPF, DKIM or DMARC still lands in spam. Run the email domain health checker once a month.

A weekly rhythm for ongoing prospecting

• Monday: reveal and export. Note the date.
• Tuesday: clean, tag catch-alls, run the live check.
• Wednesday: send valid rows.
• Thursday: send the catch-all wave if the valid wave stayed under your bounce line.
• Friday: update the suppression file and your bounce-by-source sheet.

Shared credit pools reward steady use: rollover helps you carry credits forward, and a regular rhythm keeps exports fresh enough that the check has little to catch.

Quick answers

• Is a catch-all email from Datagma verified? The page lists them as free and not counted. It doesn't say they are confirmed mailboxes.
• Do I need to re-verify paid-plan exports? If you're sending within a day or two on a warmed domain, the vendor check may be enough for a small list. Otherwise run a live check.
• How often should I re-check? Before each send of an older file (how often to verify an email list).

Try it on your own export

Upload a slice at /verify. The first 100 checks are free with a Google sign-in, no card.

Pro, $39 a month: Unlimited email verification.* Never metered, never cut off. See pricing.

*Fair use: the first 100,000 checks a month at full speed, then slower, never cut off.