Storing Email Verification Results in Your Database: A Practical Schema
Do not throw the result away after the check. The few columns that make verification results useful later, how to use them in sending rules and when to re-check.
Many teams verify an address at sign-up, act on the answer and forget it. A few extra columns turn that one check into a record you can use for months: to decide who gets which email, to find stale data and to prove what you did.
The columns worth keeping
- email_status: a short value such as valid, invalid, risky or unknown. Keep it as a small fixed list, not free text.
- verified_at: when the check ran. This is the column that makes the rest useful.
- status_reason: the reason the service gave, if it gives one. It saves you from guessing later.
- source: where the address came from, such as sign-up form, import or purchase. Sources differ in quality.
- last_bounced_at: the date of the most recent hard bounce from your own sending, which can override an old good result.
Use the status in your sending rules
- Valid: send normally.
- Risky or unknown: send in small steps, to engaged people first, and watch bounces.
- Invalid: do not send. Keep the row, so the address is not added again as new.
- Bounced since the check: treat as invalid, whatever the old status says.
Keeping invalid rows instead of deleting them matters. If you delete them, the next import brings them back and you pay to check them again.
Decide when a result goes stale
A result describes the address at one moment. Reasonable starting points are to re-check active contacts a few times a year and to check anything older than about six months before a big campaign. Use verified_at to find them with one query instead of re-checking everything.
Handle the errors too
A check can fail for reasons that have nothing to do with the address, such as a timeout. Store that as pending or unchecked, not as invalid, and retry later. Treating a failed check as a bad address deletes good contacts.
Keep it light on personal data
A status column is far less sensitive than a copy of the full result file. Store what you need to decide who to mail and no more, and follow your own retention rules.
Where to put the check
Run it when the address enters your system, using the verification API, and again in bulk on older data with bulk verification. Test a single address first with the email checker.
Frequently asked questions
Should I store the full API response? Usually the status, the reason and the date are enough. Store more only if you will use it.
What if the status changes between checks? Keep the newest result and the date. If you need history, write each check to a separate log table.
