Contact verification skill

Verify email addresses before they enter outbound sequences to prevent bounces and protect sender reputation.

by LeadMagic·MIT license·★ 62 Stars on the repo·GitHub ↗

Use now

Inside this skill

SKILL.md · the author's own words
# Contact Verification

## Overview

Verification is the gate between finding emails and sending to them. Skipping it
is the single most expensive mistake in outbound — a 5% bounce rate triggers
automated spam filtering at every major inbox provider. Recovery takes months.

The rule: every email address entering a sequence must pass verification first.
No exceptions. Verify when you find, re-verify every 90 days, and always verify
before a new campaign launches.

## When to Use

- \"Verify these emails before we send\"
- \"Check if these addresses are deliverable\"

Word-for-word excerpt, not a result. Read the full SKILL.md ↓

Files of Contact verification

LeadMagic/main1 file shown
SKILL.md
Show the full text169 lines

Contact Verification

Overview

Verification is the gate between finding emails and sending to them. Skipping it is the single most expensive mistake in outbound — a 5% bounce rate triggers automated spam filtering at every major inbox provider. Recovery takes months.

The rule: every email address entering a sequence must pass verification first. No exceptions. Verify when you find, re-verify every 90 days, and always verify before a new campaign launches.

When to Use

  • "Verify these emails before we send"
  • "Check if these addresses are deliverable"
  • "Clean my prospect list"
  • "Are these safe to send to?"
  • "Validate this CSV of contacts"
  • "What's the bounce risk on this list?"

Do NOT use for:

  • Finding new emails — use email-finding first
  • Deliverability infrastructure setup — use email-deliverability
  • General list hygiene beyond email — use list-building

Authoritative Foundations

Email verification is grounded in established deliverability practices. Industry consensus across major sending platforms (Google Workspace, M365, Smartlead, Instantly) converges on a bounce rate ceiling of 2% for cold outreach and best-in-class operations targeting under 1%.

Data decay is real: 2-3% of B2B emails become invalid every month. A 10,000-contact database loses 200-300 valid emails monthly. Re-verification on a 90-day cadence is the minimum to maintain list health.

Prerequisites

  • A list of email addresses to verify
  • Access to a verification service (LeadMagic Email Validation, ZeroBounce, NeverBounce, MillionVerifier, or equivalent)
  • For batch verification: CSV with at minimum an email column

Step-by-Step Process

Phase 1: Intake

Ask the user:

  1. How many emails need verification? (single vs batch)
  2. When were these emails last verified? (if never, flag as high-risk)
  3. What's the sending volume and cadence? (higher volume = stricter verification)
  4. Are these going to cold outreach or warm nurture? (cold = stricter)
Phase 2: Run Verification

Submit each email to the verification service. Services return a status:

Status Meaning Action for Cold Outbound Action for Warm/Nurture
valid Mailbox exists and accepts mail Safe to send Safe to send
invalid Mailbox doesn't exist or is deactivated Do not send — remove from list Do not send
risky / catch-all Domain accepts all mail, can't confirm individual mailbox Skip at volume. Send selectively (max 5% of volume) with extra monitoring Send, monitor bounces closely
unknown Could not determine status Skip. Re-verify in 7 days or discard Send if high-value, monitor
disposable Temporary/throwaway address Never send Never send
Phase 3: Segment and Route
  1. Valid → Route to the sendable list. Mark with verification date.
  2. Invalid → Remove from all sequences. Log the bounce reason if available.
  3. Risky/Catch-All → Separate list. For cold outbound at volume: skip entirely. For high-value enterprise accounts: send at reduced volume (<5% of total), monitor bounce rates daily.
  4. Unknown → Hold for re-verification. If critical contact, attempt after 7 days. Otherwise, discard.
Phase 4: Record Keeping

Every verified contact should have:

  • verification_status: valid | invalid | risky | unknown
  • verification_date: ISO date of last verification
  • verification_source: which service was used

CRM systems should filter sequences to only include verification_status = valid AND verification_date within last 90 days.

Output Format

Summary report:

Total verified: 1,000
Valid: 920 (92%)
Invalid: 35 (3.5%)
Risky/Catch-All: 30 (3%)
Unknown: 15 (1.5%)

Sendable (valid): 920
Requires monitoring (risky): 30
Removed (invalid + unknown): 50

Estimated safe send volume: 920-950/day (depending on risky handling)
Bounce rate projection: 0.8-1.5%

Quality Check

  • All emails in sequence have verification_status = valid
  • No emails with verification_date older than 90 days
  • Invalid emails removed from all active sequences
  • Catch-all emails tracked separately with daily bounce monitoring
  • Disposable emails permanently suppressed

Common Pitfalls

  1. Skipping verification entirely. "We found the emails from a reputable source." Every provider returns stale data. 5-15% of "found" emails bounce. The cost of re-warming a domain far exceeds the cost of verification.

  2. Treating catch-all as safe. Catch-all domains accept mail to any address at the domain, making individual mailbox verification impossible. They produce higher bounce rates. Treat them as a separate, monitored segment.

  3. One-time verification. "We verified this list 6 months ago." At 2-3% monthly decay, 12-18% of that list is now invalid. Re-verify every 90 days.

  4. Sending to invalid emails one more time. "Maybe it was a temporary bounce." If verification returns invalid, the mailbox doesn't exist. Sending again won't fix it. Remove permanently.

  5. Not updating CRM with verification status. Verification without recording the result means the data decays silently. Update CRM fields immediately.

Execution Artifacts

  • references/framework-notes.md — Named frameworks and reference tables
  • templates/output-template.md — Deliverable shell for agent output
  • scripts/check-output.py — Lightweight deliverable validator
  • email-finding: Find emails before verifying them
  • email-deliverability: Full deliverability strategy beyond verification
  • list-building: Build and maintain clean prospect lists
  • deliverability-monitoring: Ongoing monitoring of bounce rates and reputation
1---
2name: contact-verification
3description: >-
4 Verify email addresses before they enter outbound sequences to prevent bounces
5 and protect sender reputation. Use when the user wants to validate emails,
6 check deliverability, verify contact data, prevent bounces, clean a list, or
7 ensure their outreach list is safe to send. Triggers on: \"verify emails\",
8 \"validate this list\", \"check if these emails are real\", \"email verification\",
9 \"bounce prevention\", \"clean my list\", \"are these safe to send\", or any request
10 to confirm email deliverability before outreach.
11license: MIT
12compatibility: Claude Code, Codex, GitHub Copilot, Cursor, Gemini CLI, OpenCode, Goose, Hermes, Windsurf, Zed
13metadata:
14 version: \"1.0.0\"
15 author: LeadMagic
16 category: prospecting
17 tags: [verification, email, deliverability, bounce-prevention, data-quality]
18 related_skills: [email-finding, lead-enrichment, email-deliverability, list-building]
19 frameworks:
20 - "Email Deliverability Best Practices"
21 - "Aaron Ross — Predictable Revenue"
22 - "Winning by Design — ICP Segmentation"
23---
24 
25# Contact Verification
26 
27## Overview
28 
29Verification is the gate between finding emails and sending to them. Skipping it
30is the single most expensive mistake in outbound — a 5% bounce rate triggers
31automated spam filtering at every major inbox provider. Recovery takes months.
32 
33The rule: every email address entering a sequence must pass verification first.
34No exceptions. Verify when you find, re-verify every 90 days, and always verify
35before a new campaign launches.
36 
37## When to Use
38 
39- \"Verify these emails before we send\"
40- \"Check if these addresses are deliverable\"
41- \"Clean my prospect list\"
42- \"Are these safe to send to?\"
43- \"Validate this CSV of contacts\"
44- \"What's the bounce risk on this list?\"
45 
46Do NOT use for:
47- Finding new emails — use email-finding first
48- Deliverability infrastructure setup — use email-deliverability
49- General list hygiene beyond email — use list-building
50 
51## Authoritative Foundations
52 
53Email verification is grounded in established deliverability practices.
54Industry consensus across major sending platforms (Google Workspace, M365,
55Smartlead, Instantly) converges on a bounce rate ceiling of 2% for cold
56outreach and best-in-class operations targeting under 1%.
57 
58Data decay is real: 2-3% of B2B emails become invalid every month. A
5910,000-contact database loses 200-300 valid emails monthly. Re-verification
60on a 90-day cadence is the minimum to maintain list health.
61 
62## Prerequisites
63 
64- A list of email addresses to verify
65- Access to a verification service (LeadMagic Email Validation, ZeroBounce,
66 NeverBounce, MillionVerifier, or equivalent)
67- For batch verification: CSV with at minimum an email column
68 
69## Step-by-Step Process
70 
71### Phase 1: Intake
72 
73Ask the user:
741. How many emails need verification? (single vs batch)
752. When were these emails last verified? (if never, flag as high-risk)
763. What's the sending volume and cadence? (higher volume = stricter verification)
774. Are these going to cold outreach or warm nurture? (cold = stricter)
78 
79### Phase 2: Run Verification
80 
81Submit each email to the verification service. Services return a status:
82 
83| Status | Meaning | Action for Cold Outbound | Action for Warm/Nurture |
84|---|---|---|---|
85| **valid** | Mailbox exists and accepts mail | Safe to send | Safe to send |
86| **invalid** | Mailbox doesn't exist or is deactivated | Do not send — remove from list | Do not send |
87| **risky / catch-all** | Domain accepts all mail, can't confirm individual mailbox | Skip at volume. Send selectively (max 5% of volume) with extra monitoring | Send, monitor bounces closely |
88| **unknown** | Could not determine status | Skip. Re-verify in 7 days or discard | Send if high-value, monitor |
89| **disposable** | Temporary/throwaway address | Never send | Never send |
90 
91### Phase 3: Segment and Route
92 
931. **Valid** → Route to the sendable list. Mark with verification date.
942. **Invalid** → Remove from all sequences. Log the bounce reason if available.
953. **Risky/Catch-All** → Separate list. For cold outbound at volume: skip entirely.
96 For high-value enterprise accounts: send at reduced volume (<5% of total),
97 monitor bounce rates daily.
984. **Unknown** → Hold for re-verification. If critical contact, attempt after 7 days.
99 Otherwise, discard.
100 
101### Phase 4: Record Keeping
102 
103Every verified contact should have:
104- `verification_status`: valid | invalid | risky | unknown
105- `verification_date`: ISO date of last verification
106- `verification_source`: which service was used
107 
108CRM systems should filter sequences to only include `verification_status = valid`
109AND `verification_date` within last 90 days.
110 
111## Output Format
112 
113Summary report:
114```
115Total verified: 1,000
116Valid: 920 (92%)
117Invalid: 35 (3.5%)
118Risky/Catch-All: 30 (3%)
119Unknown: 15 (1.5%)
120 
121Sendable (valid): 920
122Requires monitoring (risky): 30
123Removed (invalid + unknown): 50
124 
125Estimated safe send volume: 920-950/day (depending on risky handling)
126Bounce rate projection: 0.8-1.5%
127```
128 
129## Quality Check
130 
131- [ ] All emails in sequence have verification_status = valid
132- [ ] No emails with verification_date older than 90 days
133- [ ] Invalid emails removed from all active sequences
134- [ ] Catch-all emails tracked separately with daily bounce monitoring
135- [ ] Disposable emails permanently suppressed
136 
137## Common Pitfalls
138 
1391. **Skipping verification entirely.** \"We found the emails from a reputable
140 source.\" Every provider returns stale data. 5-15% of \"found\" emails bounce.
141 The cost of re-warming a domain far exceeds the cost of verification.
142 
1432. **Treating catch-all as safe.** Catch-all domains accept mail to any address
144 at the domain, making individual mailbox verification impossible. They produce
145 higher bounce rates. Treat them as a separate, monitored segment.
146 
1473. **One-time verification.** \"We verified this list 6 months ago.\" At 2-3%
148 monthly decay, 12-18% of that list is now invalid. Re-verify every 90 days.
149 
1504. **Sending to invalid emails one more time.** \"Maybe it was a temporary
151 bounce.\" If verification returns invalid, the mailbox doesn't exist. Sending
152 again won't fix it. Remove permanently.
153 
1545. **Not updating CRM with verification status.** Verification without recording
155 the result means the data decays silently. Update CRM fields immediately.
156 
157## Execution Artifacts
158 
159- `references/framework-notes.md` — Named frameworks and reference tables
160- `templates/output-template.md` — Deliverable shell for agent output
161- `scripts/check-output.py` — Lightweight deliverable validator
162 
163## Related Skills
164 
165- **email-finding**: Find emails before verifying them
166- **email-deliverability**: Full deliverability strategy beyond verification
167- **list-building**: Build and maintain clean prospect lists
168- **deliverability-monitoring**: Ongoing monitoring of bounce rates and reputation
169 

Discussion

Alternatives